Just to update...
My config on the OpenSIPS/SBC was all jacked up. I basically have two routes in my config, one for SIP messages coming from the LAN and one for SIP messages coming from the WAN. On the LAN side before I was doing my "if has_totag" and "if loose_route" I had unintentionally put my "if method is not REGISTER|MESSAGE then record_route()" before it. Then on my WAN side I didn't even have the "if method is not REGISTER|MESSAGE then record_route()". So that was really jacking up my routing. Not having the "if method is not REGISTER|MESSAGE then record_route()" in my WAN side route was the reason why I saw the INVITE coming from the OpenSIPS/Proxy and the Record_route headers not being in the correct order when my Callee received the INVITE relayed by the OpenSIPS/SBC. Also like Ali said my contacts were also an issue. I saw Jeff's post about fix_contact() so I got rid of that on my OpenSIPs/Proxy device. Things look a lot better now. I thought all that duct taping was hidding something and it got out of control. Thanks for working with me. This really gave me a good refreshers course in SIP routing. On Mon, Jul 9, 2012 at 3:45 AM, Vlad Paiu <[email protected]> wrote: > ** > Hello, > > This is quite strange, can you please also post a full OpenSIPS debug for > the call where that ACK got relayed out like > > ACK > sip:50.xx.xx.156;lr;ftag=d4xut7i3jx;nat=yes;vst=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA;did=0f9.1ddb82a6 > SIP/2.0. > Record-Route: <sip:99.xx.xx.161;r2=on;lr>. > Record-Route: <sip:192.168.88.1;r2=on;lr>. > > > Regards, > > Vlad Paiu > OpenSIPS Developerhttp://www.opensips-solutions.com > > > On 07/09/2012 07:09 AM, [email protected] wrote: > > I just got my calls working by removing the Record-Route's and then > reinserting then in an order that would according to my topology. > > I will need to go back and start from scratch to see if a lot of the other > stuff I did was really needed or not and then update but here is were I > edited the Record-Routes > > When the INVITE is coming from my OpenSIPS/Proxy to the Callee I did > > if ( is_method("INVITE") ) { > remove_hf("Record-Route"); > insert_hf("Record-Route: $(hdr(Record-Route)[2])\r\n", "Via"); > insert_hf("Record-Route: $(hdr(Record-Route)[1])\r\n", "Via"); > insert_hf("Record-Route: $(hdr(Record-Route)[0])\r\n", "Via"); > } > > Then when the 180 and 200 are coming from the Callee to the Caller before > the 180 and 200 go to the Caller I did the following > > > if (t_check_status("180")){ > remove_hf("Record-Route"); > insert_hf("Record-Route: $(hdr(Record-Route)[2])\r\n", "Via"); > insert_hf("Record-Route: $(hdr(Record-Route)[1])\r\n", "Via"); > insert_hf("Record-Route: $(hdr(Record-Route)[0])\r\n", "Via"); > > } > > > if (t_check_status("200")){ > remove_hf("Record-Route"); > insert_hf("Record-Route: $(hdr(Record-Route)[2])\r\n", "Via"); > insert_hf("Record-Route: $(hdr(Record-Route)[1])\r\n", "Via"); > insert_hf("Record-Route: $(hdr(Record-Route)[0])\r\n", "Via"); > > } > > > So not sure if there is something wrong with the way OpenSIPS places the > Record-Route ordering when OpenSIPS has multiple interfaces. I am not 100% > sure if what I have done here is right or not but calls are working now. > > Any feedback? > > > On , [email protected] wrote: > > I think I have multiple issues going on but I might be getting closer to > the issue. > > > > > > > > > > > > I am wondering if this might be part of the issue. > > > > > > > > > > > > If you look at the the following, > http://www.tech-invite.com/Ti-sip-dialog.html#inv , for the first INVITE > message that the Callee receives the first Proxy that the callee needs to > take in its Record-Route is first in the list of Record-Routes on the > INVITE message. As for the Caller the Record-Route set gets flipped > (whatever Record-Route is on the top will be its last route hop). So if > this is the case then why is the OpenSIPS/SBC device sending my Callee > device an INVITE message with the far end proxy, OpenSIPS/Proxy, on the top > of the Record-Route list? Here is the INVITE that my callee is getting > > > > > > > > > > > > INVITE sip:[email protected]:3072;line=9zx0whnm SIP/2.0 > > > > > > Record-Route: > 4aoni525hc;nat=yes;vst=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA;did=598.b8b26331> > > > > > > Record-Route: > > > > > > Record-Route: > > > > > > > > > > > > > > > > > > The Record-Route with 50.XX.XX.156 should be at the bottom of the list I > think because that is the OpenSIPS/Proxy that is on the Internet. Am I > wrong on this? On the SIP trace I posted on pastebin this INVITE to the > Callee starts on line 299. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On , [email protected] wrote: > > > > > > > I'm really not sure if I am just duck taping the issue but I was able > to make most of the call work. The only problem now is when the Callee > hangs up the BYE is sent directly to the OpenSIPS/Proxy IP instead of going > to the OpenSIPS/SBC. This will not work due to firewall issues. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > My ACKs are no longer not showing up as Non-Loose Route messages, but > the BYEs are. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > So if the Caller hangs up the Callee sees the BYE message (GOOD!), but > if the Callee hangs up the Caller never sees the BYE message (Bad). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I will send a PCAP trace to Ali directly. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On , Ali Pey [email protected]> wrote: > > > > > > > > > > > > > > > > > > > > > > Duane, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The Ack should not have any request-route headers. Only Route > headers. If you see request-route headers, then you need to find how they > got there and fix that first. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I believe it is ok if the Ack doesn't go through loose route, in > that case it should be sent to the request-uri destination ip and that IP > should be your client IP. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Let me know if this help. If not, can you attach here a wireshark > trace and I will go through your signalling for you. Going thought a text > trace can be quit time consuming. In wireshark it's a lot easier to jump > from a message to another through the call flow. You can use tcpdump to > capture to .cap file for wireshark. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > > > > > > > > > Ali Pey > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Sat, Jul 7, 2012 at 3:35 PM, osiris123d [email protected]> > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > This is driving me crazy. I was right the first time when I said > that one of > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > the ACKs was not showing up as a loose route. It is the third ACK > that is > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > coming from the OpenSIPS/Proxy. When it reaches the OpenSIPS/SBC > device the > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ACK fails as a loose route. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > It would make sense that this would not be a loose route because > there are > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > no Route headers so the loose_route() function would return FALSE. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The issue still remains that when the ACK reaches the OpenSIPS/SBC > it still > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > isn't routed to the Callee, instead it is looped and routed to the > same > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > interface it came from because that is whats in the RURI. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > View this message in context: > http://opensips-open-sip-server.1449251.n2.nabble.com/Two-OpenSIPS-proxies-issue-tp7580685p7580743.html > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Sent from the OpenSIPS - Users mailing list archive at Nabble.com. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Users mailing list > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > [email protected] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > Users mailing > [email protected]http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > _______________________________________________ > Users mailing list > [email protected] > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > -- -- *--*--*--*--*--* Duane *--*--*--*--*--* --
_______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
