[reSIProcate] Many DUM -> one SipStack... Does it actually work??

[Kovar, William (Bill)]

Byron,
 
I was using the To header as an example. Request-Uri is obviously more
appropriate. However, looking at the various args to
MessageFilterRule(...) I can't determine which part could be used for a
Header filter.
 
The choices are (and my ideas of their applicability):
SchemeList - should be don't care
HostpartTypes - should be don't care
HostpartList - should be don't care
MethodList - SIP methods - this looks like the one to use but don't know
how to set a specific Request-Uri
EventList - probably want to use this one too since I'm using REFER.
 
The above is based on my examination of MessageFilterRule.cxx. I have
not pulled an SVN update since 2/06. Maybe the file has changed to add
additional functionality??
 
Which one is appropriate to set Request-Uri=sip:X at Y.COM <mailto:X at Y.COM>
for all Methods and Events.
 
Bill Kovar
Avaya Inc.
(732) 852-2609
bkovar at avaya.com
 

  _____  

From: Byron Campen [mailto:bcampen at estacado.net] 
Sent: Monday, August 07, 2006 5:50 PM
To: Kovar, William (Bill)
Cc: resiprocate-devel at list.sipfoundry.org
Subject: Re: [reSIProcate] Many DUM -> one SipStack... Does it actually
work??


Why are you making routing decisions based on the contents of the To
header? The To: header is not intended to drive routing; that is the job
of the Request-Uri.

Best regards,
Byron Campen


	Byron,
	 
	I looked at the example you listed and I'm not clear on how I
would be able to to get the msgs to route correctly. The only true
difference between the UAs is their AOR value. Is there a way to use the

	MessageFilterRules to force the msg to go to the correct UA
based on the TO address?? 
	Or something else?
	 
	Suggestions??
	 
	Bill Kovar
	Avaya Inc.
	(732) 852-2609
	bkovar at avaya.com
	 

  _____  

	From: Byron Campen [mailto:bcampen at estacado.net] 
	Sent: Monday, August 07, 2006 3:44 PM
	To: Kovar, William (Bill)
	Cc: resiprocate-devel at list.sipfoundry.org
	Subject: Re: [reSIProcate] Many DUM -> one SipStack... Does it
actually work??
	
	
	The TuSelector in the resip stack uses
TransactionUser::isForMe(SipMessage& msg) to determine which TU to send
the message to. The TuSelector will hand the message to the first TU
that returns true when isForMe is called. You can influence how a given
DUM answers isForMe by registering MessageFilterRules with that
particular instance of DUM. (see repro/repro.cxx for an example of how
this can be done) 

	Best regards,
	Byron Campen


		All,
		 
		Although I was told several months ago that this should
work, I am seeing problems with the same SipStack associated with 2
different UAs. 
		 
		The Registration of each UA seems to get routed
correctly, i.e. the OnSuccess() for the Register for a specific UA is
being delivered to the correct UA.
		 
		However, when an INVITE is sent to a particular URI, it
goes to the first UA that was associated with the SipStack. 
		 
		Any thoughts?? It seems the transaction layer is tied to
IP:PORT somehow which could be a cause of this problem...
		 
		Bill Kovar
		Avaya Inc.
		(732) 852-2609
		bkovar at avaya.com
		 
		_______________________________________________
		resiprocate-devel mailing list
		resiprocate-devel at list.sipfoundry.org
	
https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20060808/acfe5861/attachment.htm>