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 <jp...@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 <vladp...@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@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 <r...@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 <jp...@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.lar...@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 <jp...@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@lists.opensips.org >>> >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>> >> >>> > >>> > >>> > _______________________________________________ >>> > Users mailing list >>> > Users@lists.opensips.org >>> > http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>> > >>> >>> _______________________________________________ >>> Users mailing list >>> Users@lists.opensips.org >>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>> >> >> >> _______________________________________________ >> Users mailing >> listUsers@lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users >> >> >> _______________________________________________ >> Users mailing list >> Users@lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> >> >
_______________________________________________ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users