Hi All.
I'm using dev12 with nathelper and rtpproxy. I'm interfacing with a company that uses Sonus equipment to terminate to the PSTN. This company is telling me that SER is not performing to RFC3261 because ACK messages are not including any "Route:" headers as stated in section 12.1.2.
Following is an email I recieved from their network engineers. Attached is also a partial conversation between my SER proxy and their Sonus box. The actual problem is that Sonus disconnects the call after a few seconds because of this ACK routing issue.
+++++++++START OF EMAIL FROM THE GUYS USING SONUS++++++++++++++ No, this is definitely not a Sonus issue.
The response sent from the Sonus to the SER contains the correct set of Record-Route (every hop that the original INVITE has traversed). When the SER sends back the ACK, the SER if it acts as a UAC, then must include this set of Record-Route as Route in the message per RFC3261 section 12.1.2.
I believe you will have problem with this if you interface the SER with any SIP proxy. I assume that it works with Broadvox because you are connected directly to their gateway and no other proxy is in between. If you were to connect directly with the Sonus, then it would work.
The problem should be fixed on your end. You just need to look into the code where it generates the ACK and follow RFC3261 section 12.1.2 on how to build and send it. +++++++++END OF EMAIL FROM THE GUYS USING SONUS++++++++++++++
Here is the actual problem from a real SER/Sonus dialog.
We have a "200 OK" and two ACKs - The first ACK is good and the second ACK is bad because it should have a "Route:" header referring to the Sonus box.
NOTE: If I have STUN enabled on my SIP phone then SER works 100% fine. If STUN is not used on the SIP phone then the second ACK is messed up as shown here. So the ACK from SER to Sonus is incorrect. A working (corrected ACK) is at the very bottom of this message.
These are the bogus IP addresses shown in the dialog: 100.99.99.99.99 is my SER proxy 100.10.10.10 is the public side of my firewall 216.50.50.50 is the ip of the Sonus box
U 2004/11/18 14:13:08.419098 100.99.99.99:5060 -> 100.10.10.10:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP 192.168.0.83;rport=5060;received=100.10.10.10;branch=z9hG4bKa70081ccdd52daf0. To: sip:14075551212@sip.mycompany.com;user=phone;tag=069c9797. From: "Paul (1002)" sip:9990010001@sip.mycompany.com;user=phone;tag=92691bb29380c100. Call-ID: e37c04be3e50ea72@192.168.0.83. CSeq: 21752 INVITE. Contact: sip:4075551212@216.50.50.50:5060. Record-Route: sip:216.50.50.50:5060;lr. Record-Route: sip:100.99.99.99;ftag=92691bb29380c100;lr=on. Accept: multipart/mixed, application/sdp, application/isup, application/dtmf, application/dtmf-relay. Allow: OPTIONS, INVITE, CANCEL, ACK, BYE, PRACK, INFO. Supported: timer. Content-Disposition: session;handling=required. Content-Type: application/sdp. Session-Expires: 240;refresher=uas. Content-Length: 244. . v=0. o=Sonus_UAC 18748 26881 IN IP4 216.229.118.76. s=SIP Media Capabilities. c=IN IP4 100.99.99.99. t=0 0. m=audio 35552 RTP/AVP 18 101. a=rtpmap:18 G729/8000. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-15. a=sendrecv. a=nortpproxy:yes.
# U 2004/11/18 14:13:08.428394 100.10.10.10:5060 -> 100.99.99.99:5060 ACK sip:4075551212@216.50.50.50:5060 SIP/2.0. Via: SIP/2.0/UDP 192.168.0.83;branch=z9hG4bKf4bb608e498ec61d. Route: sip:100.99.99.99;ftag=92691bb29380c100;lr=on. Route: sip:216.50.50.50:5060;lr. From: "Paul (1002)" sip:9990010001@sip.mycompany.com;user=phone;tag=92691bb29380c100. To: sip:14075551212@sip.mycompany.com;user=phone;tag=069c9797. Contact: sip:9990010001@192.168.0.83;user=phone. Call-ID: e37c04be3e50ea72@192.168.0.83. CSeq: 21752 ACK. User-Agent: Grandstream BT100 1.0.5.16. Max-Forwards: 70. Allow: INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE. Content-Length: 0. .
# U 2004/11/18 14:13:08.429879 100.99.99.99:5060 -> 216.50.50.50:5060 ACK sip:216.50.50.50:5060;lr SIP/2.0. Via: SIP/2.0/UDP 100.99.99.99;branch=z9hG4bK2b35.552edb80cbf475b9be9ae3f9db23f960.0. Via: SIP/2.0/UDP 192.168.0.83;rport=5060;received=100.10.10.10;branch=z9hG4bKf4bb608e498ec61d. From: "Paul (1002)" sip:9990010001@sip.mycompany.com;user=phone;tag=92691bb29380c100. To: sip:14075551212@sip.mycompany.com;user=phone;tag=069c9797. Contact: sip:9990010001@100.10.10.10:5060;user=phone. Call-ID: e37c04be3e50ea72@192.168.0.83. CSeq: 21752 ACK. User-Agent: Grandstream BT100 1.0.5.16. Max-Forwards: 16. Allow: INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE. Content-Length: 0. .
+++++++++++++++The Second ACK Should Look Like This+++++++++++++++++++++++ U 2004/11/18 14:13:08.429879 100.99.99.99:5060 -> 216.50.50.50:5060 ACK sip:216.50.50.50:5060;lr SIP/2.0. Via: SIP/2.0/UDP 100.99.99.99;branch=z9hG4bK2b35.552edb80cbf475b9be9ae3f9db23f960.0. Via: SIP/2.0/UDP 192.168.0.83;rport=5060;received=100.10.10.10;branch=z9hG4bKf4bb608e498ec61d. Route: sip:216.50.50.50:5060;lr. From: "Paul (1002)" sip:9990010001@sip.mycompany.com;user=phone;tag=92691bb29380c100. To: sip:14075551212@sip.mycompany.com;user=phone;tag=069c9797. Contact: sip:9990010001@100.10.10.10:5060;user=phone. Call-ID: e37c04be3e50ea72@192.168.0.83. CSeq: 21752 ACK. User-Agent: Grandstream BT100 1.0.5.16. Max-Forwards: 16. Allow: INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE. Content-Length: 0.
Regards, Paul
__________________________________ Do you Yahoo!? The all-new My Yahoo! - Get yours free! http://my.yahoo.com
On Nov 18, 2004 at 13:07, Java Rockx javarockx@yahoo.com wrote:
Hi All.
I'm using dev12 with nathelper and rtpproxy. I'm interfacing with a company that uses Sonus equipment to terminate to the PSTN. This company is telling me that SER is not performing to RFC3261 because ACK messages are not including any "Route:" headers as stated in section 12.1.2.
Following is an email I recieved from their network engineers. Attached is also a partial conversation between my SER proxy and their Sonus box. The actual problem is that Sonus disconnects the call after a few seconds because of this ACK routing issue.
What's happening is you use as an alias the SONUS ip. This means ser will believe that the SONUS ip is his own. Because of this it will think the ACK uri ( user@sonus_ip) was a result of a strict router and will try to recover from the previous strict router. You can see the result :-) So remove alias=sonus_ip from your config. ser behaves as in RFC3261, it was just a little configuration error.
BTW: in you onreply_route, use fix_nated_contact only for replies for which nat_uac_test("1") is true and not for all replies to nated requests (important if you run into an asymmetric UA).
Andrei
THANK YOU!!!!!!
That was my problem. I don't remember why I had that there, but it was wrong.
If you're ever in Orlando Florida I'll buy you a pint.
Thanks again, Paul
--- Andrei Pelinescu-Onciul pelinescu-onciul@fokus.fraunhofer.de wrote:
On Nov 18, 2004 at 13:07, Java Rockx javarockx@yahoo.com wrote:
Hi All.
I'm using dev12 with nathelper and rtpproxy. I'm interfacing with a company that uses Sonus equipment to terminate to the PSTN. This company is telling me that SER is not performing to RFC3261 because ACK messages are not including any "Route:" headers as stated in section
12.1.2.
Following is an email I recieved from their network engineers. Attached is also a partial conversation between my SER proxy and their Sonus box. The actual problem is that Sonus disconnects the call after a few seconds because of this ACK routing issue.
What's happening is you use as an alias the SONUS ip. This means ser will believe that the SONUS ip is his own. Because of this it will think the ACK uri ( user@sonus_ip) was a result of a strict router and will try to recover from the previous strict router. You can see the result :-) So remove alias=sonus_ip from your config. ser behaves as in RFC3261, it was just a little configuration error.
BTW: in you onreply_route, use fix_nated_contact only for replies for which nat_uac_test("1") is true and not for all replies to nated requests (important if you run into an asymmetric UA).
Andrei
__________________________________ Do you Yahoo!? Meet the all-new My Yahoo! - Try it today! http://my.yahoo.com