[OpenSIPS-Users] Unexpected loose_route() behavior
Matthew Lehner
mlehner at gmail.com
Tue Jun 15 19:16:38 CEST 2010
Bogdan,
I suspected that it was something my provider was doing wrong. While I
will bring this up with them, I don't expect a fix from them any time
soon.
In the meantime I would like to find a better solution to the problem.
I am thinking that a b2bua between my network and the provider network
would be best. Though I am having a minor issue getting that to work.
I setup the b2bua modules to do top hiding, but I need to do a
different rewritehostport depending on the direction of the message.
That information is based on the original src_ip and src_port, which
is lost in a top hiding situation.
I tried to add a P-hint header to tell the direction, but it's not
being passed through in the b2b requests. I set the 'custom_headers'
modparam to include P-hint, but it still does not get passed along
with the b2b request.
if (check_source_address("2"))
{
xlog("request from provider $si:$sp\n");
append_hf("P-hint: inbound\r\n");
setflag(10);
}
if (check_source_address("3") && !isflagset(10))
{
xlog("request from internal $si:$sp\n");
append_hf("P-hint: outbound\r\n");
setflag(11);
}
Is this currently not possible with the b2b modules?
Matt
On Tue, Jun 15, 2010 at 6:30 AM, Bogdan-Andrei Iancu
<bogdan at voice-system.ro> wrote:
> 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
>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: siptrace
Type: application/octet-stream
Size: 2113 bytes
Desc: not available
Url : http://lists.opensips.org/pipermail/users/attachments/20100615/1d3b48f4/attachment-0001.obj
More information about the Users
mailing list