[OpenSIPS-Users] problem with loose_route()/t_relay() across multiple interfaces
Jeff Pyle
jpyle at fidelityvoice.com
Tue Jul 10 14:34:14 CEST 2012
Vlad,
I think I found it. There is a fix_contact("3") on the "softswitch". The
"1" bit test is finding the private Contact URI, causing the function to
return true, thus rewriting the Contact header as the received ip:port.
Interesting how it does exactly what I told it to.
- Jeff
On Tue, Jul 10, 2012 at 8:23 AM, Jeff Pyle <jpyle at fidelityvoice.com> wrote:
> Vlad,
>
> Yes, that's it exactly! The softswitch in this case is changing the
> Contact header from the original value to the received ip:port. The strict
> router behavior makes sense.
>
> The "softswitch" in this case is Opensips 1.6. Which functions have the
> ability to cause that change? The "softswitch" Opensips configuration has
> been active for years and I've never noticed this behavior before.
>
>
> - Jeff
>
>
>
> On Tue, Jul 10, 2012 at 4:29 AM, Vlad Paiu <vladpaiu at opensips.org> wrote:
>
>> **
>> Hello Jeff,
>>
>> Your OpenSIPS probably routes that ACK as a strict router, since it sees
>> that in the R-URI there's an IP where it's listening on (
>> opensips_WAN_public ).
>> The contact in the 200OK had sip:9998887777 at 172.21.201.1:5066 , so this
>> should have been in the ACK's R-URI. Try to fix the softswitch.
>>
>> Regards,
>>
>> Vlad Paiu
>> OpenSIPS Developerhttp://www.opensips-solutions.com
>>
>>
>> On 07/09/2012 09:28 PM, Jeff Pyle wrote:
>>
>> Rudy,
>>
>> I don't have pcaps but I do have ngreps available here:
>> http://pastebin.com/EKMrhc7Z
>>
>> You can see the ACK come in from the softswitch to Opensips's public
>> interface starting at line 212. I'd expect this to relay through to the
>> private side, but instead, we see starting on line 228 it relays the ACK to
>> itself on its private interface. I don't know why that is happening.
>>
>> The opensips.cfg is available here:
>> http://pastebin.com/UB9pPuUk
>>
>> I'm not sure what to do with it from here.
>>
>>
>> - Jeff
>>
>>
>>
>> On Sun, Jul 8, 2012 at 11:44 AM, Rudy <rudy at dynamicpacket.com> wrote:
>>
>>> Jeff,
>>>
>>> Can you post the pcap captures somewhere so I can take a look?
>>>
>>> Thanks in advance,
>>> --Rudy
>>> Dynamic Packet
>>> Toll-Free: 888.929.VOIP ( 8647 )
>>>
>>>
>>> On Sun, Jul 8, 2012 at 8:21 AM, Jeff Pyle <jpyle at fidelityvoice.com>
>>> wrote:
>>> > Hi Duane,
>>> >
>>> > I have captures now! I also read through your thread. The situation
>>> looks
>>> > to be the same. I also have a missing username in the self-relayed
>>> ACK's
>>> > RURI.
>>> >
>>> > And it's also driving my crazy.
>>> >
>>> > I'm on 1.7 build 9142. You?
>>> >
>>> >
>>> >
>>> > - Jeff
>>> >
>>> >
>>> > On Sat, Jul 7, 2012 at 7:14 PM, <duane.larson at gmail.com> wrote:
>>> >>
>>> >> Almost sounds like you and I are having the same issue.
>>> >>
>>> >> Here's my issue
>>> >>
>>> >>
>>> http://opensips-open-sip-server.1449251.n2.nabble.com/Two-OpenSIPS-proxies-issue-td7580685.html
>>> >>
>>> >> Do you have a SIP trace? I'm just wondering if we are having the same
>>> >> problem. Does the ACK that gets relayed to ifself on the other IP
>>> have the
>>> >> username missing in the RURI?
>>> >>
>>> >>
>>> >>
>>> >>
>>> >> On , Jeff Pyle <jpyle at fidelityvoice.com> wrote:
>>> >> > Hello,
>>> >> >
>>> >> >
>>> >> >
>>> >> > I'm attempting to write a config to perform near-end NAT traversal
>>> on
>>> >> > Opensips 1.7. I'm having a problem with the loose_route of the ACK
>>> after
>>> >> > the 200 OK, and if I wait long enough, the BYE as well.
>>> >> >
>>> >> >
>>> >> >
>>> >> >
>>> >> > Here's the scenario. An INVITE comes in the WAN side and is
>>> t_relay'd
>>> >> > to the LAN side. The LAN-side UAS sends a 200 OK, and that is
>>> relayed back
>>> >> > to the WAN-side UAC. So far, so good. Then the WAN-side UAC sends
>>> the ACK
>>> >> > to the 200. Opensips relays this from its own WAN IP to its own
>>> LAN IP - I
>>> >> > found it with ngrep on the lo interface. Eventually Opensips sends
>>> a 408
>>> >> > back to the UAC.
>>> >> >
>>> >> >
>>> >> >
>>> >> >
>>> >> > Here's the relevant portion of the config, based largely on the
>>> included
>>> >> > sample. This works fine with single-interface configurations:
>>> >> >
>>> >> >
>>> >> >
>>> >> >
>>> >> > if (has_totag()) {
>>> >> > if (loose_route()) {
>>> >> > if (method=="INVITE") record_route();
>>> >> >
>>> >> >
>>> >> > if (!t_relay()) sl_reply_error();
>>> >> > exit;
>>> >> > } else {
>>> >> > if (method == "ACK") {
>>> >> > if (t_check_trans()) {
>>> >> >
>>> >> >
>>> >> > if (!t_relay())
>>> >> > sl_reply_error();
>>> >> > exit;
>>> >> > } else {
>>> >> > exit;
>>> >> >
>>> >> >
>>> >> > }
>>> >> > }
>>> >> > sl_send_reply("404", "Not Here");
>>> >> > }
>>> >> > exit;
>>> >> >
>>> >> >
>>> >> > }
>>> >> >
>>> >> >
>>> >> > I've verified with xlogs the ACK hits in the loose_route() portion
>>> of
>>> >> > the config. It does hit t_relay, but it relays the message to
>>> itself on its
>>> >> > 'other' IP. I've tried to look the extended debugs but I'm not
>>> finding
>>> >> > anything telling. Unfortunately I don't have any experience with
>>> multiple
>>> >> > interface configurations. I suspect it has something to do with
>>> the double
>>> >> > Via lines added, one from each interface. Perhaps it's not
>>> detecting the
>>> >> > second Via as its own? (Even if that were the case, I can't
>>> explain why
>>> >> > it's not responding to itself on the lo interface.)
>>> >> >
>>> >> >
>>> >> >
>>> >> >
>>> >> > I do have mhomed=1 enabled. Without it the initial invite doesn't
>>> >> > arrive at the LAN-side UAS.
>>> >> >
>>> >> >
>>> >> > I've experimented with check_via, aliases, etc. No effect. Any
>>> >> > suggestions on where to go from here?
>>> >> >
>>> >> >
>>> >> >
>>> >> >
>>> >> >
>>> >> >
>>> >> >
>>> >> >
>>> >> > - Jeff
>>> >> >
>>> >> >
>>> >> >
>>> >> >
>>> >> >
>>> >> >
>>> >> >
>>> >> >
>>> >>
>>> >> _______________________________________________
>>> >> 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
>>> >
>>>
>>> _______________________________________________
>>> Users mailing list
>>> Users at lists.opensips.org
>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>
>>
>>
>> _______________________________________________
>> Users mailing listUsers at lists.opensips.orghttp://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
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20120710/e91d64eb/attachment.htm>
More information about the Users
mailing list