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

[Kovar, William (Bill)]

As I thought....
 
My solution (3rd Party Call Controller monitoring several URIs) requires
that I have one application (single IP:port) that contains several (~10)
UAs that each have a unique URI but share the same SipStack. Is this at
all doable given the capabilities discussed. 
 
 
Bill Kovar
Avaya Inc.
(732) 852-2609
bkovar at avaya.com
 

  _____  

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


Are you trying to choose the TU based on the user-part of the uri? If
so, there isn't anything in MessageFilterRule that will help you. You
would need to make the filter-rule based on the host-part of the uri.

Best regards,
Byron Campen


	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/19408695/attachment.htm>