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

[Byron Campen]

	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
> 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 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/b055c742/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2369 bytes
Desc: not available
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20060808/b055c742/attachment.bin>