Hi All.
One last thing, is I had a STUN server set whereas on earlier attempts I did not have stun. I'm using nathelper and rtpproxy so I'm trying to avoid STUN, but it appears for some reason SER correctly adds the "Route:" header only when using a STUN server with my Grandstream phone.
Can anyone shed some light on why this might be?
Regards, Paul
--- Java Rockx javarockx@yahoo.com wrote:
I may have stumbled upon the root of the problem and a solution.
In my ser.cfg I have
if (!method=="INVITE") record-route();
And my phone is a Grandstream BT100. I did not have anything in my "Outbound Proxy" field because I assumed that omitting this field would default the phone to use the ser proxy as the outbound proxy.
I now see that this is not the case. When my outbound proxy field was left blank my ACK looked like this:
NOTE: These ACKs are originating at my ser proxy and being sent to the Sonus equipment.
U 2004/11/18 02:19:05.789518 66.40.100.99:5060 -> 216.12.18.98:5060 ACK sip:216.12.18.98:5060;lr SIP/2.0. Via: SIP/2.0/UDP 66.40.100.99;branch=0. Via: SIP/2.0/UDP 172.16.1.34;rport=5060;received=66.90.50.230;branch=z9hG4bK0cf6f59ad9cff263. From: "Paul Hazlett" sip:9990010005@sip.mycompany.com;user=phone;tag=153be9cfe0227ba6. To: sip:14075551212@sip.mycompany.com;user=phone;tag=0bc2b91b. Contact: sip:9990010005@66.90.50.230:5060;user=phone. Proxy-Authorization: DIGEST username="9990010005", realm="sip.mycompany.com", algorithm=MD5, uri="sip:4075551212@216.12.18.98:5060", nonce="419c4e0f62b492f993917bb283d89431c978b522", response="4dd7cb5d0e06a50c24d3a4848f57f1ad". Call-ID: 2fe29b9654abc94f@172.16.1.34. CSeq: 16138 ACK. User-Agent: Grandstream BT100 1.0.5.11. Max-Forwards: 16. Allow: INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE. Content-Length: 0.
Now with my outbound proxy field set to the same value as my sip proxy I get this ACK -- notice the Route: header??? The Sonus equipment now seems to be happy.
U 2004/11/18 02:29:47.505321 66.40.100.99:5060 -> 216.12.18.98:5060 ACK sip:4075551212@216.229.118.76:4060 SIP/2.0. Via: SIP/2.0/UDP 66.40.100.99;branch=0. Via: SIP/2.0/UDP 66.90.50.230;branch=z9hG4bKd14abbdd801339a6. Route: sip:216.12.18.98:5060;lr. From: "Paul Hazlett" sip:9990010005@sip.mycompany.com;user=phone;tag=343704cb47bd81b2. To: sip:14075551212@sip.mycompany.com;user=phone;tag=06c57864. Contact: sip:9990010005@66.90.50.230;user=phone. Proxy-Authorization: DIGEST username="9990010005", realm="sip.mycompany.com", algorithm=MD5, uri="sip:4075551212@216.229.118.76:4060", nonce="419c50915314f17ec7beef27579c4fc2ccfba7ed", response="6cde7461dfde9e0a7327fa1a20f47fb0". Call-ID: f211021ad0a34a37@172.16.1.34. CSeq: 3685 ACK. User-Agent: Grandstream BT100 1.0.5.11. Max-Forwards: 16. Allow: INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE. Content-Length: 0.
--- Java Rockx javarockx@yahoo.com wrote:
Ranga,
Yes, in my ser.cfg script I have
if (!method=="REGISTER") record-route();
I think there is plenty of confusion in the serusers list about wheather or not this is
correct.
Most of the example ser.cfg files I've seen, including those that sip with ser, show this
rather
than
if (!method=="INVITE") record-route();
Can anyone say which method is more RFC3261 compliant?
Also, I can't say wheather or not changing my ser.cfg to the latter will fix the problems that our PSTN provider has with our SIP dialogs. I'll find that out in the morning.
Regards, Paul
--- Ranga rangarao.v@gmail.com wrote:
U 2004/11/17 14:59:59.255342 68.80.200.100:1063 -> 68.80.201.101:5060 ACK sip:4075551212@216.229.127.60:5060 SIP/2.0. Via: SIP/2.0/UDP 192.168.0.83;branch=z9hG4bKe15e695c98bd9cb0. Route: sip:68.80.201.101;ftag=4edd147cdac0025f;lr=on. Route: sip:216.229.127.60:5060;lr. From: "Paul (1002)" sip:9990010001@sip.mycompany.com;user=phone;tag=4edd147cdac0025f. To: sip:14075551212@sip.mycompany.com;user=phone;tag=0bf5212d. Contact: sip:9990010001@192.168.0.83;user=phone. Proxy-Authorization: DIGEST username="9990010001", realm="sip.mycompany.com",
algorithm=MD5,
uri="sip:4075551212@216.229.127.60:5060", nonce="419baee2139477c22db6d0ec9a47b23003512431", response="7b83435f78bc60f5ced80304c7d54093".
Call-ID: aa31202374f54793@192.168.0.83. CSeq: 12010 ACK. User-Agent: Grandstream BT100 1.0.5.11. Max-Forwards: 70. Allow: INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE. Content-Length: 0. . # U 2004/11/17 14:59:59.255737 68.80.201.101:5060 -> 216.229.127.60:5060 ACK sip:216.229.127.60:5060;lr SIP/2.0. Record-Route: sip:68.80.201.101;ftag=4edd147cdac0025f;lr=on. Via: SIP/2.0/UDP 68.80.201.101;branch=0. Via: SIP/2.0/UDP
192.168.0.83;rport=1063;received=68.80.200.100;branch=z9hG4bKe15e695c98bd9cb0.
From: "Paul (1002)" sip:9990010001@sip.mycompany.com;user=phone;tag=4edd147cdac0025f. To: sip:14075551212@sip.mycompany.com;user=phone;tag=0bf5212d. Contact: sip:9990010001@68.80.200.100:1063;user=phone. Proxy-Authorization: DIGEST username="9990010001", realm="sip.mycompany.com",
algorithm=MD5,
uri="sip:4075551212@216.229.127.60:5060", nonce="419baee2139477c22db6d0ec9a47b23003512431", response="7b83435f78bc60f5ced80304c7d54093".
Call-ID: aa31202374f54793@192.168.0.83. CSeq: 12010 ACK. User-Agent: Grandstream BT100 1.0.5.11. Max-Forwards: 16. Allow: INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE. Content-Length: 0. . #
I guess, you are doing record-route for ACK also. IMO, you should not add record route headers for ACK.
I am not sure why Route header is completely removed from the request. Proxy is supposed to delete only the top route value.
-Ranga
__________________________________ Do you Yahoo!? The all-new My Yahoo! - Get yours free! http://my.yahoo.com
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
__________________________________ Do you Yahoo!? Meet the all-new My Yahoo! - Try it today! http://my.yahoo.com
__________________________________ Do you Yahoo!? The all-new My Yahoo! - Get yours free! http://my.yahoo.com