18 Nov
2004
18 Nov
'04
10:07 p.m.
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(a)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(a)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(a)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(a)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
18 Nov
18 Nov
11:01 p.m.
On Nov 18, 2004 at 13:07, Java Rockx <javarockx(a)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
11:39 p.m.
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(a)fokus.fraunhofer.de> wrote:
On Nov 18, 2004 at 13:07, Java Rockx
<javarockx(a)yahoo.com> wrote:
__________________________________
Do you Yahoo!?
Meet the all-new My Yahoo! - Try it today!
http://my.yahoo.com
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
7123
days inactive
7123
days old
2 comments
2 participants
participants (2)
-
Andrei Pelinescu-Onciul -
Java Rockx