reSIProcate

Mailing Lists

Source Code

Google Search:



< Previous by Date Date Index Next by Date >
< Previous in Thread Thread Index Next in Thread >

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

If the uris all have the same host-part, not without subclassing DialogUsageManager. Or, perhaps you could create a wrapper TU that contains a DUM and will answer isForMe in the way you want.

For the list: Does it make sense to make MessageFilterRule suitable for subclassing? This would allow arbitrarily complex TU selection, which could be a very powerful tool.

Thoughts?

Best regards,
Byron Campen

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
 

From: Byron Campen [mailto:bcampen@xxxxxxxxxxxx]
Sent: Tuesday, August 08, 2006 10:05 AM
To: Kovar, William (Bill)
Cc: resiprocate-devel@xxxxxxxxxxxxxxxxxxx
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@xxxxx for all Methods and Events.
 
Bill Kovar
Avaya Inc.
(732) 852-2609
 

From: Byron Campen [mailto:bcampen@xxxxxxxxxxxx]
Sent: Monday, August 07, 2006 5:50 PM
To: Kovar, William (Bill)
Cc: resiprocate-devel@xxxxxxxxxxxxxxxxxxx
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
 

From: Byron Campen [mailto:bcampen@xxxxxxxxxxxx]
Sent: Monday, August 07, 2006 3:44 PM
To: Kovar, William (Bill)
Cc: resiprocate-devel@xxxxxxxxxxxxxxxxxxx
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
 
_______________________________________________
resiprocate-devel mailing list




Attachment: smime.p7s
Description: S/MIME cryptographic signature