[OpenSIPS-Users] Unexpected loose_route() behavior
Bogdan-Andrei Iancu
bogdan at voice-system.ro
Mon Jun 21 11:46:12 CEST 2010
Hi Matthew,
My guess is that you try to set the destination after the b2bua part...
Correctly is to change the RURI before the b2bua part:
rewritehostport();
b2b_init_request("scenario");
This will spare you of a lot of problems ;)
Regards,
Bogdan
--
Bogdan-Andrei Iancu
OpenSIPS Bootcamp
20 - 24 September 2010, Frankfurt, Germany
www.voice-system.ro
Matthew Lehner 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
>>>>>>>
>>>>>>>
More information about the Users
mailing list