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

[Scott Godin]

Why not just use 1 stack and 1 DUM?  Use the AppDialogSet's to associate
app data with invite transactions to keep track which callbacks apply to
which URI.

 

From: resiprocate-devel-bounces at list.sipfoundry.org
[mailto:resiprocate-devel-bounces at list.sipfoundry.org] On Behalf Of
Kovar, William (Bill)
Sent: Tuesday, August 08, 2006 10:12 AM
To: Byron Campen
Cc: resiprocate-devel at list.sipfoundry.org
Subject: Re: [reSIProcate] Many DUM -> one SipStack... Does it
actuallywork??

 

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/20060814/9710bf60/attachment.htm>