[OpenSIPS-Users] In dialog requests misrouted
Bogdan-Andrei Iancu
bogdan at voice-system.ro
Tue May 25 21:28:02 CEST 2010
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 <bogdan at voice-system.ro>
> *To:* OpenSIPS users mailling list <users at lists.opensips.org>
> *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:1111111111 at 2.2.2.2 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:2222222222 at 3.3.3.3>;tag=as1a75bb38
> > To: <sip:1111111111 at 2.2.2.2>
> > Contact: <sip:2222222222 at 3.3.3.3>
> > Call-ID: 7a98e4540899dde2053dc8a11cee1a04 at 3.3.3.3
> > 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:1111111111 at 4.4.4.4 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:2222222222 at 3.3.3.3>;tag=as1a75bb38
> > To: <sip:1111111111 at 2.2.2.2>
> > Contact: <sip:2222222222 at 3.3.3.3>
> > Call-ID: 7a98e4540899dde2053dc8a11cee1a04 at 3.3.3.3
> > 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:2222222222 at 3.3.3.3>;tag=as1a75bb38
> > To: <sip:1111111111 at 2.2.2.2>;tag=as5bd164c9
> > Call-ID: 7a98e4540899dde2053dc8a11cee1a04 at 3.3.3.3
> > 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:1111111111 at 4.4.4.4>
> > 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:2222222222 at 3.3.3.3>;tag=as1a75bb38
> > To: <sip:1111111111 at 2.2.2.2>;tag=as5bd164c9
> > Call-ID: 7a98e4540899dde2053dc8a11cee1a04 at 3.3.3.3
> > 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:1111111111 at 4.4.4.4>
> > 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:1111111111 at 2.2.2.2: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:2222222222 at 3.3.3.3>;tag=as1a75bb38
> > To: <sip:1111111111 at 2.2.2.2>;tag=as5bd164c9
> > Contact: <sip:2222222222 at 3.3.3.3>
> > Call-ID: 7a98e4540899dde2053dc8a11cee1a04 at 3.3.3.3
> > 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:1111111111 at 2.2.2.2: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:2222222222 at 3.3.3.3>;tag=as1a75bb38
> > To: <sip:1111111111 at 2.2.2.2>;tag=as5bd164c9
> > Call-ID: 7a98e4540899dde2053dc8a11cee1a04 at 3.3.3.3
> > 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 <bogdan at voice-system.ro
> <mailto:bogdan at voice-system.ro>>
> > *To:* OpenSIPS users mailling list <users at lists.opensips.org
> <mailto:users at lists.opensips.org>>
> > *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:xxxxxxx7239 at xx.xxx
> <mailto:xxxxxxx7239 at xx.xxx>
> > <mailto:xxxxxxx7239 at xx.xxx
> <mailto:xxxxxxx7239 at xx.xxx>>.0.42>;tag=as5e3b3ce0
> > > To: <sip:xxxxxx0114 at xx.xxx <mailto:xxxxxx0114 at xx.xxx>
> > <mailto:xxxxxx0114 at xx.xxx
> <mailto:xxxxxx0114 at xx.xxx>>.1.13>;tag=as33b0f85f
> > > Call-ID: 4b3419c86b29e5ce5a387a1b74f7effc at xx.xxx
> <mailto:4b3419c86b29e5ce5a387a1b74f7effc at xx.xxx>
> > <mailto:4b3419c86b29e5ce5a387a1b74f7effc at xx.xxx
> <mailto:4b3419c86b29e5ce5a387a1b74f7effc at xx.xxx>>.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:xxxxxxx0114 at xx.xxx <mailto:xxxxxxx0114 at xx.xxx>
> <mailto:xxxxxxx0114 at xx.xxx <mailto:xxxxxxx0114 at xx.xxx>>.236.105>
> > > Content-Type: application/sdp
> > > Content-Length: 290
> > >
> > >
> > > ACK sip:xxxxxx0114 at xx.xxx <mailto:xxxxxx0114 at xx.xxx>
> <mailto:xxxxxx0114 at xx.xxx <mailto:xxxxxx0114 at xx.xxx>>.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:xxxxxxx7239 at xx.xxx
> <mailto:xxxxxxx7239 at xx.xxx>
> > <mailto:xxxxxxx7239 at xx.xxx
> <mailto:xxxxxxx7239 at xx.xxx>>.0.42>;tag=as5e3b3ce0
> > > To: <sip:xxxxxx0114 at xx.xxx <mailto:xxxxxx0114 at xx.xxx>
> > <mailto:xxxxxx0114 at xx.xxx
> <mailto:xxxxxx0114 at xx.xxx>>.1.13>;tag=as33b0f85f
> > > Contact: <sip:xxxxxx7239 at xx.xxx <mailto:xxxxxx7239 at xx.xxx>
> <mailto:xxxxxx7239 at xx.xxx <mailto:xxxxxx7239 at xx.xxx>>.0.42>
> > > Call-ID: 4b3419c86b29e5ce5a387a1b74f7effc at xx.xxx
> <mailto:4b3419c86b29e5ce5a387a1b74f7effc at xx.xxx>
> > <mailto:4b3419c86b29e5ce5a387a1b74f7effc at xx.xxx
> <mailto:4b3419c86b29e5ce5a387a1b74f7effc at xx.xxx>>.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
More information about the Users
mailing list