18 Nov
2004
18 Nov
'04
9:56 a.m.
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(a)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(a)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(a)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(a)yahoo.com> wrote:
__________________________________
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
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(a)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(a)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".
__________________________________
Do you Yahoo!?
The all-new My Yahoo! - Get yours free!
http://my.yahoo.com
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
Call-ID: aa31202374f54793(a)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