[OpenSIPS-Users] Unexpected loose_route() behavior
Bogdan-Andrei Iancu
bogdan at voice-system.ro
Tue Jun 15 12:30:08 CEST 2010
Hi Matthew,
Seams that the 64.x.x.90 party (or somebody before it) is screwing up
big time:
See the 200 OK received from callee (24.x.x.75):
Record-Route: <sip:72.x.x.227;lr=on>
Record-Route: <sip:64.x.x.90;lr=on;did=46f.d88cfd97>
Contact: <sip:8777014225 at 172.x.x.10>
And see the ACK built based as response to the 200 OK:
ACK sip:8777014225 at 72.x.x.227:5060 SIP/2.0
Route: <sip:72.x.x.227;lr=on>
I see that the rest of the route set (64.x.x.90 + 172.x.x.10) is lost,
so it is impossible to properly route the ACK from caller to callee.
Normally it should like:
ACK sip:8777014225 at 172.x.x.10 SIP/2.0
Route: <sip:64.x.x.90;lr=on;did=46f.d88cfd97>
Route: <sip:72.x.x.227;lr=on>
Regards,
Bogdan
Matthew Lehner wrote:
> Here is a sip trace from tcpdump of what happens during the call.
> Everything looks correct until you get to 1276532886.578286. This is
> where we get the ACK from the provider that has my proxy in the RURI
> instead of the final destination.
>
> 64.x.x.x is my sip trunk provider
> 72.x.x.227 is my opensips proxy
> 24.x.x.75 / 172.x.x.10 is a test install of asterisk with nat. though
> i am using port forwarding on 5060 atm.
>
> Best I can tell, it seems the sip trunk provider is ignoring the
> record-route (or maybe just the loose-route param?) and rewriting the
> RURI when they should not be.
>
> Matt
>
> On Fri, Jun 11, 2010 at 4:51 AM, Bogdan-Andrei Iancu
> <bogdan at voice-system.ro> wrote:
>
>> Hi Matthew,
>>
>> Could you post a SIP trace (from your opensips) of a such call - to see
>> exactly what is wrong and what can be done ?
>>
>> Regards,
>> Bogdan
>>
>> Matthew Lehner wrote:
>>
>>> Bogdan,
>>>
>>> Thanks, that makes sense now. The problem seems to be at my provider
>>> though. They rewrite the RURI to be my opensips and not the
>>> destination. Seems the provider is ignoring my lr=on and making it a
>>> strict route. I am still figuring out the difference between
>>> loose/strict. Would the best solution to this be to ignore any Route
>>> headers from my provider in this case?
>>>
>>> Matt
>>>
>>> On Thu, Jun 10, 2010 at 4:20 PM, Bogdan-Andrei Iancu
>>> <bogdan at voice-system.ro> wrote:
>>>
>>>
>>>> Hi Matthew,
>>>>
>>>> you have a logical bug in your routing - all sequential requests are
>>>> routed in SIP based only on Route hdrs (via loose_route), so there is no
>>>> need to do manual routing for them. Manual routing is done only for
>>>> initial requests.
>>>>
>>>> Better see http://www.opensips.org/Resources/Webinars#toc11
>>>>
>>>> When the sequential request comes from the provider, it will have a
>>>> Route hdr pointing to your opensips and in RURI will be the IP of the
>>>> final Asterisk box (contact from 200 OK) -> after loose_route, opensips
>>>> will remove the Route hdr with its IP and the request will be routed
>>>> (RURI based) to proper Asterisk.
>>>>
>>>> Regards,
>>>> Bogdan
>>>>
>>>> Matthew Lehner wrote:
>>>>
>>>>
>>>>> I am setting up opensips to act as a proxy between a SIP trunk
>>>>> provider and more than one asterisk server. I am using alias_db to
>>>>> determine which asterisk server a particular DID/user should be
>>>>> relayed to. I am also using record_route() to ensure my proxy stays in
>>>>> the entire dialog of the call.
>>>>>
>>>>> The initial requests go through just fine, but subsequent requests in
>>>>> the same dialog from the SIP provider are not getting routed properly
>>>>> because of loose_route().
>>>>>
>>>>> When the request from the SIP provider arrives, it hits loose_route()
>>>>> and the RURI gets changed to sip:222.222.222.227;lr=on which does not
>>>>> contain a username and so alias_db can no longer match the call
>>>>> details and route the request to the proper asterisk server.
>>>>>
>>>>> The way I understood loose_route() was supposed to work is.. it checks
>>>>> the top-most Route header to see if it is the local proxy.. if it is
>>>>> it removes that Route and if there is another Route below it.. it will
>>>>> change the RURI to that.
>>>>>
>>>>> If I just don't do loose_route() on requests from the SIP provider,
>>>>> everything works as expected.. but this does not seem like the right
>>>>> solution to the problem.
>>>>>
>>>>> I have included debug output from opensips, along with some of my own logging.
>>>>>
>>>>> 333.333.333.x is the SIP provider
>>>>> 222.222.222.x is my opensips proxy
>>>>>
>>>>> Regards,
>>>>>
>>>>> Matt
>>>>>
>>>>> ------------------------------------------------------------------------
>>>>>
>>>>> _______________________________________________
>>>>> Users mailing list
>>>>> Users at lists.opensips.org
>>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>>>
>>>>>
>>>>>
>>>> --
>>>> Bogdan-Andrei Iancu
>>>> www.voice-system.ro
>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>>>
>>>
>>>
>> --
>> Bogdan-Andrei Iancu
>> www.voice-system.ro
>>
>>
>> _______________________________________________
>> 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
>>
--
Bogdan-Andrei Iancu
www.voice-system.ro
More information about the Users
mailing list