Hi Bruce, Bruce Borrett wrote: > Hi Bogdan > > Just to complicate things a bit, 4.4.4.4 is the public ip of the nated > device... I made a mistake in my trace where I changed the contact > address in the initial 200 (from 4.4.4.4), it should have been the > nated ip, 5.5.5.5 for example... So you will see then that 2 is in > fact fixing the contact, but 1 is then fixing it again... why 2 is doing again? if you see a public IP (like 4) in contact, do not fix it again! > > For now we have managed to create a workaround whereby we perform a > "lookup location" on any acks, cancels or byes received from 1.1.1.1, > this function fixes the ruri to the correct one from the location > table, and sends it out correctly. This seems to be working fine so far... yeah, but it is really a ugly hack that my break SIP routing - ACK is a sequential request and must be routed contact + route set only.
Regards, Bogdan > > Thank you for your help, > > Regards, > Bruce > > > ------------------------------------------------------------------------ > *From:* Bogdan-Andrei Iancu <[email protected]> > *To:* OpenSIPS users mailling list <[email protected]> > *Sent:* Fri, 21 May, 2010 12:57:37 > *Subject:* Re: [OpenSIPS-Users] In dialog requests misrouted > > 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] > <mailto:[email protected]>> > > *To:* OpenSIPS users mailling list <[email protected] > <mailto:[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]> > > <mailto:[email protected] > <mailto:[email protected]>>.0.42>;tag=as5e3b3ce0 > > > To: <sip:[email protected] <mailto:[email protected]> > > <mailto:[email protected] > <mailto:[email protected]>>.1.13>;tag=as33b0f85f > > > Call-ID: [email protected] > <mailto:[email protected]> > > <mailto:[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]> > <mailto:[email protected] <mailto:[email protected]>>.236.105> > > > Content-Type: application/sdp > > > Content-Length: 290 > > > > > > > > > ACK sip:[email protected] <mailto:[email protected]> > <mailto:[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]> > > <mailto:[email protected] > <mailto:[email protected]>>.0.42>;tag=as5e3b3ce0 > > > To: <sip:[email protected] <mailto:[email protected]> > > <mailto:[email protected] > <mailto:[email protected]>>.1.13>;tag=as33b0f85f > > > Contact: <sip:[email protected] <mailto:[email protected]> > <mailto:[email protected] <mailto:[email protected]>>.0.42> > > > Call-ID: [email protected] > <mailto:[email protected]> > > <mailto:[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 -- Bogdan-Andrei Iancu www.voice-system.ro _______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
