[OpenSIPS-Users] loose routing question

[Bogdan-Andrei Iancu]

Hi Robert,

This is a typical example of "SIP understanding outside the SIP spec" :D..

RFC3261 is very clear that in a Route Set (RR headers and contact), 
across the dialog, only the contacts can be changed. The RR headers 
cannot be changed at all. So, no  UAC/UAS should look for RR headers in 
any sequential request.

But the difference between theory and practice is that in theory, theory 
and practice are the same, but in practice they are not.

So, to be on the safe side (at least from your point of view) is will be 
better to do RR for sequential requests also - if the UAC/UAS are RFC 
compliant, they will ignore it. If they don't, you try to set the same 
Routing Set as per initial request.

Regards,
Bogdan

Robert Dyck wrote:
> As an aside, there are Asterisk machines out there that do not follow the 
> rules. Specifically they will alter their route set according to R-R received 
> in-dialog. This usually does not cause a problem because most UA's repeat 
> their R-R in the in-dialog request. Twinkle as one example however does not 
> send R-R with the in-dialog request. Asterisk will then create a null route 
> set. Asterisk was patched I believe about a year ago for this problem but 
> service providers are slow to upgrade. I eventually gave up badgering one 
> service provider.
>
> On Wednesday 04 March 2009, Bogdan-Andrei Iancu wrote:
>   
>> Hi Brett,
>>
>> As Inaki said, the Route header has priority over the Contact in
>> building the route set. You can check the Admin Course:
>>
>>     http://www.voice-sistem.ro/downloads/2007.08.29-Admin-Course/
>>
>> section 02 - routing. I put there a detailed description of  SIP routing
>> (and how RR works). If the archive contains only PDF file (with no
>> animation), just let me know and I can provide the PPT files.
>>
>> Regards,
>> Bogdan
>>
>> Brett Nemeroff wrote:
>>     
>>> Question...
>>>
>>> In general the receipient of an INVITE should respond to that invite
>>> to the address in the contact header, right?
>>>
>>> What if there is a record-route header? That should prevail, right?
>>>
>>> I'm having a problem that with a single provider, some (not all) calls
>>> they don't send the BYE from the FAR side of the call back via me,
>>> instead it goes direct to the originator.
>>>
>>> Example:
>>>
>>> My customer places a call to me. I send to my provider. Provider sends
>>> it to destination.
>>>
>>> Destination hangs up, BYE goes to my customer instead of me.. My
>>> INVITE to my provider DOES have a record-route header init.
>>>
>>> Originally, this problem began because my customer would reinvite the
>>> call right after the call was established and the re-invite, because
>>> it was in-dialog wouldn't get record routed.
>>>
>>> So I moved my record-route block to before my loose route block.  Now,
>>> sometimes I get byes.. I'm not sure what I'm doing wrong.. any ideas?
>>> -Brett
>>>
>>> ------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> Users mailing list
>>> Users at lists.opensips.org
>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>       
>> _______________________________________________
>> Users mailing list
>> Users at lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>     
>
>
>
>