[Serusers] Can someone (Jan, Jiri, Andrei, Bodgan, etc, etc) explain this?

Java Rockx javarockx at yahoo.com
Thu Nov 18 22:07:01 CET 2004


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 at sip.mycompany.com;user=phone>;tag=069c9797.
From: "Paul (1002)" <sip:9990010001 at sip.mycompany.com;user=phone>;tag=92691bb29380c100.
Call-ID: e37c04be3e50ea72 at 192.168.0.83.
CSeq: 21752 INVITE.
Contact: sip:4075551212 at 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 at 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 at sip.mycompany.com;user=phone>;tag=92691bb29380c100.
To: <sip:14075551212 at sip.mycompany.com;user=phone>;tag=069c9797.
Contact: <sip:9990010001 at 192.168.0.83;user=phone>.
Call-ID: e37c04be3e50ea72 at 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 at sip.mycompany.com;user=phone>;tag=92691bb29380c100.
To: <sip:14075551212 at sip.mycompany.com;user=phone>;tag=069c9797.
Contact: <sip:9990010001 at 100.10.10.10:5060;user=phone>.
Call-ID: e37c04be3e50ea72 at 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 at sip.mycompany.com;user=phone>;tag=92691bb29380c100.
To: <sip:14075551212 at sip.mycompany.com;user=phone>;tag=069c9797.
Contact: <sip:9990010001 at 100.10.10.10:5060;user=phone>.
Call-ID: e37c04be3e50ea72 at 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 
 




More information about the sr-users mailing list