Hi Bruce, It is a logical problem. The chain is: 3 -> 1 -> 2 -> 4, and when the reply goes back, the NAT traversal must be done by the border entity (first in the public net). So, if 4 is behind nat, then 2 must do it and not 1 (like in your case)
Because 1 (and not 2) is "fixing" the contact , the routing info gets lost (the 4 hop is lost). So, guilty is 2 for not fixing the contact in 200 OK from 4. Regards, Bogdan Bruce Borrett wrote: > Hi Bogdan > > Thank you for your reply, that is exactly how I understood it. > > Here is another fuller trace for a better understanding of the > problem, which I believe to be uac_nat_test. On both servers , when a > 200 is received, uac_nat_test is returning true because it is finding > the top via (next hop for reply) to be different to the source ip > (previous hop of reply): > > Internet Protocol, Src: 1.1.1.1 (1.1.1.1), Dst: 2.2.2.2 (2.2.2.2) > > User Datagram Protocol, Src Port: sip (5060), Dst Port: sip (5060) > > INVITE sip:[email protected] SIP/2.0 > Record-Route: <sip:1.1.1.1;lr=on;ftag=as1a75bb38> > Via: SIP/2.0/UDP 1.1.1.1;branch=z9hG4bK5be8.eeb63911.0 > Via: SIP/2.0/UDP 3.3.3.3:5060;branch=z9hG4bK55985828;rport=5060 > From: "22222222222" <sip:[email protected]>;tag=as1a75bb38 > To: <sip:[email protected]> > Contact: <sip:[email protected]> > Call-ID: [email protected] > CSeq: 102 INVITE > User-Agent: Asterisk PBX > Max-Forwards: 69 > Date: Tue, 18 May 2010 06:29:00 GMT > Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY > Supported: replaces > X-CRE-ID: "sbc-tp-04-1274164140.30823.0 > X-DIALSTRING: SIP/ico-bry-001/1111111111 > Content-Type: application/sdp > Content-Length: 259 > > v=0 > o=root 4296 4296 IN IP4 3.3.3.3 > s=session > c=IN IP4 3.3.3.3 > t=0 0 > m=audio 10060 RTP/AVP 18 101 > a=rtpmap:18 G729/8000 > a=fmtp:18 annexb=no > a=rtpmap:101 telephone-event/8000 > a=fmtp:101 0-16 > a=silenceSupp:off - - - - > a=ptime:60 > a=sendrecv > > > > > > > > > Internet Protocol, Src: 2.2.2.2 (2.2.2.2), Dst: 4.4.4.4 (4.4.4.4) > > User Datagram Protocol, Src Port: sip (5060), Dst Port: sip (5060) > > INVITE sip:[email protected] SIP/2.0 > Record-Route: <sip:2.2.2.2;lr=on;ftag=as1a75bb38> > Record-Route: <sip:1.1.1.1;lr=on;ftag=as1a75bb38> > Via: SIP/2.0/UDP 2.2.2.2;branch=z9hG4bK5be8.91dcf496.0 > Via: SIP/2.0/UDP > 1.1.1.1;rport=5060;received=1.1.1.1;branch=z9hG4bK5be8.eeb63911.0 > Via: SIP/2.0/UDP 3.3.3.3:5060;branch=z9hG4bK55985828;rport=5060 > From: "2222222222" <sip:[email protected]>;tag=as1a75bb38 > To: <sip:[email protected]> > Contact: <sip:[email protected]> > Call-ID: [email protected] > CSeq: 102 INVITE > User-Agent: Asterisk PBX > Max-Forwards: 68 > Date: Tue, 18 May 2010 06:29:00 GMT > Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY > Supported: replaces > X-CRE-ID: "sbc-tp-04-1274164140.30823.0 > X-DIALSTRING: SIP/ico-bry-001/1111111111 > Content-Type: application/sdp > Content-Length: 259 > > v=0 > o=root 4296 4296 IN IP4 3.3.3.3 > s=session > c=IN IP4 3.3.3.3 > t=0 0 > m=audio 10060 RTP/AVP 18 101 > a=rtpmap:18 G729/8000 > a=fmtp:18 annexb=no > a=rtpmap:101 telephone-event/8000 > a=fmtp:101 0-16 > a=silenceSupp:off - - - - > a=ptime:60 > a=sendrecv > > > > > > Internet Protocol, Src: 4.4.4.4 (4.4.4.4), Dst: 2.2.2.2 (2.2.2.2) > > User Datagram Protocol, Src Port: sip (5060), Dst Port: sip (5060) > > SIP/2.0 200 OK > Via: SIP/2.0/UDP 2.2.2.2;branch=z9hG4bK5be8.91dcf496.0;received=2.2.2.2 > Via: SIP/2.0/UDP > 1.1.1.1;rport=5060;received=1.1.1.1;branch=z9hG4bK5be8.eeb63911.0 > Via: SIP/2.0/UDP 3.3.3.3:5060;branch=z9hG4bK55985828;rport=5060 > Record-Route: <sip:2.2.2.2;lr=on;ftag=as1a75bb38> > Record-Route: <sip:1.1.1.1;lr=on;ftag=as1a75bb38> > From: "2222222222" <sip:[email protected]>;tag=as1a75bb38 > To: <sip:[email protected]>;tag=as5bd164c9 > Call-ID: [email protected] > CSeq: 102 INVITE > User-Agent: Asterisk PBX 1.6.0.9 > Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY > Supported: replaces, timer > Contact: <sip:[email protected]> > Content-Type: application/sdp > Content-Length: 290 > > v=0 > o=root 2115801714 2115801714 IN IP4 4.4.4.4 > s=Asterisk PBX 1.6.0.9 > c=IN IP4 4.4.4.4 > t=0 0 > m=audio 12004 RTP/AVP 18 101 > a=rtpmap:18 G729/8000 > a=fmtp:18 annexb=no > a=rtpmap:101 telephone-event/8000 > a=fmtp:101 0-16 > a=silenceSupp:off - - - - > a=ptime:60 > a=sendrecv > > > > > > > Internet Protocol, Src: 2.2.2.2 (2.2.2.2), Dst: 1.1.1.1 (1.1.1.1) > > User Datagram Protocol, Src Port: sip (5060), Dst Port: sip (5060) > > SIP/2.0 200 OK > Via: SIP/2.0/UDP > 1.1.1.1;rport=5060;received=1.1.1.1;branch=z9hG4bK5be8.eeb63911.0 > Via: SIP/2.0/UDP 3.3.3.3:5060;branch=z9hG4bK55985828;rport=5060 > Record-Route: <sip:2.2.2.2;lr=on;ftag=as1a75bb38> > Record-Route: <sip:1.1.1.1;lr=on;ftag=as1a75bb38> > From: "2222222222" <sip:[email protected]>;tag=as1a75bb38 > To: <sip:[email protected]>;tag=as5bd164c9 > Call-ID: [email protected] > CSeq: 102 INVITE > User-Agent: Asterisk PBX 1.6.0.9 > Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY > Supported: replaces, timer > Contact: <sip:[email protected]> > Content-Type: application/sdp > Content-Length: 290 > > v=0 > o=root 2115801714 2115801714 IN IP4 4.4.4.4 > s=Asterisk PBX 1.6.0.9 > c=IN IP4 4.4.4.4 > t=0 0 > m=audio 12004 RTP/AVP 18 101 > a=rtpmap:18 G729/8000 > a=fmtp:18 annexb=no > a=rtpmap:101 telephone-event/8000 > a=fmtp:101 0-16 > a=silenceSupp:off - - - - > a=ptime:60 > a=sendrecv > > > > > ACK is sent with 2.2.2.2 in ruri, instead of 4.4.4.4: > > Internet Protocol, Src: 1.1.1.1 (1.1.1.1), Dst: 2.2.2.2 (2.2.2.2) > > User Datagram Protocol, Src Port: sip (5060), Dst Port: sip (5060) > > ACK sip:[email protected]:5060 SIP/2.0 > Record-Route: <sip:1.1.1.1;lr=on;ftag=as1a75bb38> > Via: SIP/2.0/UDP 1.1.1.1;branch=z9hG4bK5be8.eeb63911.2 > Via: SIP/2.0/UDP 3.3.3.3:5060;branch=z9hG4bK07b01eaf;rport=5060 > Route: <sip:2.2.2.2;lr=on;ftag=as1a75bb38> > From: "2222222222" <sip:[email protected]>;tag=as1a75bb38 > To: <sip:[email protected]>;tag=as5bd164c9 > Contact: <sip:[email protected]> > Call-ID: [email protected] > CSeq: 102 ACK > User-Agent: Asterisk PBX > Max-Forwards: 69 > Content-Length: 0 > > > > > The ACK is not relayed on to 4.4.4.4, and so 4.4.4.4 just keeps > retransmitting 200 replies. Later the BYE from 1.1.1.1 also has an > incorrect ruri and so it is also not sent on to 4.4.4.4 as follows: > > Internet Protocol, Src: 1.1.1.1 (1.1.1.1), Dst: 2.2.2.2 (2.2.2.2) > > User Datagram Protocol, Src Port: sip (5060), Dst Port: sip (5060) > > BYE sip:[email protected]:5060 SIP/2.0 > Record-Route: <sip:1.1.1.1;lr=on;ftag=as1a75bb38> > Via: SIP/2.0/UDP 1.1.1.1;branch=z9hG4bK6be8.2fa52b26.0 > Via: SIP/2.0/UDP 3.3.3.3:5060;branch=z9hG4bK02874f97;rport=5060 > Route: <sip:2.2.2.2;lr=on;ftag=as1a75bb38> > From: "2222222222" <sip:[email protected]>;tag=as1a75bb38 > To: <sip:[email protected]>;tag=as5bd164c9 > Call-ID: [email protected] > CSeq: 103 BYE > User-Agent: Asterisk PBX > Max-Forwards: 69 > Reason: Q.850 ;cause=16; text="Normal Clearing" > X-Asterisk-HangupCauseCode: 16 > Content-Length: 0 > > I believe we would have been able to fix this issue by using the > dialoq module on both servers, but I do not know much about the dialog > module yet, and unfortunately we have no control over one of the > opensips servers. i also thought of trying to use the b2bua modules on > just our server, but once again i will first need to learn more about > those, but for now, we have managed to create a workaround whereby we > rewrite the ruri for all acks, byes and cancels with the ip retrieved > from the location table (using avp_db_query), which seems to be > working, for now. I hope to find a more reliable fix. > > Thanks for the help. > Bruce > > > ------------------------------------------------------------------------ > *From:* Bogdan-Andrei Iancu <[email protected]> > *To:* OpenSIPS users mailling list <[email protected]> > *Sent:* Tue, 18 May, 2010 17:54:01 > *Subject:* Re: [OpenSIPS-Users] In dialog requests misrouted > > Hi Bruce, > > The ACK for a 200OK is routed based on the route set - this the RR set + > the contact of the other party. So, the ACK will have in RURI the > contact of the other party (from 200 OK) and the RR set as Route hdrs. > > Regards, > Bogdan > > Bruce Borrett wrote: > > Hi > > > > We are trying to migrate from an SBC to Opensips 1.6. When we are > > sending calls to another provider who are using Openser, they are not > > taking the contact address from our 200 replies, instead they are > > putting our Openser address in the RURI of all Acks, Byes and Cancels. > > Am I right in saying that this is incorrect? Im not sure where they > > are getting this address either, maybe from the To: field, or from the > > record route header? > > > > Is there a way to match the message received to a transaction and > > route the message to the contact in the original invite stored by TM? > > Or perhaps some better way of solving this? > > > > Here are the messages: > > > > SIP/2.0 200 OK > > Via: SIP/2.0/UDP > > > xx.xxx.0.33;rport=5060;received=41.221.0.33;branch=z9hG4bKb9fc.f1cf4e03.0 > > Via: SIP/2.0/UDP xx.xxx.0.42:5060;branch=z9hG4bK3d3a5800;rport=5060 > > Record-Route: <sip:xx.xxx.1.13;lr=on;ftag=as5e3b3ce0> > > Record-Route: <sip:xx.xxx.0.33;lr=on;ftag=as5e3b3ce0> > > From: "xxxxxxx7239" <sip:[email protected] > <mailto:[email protected]>.0.42>;tag=as5e3b3ce0 > > To: <sip:[email protected] > <mailto:[email protected]>.1.13>;tag=as33b0f85f > > Call-ID: [email protected] > <mailto:[email protected]>.0.42 > > CSeq: 102 INVITE > > User-Agent: Asterisk PBX 1.6.0.9 > > Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY > > Supported: replaces, timer > > Contact: <sip:[email protected] <mailto:[email protected]>.236.105> > > Content-Type: application/sdp > > Content-Length: 290 > > > > > > ACK sip:[email protected] <mailto:[email protected]>.1.13:5060 SIP/2.0 > > Record-Route: <sip:xx.xxx.0.33;lr=on;ftag=as5e3b3ce0> > > Via: SIP/2.0/UDP xx.xxx.0.33;branch=z9hG4bKb9fc.f1cf4e03.2 > > Via: SIP/2.0/UDP xx.xxx.0.42:5060;branch=z9hG4bK5e0350ba;rport=5060 > > Route: <sip:xx.xxx.1.13;lr=on;ftag=as5e3b3ce0> > > From: "xxxxxxx7239" <sip:[email protected] > <mailto:[email protected]>.0.42>;tag=as5e3b3ce0 > > To: <sip:[email protected] > <mailto:[email protected]>.1.13>;tag=as33b0f85f > > Contact: <sip:[email protected] <mailto:[email protected]>.0.42> > > Call-ID: [email protected] > <mailto:[email protected]>.0.42 > > CSeq: 102 ACK > > User-Agent: Asterisk PBX > > Max-Forwards: 69 > > Content-Length: 0 > > > > Thank you very much in advance.. > > Bruce > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > Users mailing list > > [email protected] <mailto:[email protected]> > > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > > > -- > Bogdan-Andrei Iancu > www.voice-system.ro > > > _______________________________________________ > Users mailing list > [email protected] <mailto:[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 > -- Bogdan-Andrei Iancu www.voice-system.ro _______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
