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

[Steve Robichaud]

Could you simply remember the rinstance param on the contact header when 
registering an aor and route invites based on that?

Enjoy,
Steve Robichaud

-----Original Message-----
From: Byron Campen
Sent: 08/08/2006 10:27 AM

> 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 <mailto: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 
>> <mailto: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 <mailto: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 
>>> <mailto: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 <mailto: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 
>>>> <mailto: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 <mailto:bkovar at avaya.com>
>>>>>  
>>>>> _______________________________________________
>>>>> resiprocate-devel mailing list
>>>>> resiprocate-devel at list.sipfoundry.org 
>>>>> <mailto:resiprocate-devel at list.sipfoundry.org>
>>>>> https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel
>>>>
>>>>
>>>
>>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>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/fc608d7f/attachment.htm>