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

[Byron Campen]

	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/cec9a85b/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/cec9a85b/attachment.bin>