[OpenSIPS-Users] Unexpected loose_route() behavior
Matthew Lehner
mlehner at gmail.com
Tue Jun 15 20:25:45 CEST 2010
After digging through the source code, it seems that any modifications
to the current SIP message don't happen until the message is sent out.
If this is true, what would be the best way to pass on the
inbound/outbound flags with the b2b requests?
Matt
On Tue, Jun 15, 2010 at 1:16 PM, Matthew Lehner <mlehner at gmail.com> wrote:
> 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
>>
>
More information about the Users
mailing list