4 Mar
2003
4 Mar
'03
4:47 a.m.
I copied a few SNOM phone messages to the list.
I am having problems communicating with the
SNOM phone.
I guess it isn't working because the SNOM phone
sends a PRACK after the 183, and the received
OK doesn't have a 'Record-Route'. This doesn't make
sense to me. I don't know why the phone is listening
to the first OK (the OK to the PRACK) rather than the
second OK (the OK to the INVITE).
If that is the way it is then do I have the PROXY mis-configured?
-----
if(method=="INVITE" | method=="BYE" |
method=="PRACK")
{
log(1,"TRACE: addRecordRoute()");
setflag(1);
setflag(2);
addRecordRoute();
};
append_hf("P-hint: ATEND\r\n");
if(!t_relay())
{
sl_reply_error();
break;
};
When I do a ngrep trace, I see the packet being relayed...
----
#
U 2003/03/03 20:05:59.858473 216.87.145.22:5060 -> 216.87.144.203:5060
PRACK sip:2143357976@216.87.144.203;branch=0 SIP/2.0.
Via: SIP/2.0/UDP 216.87.145.22:5060;branch=z9hG4bK-bec8z5qwsbqg.
Max-Forwards: 70.
RAck: 5620 2 INVITE.
From: "snom man" <sip:4695461245@augustvoice.net>;tag=1r1bpkl72i.
To: <sip:2143357976@augustvoice.net;user=phone>;tag=63631E34-197C.
Call-ID: 3c26f8de39d9-7dyvkrekeha3(a)216.87.145.22.
CSeq: 4 PRACK.
Route: <sip:92143357976@216.87.144.196:5060;user=phone>.
Contact: <sip:4695461245@216.87.145.22:5060;line=1>.
Content-Length: 0.
Authorization: Digest
username="4695461245",realm="augustvoice.net",nonce="3e640b3300000000dbb
edccd04f755cac7e3b6dd55d202c9",uri="sip:",response="3693b828395cd40fe1b1
ab5f9ad61308",algorithm=md5.
.
#
U 2003/03/03 20:05:59.859540 216.87.144.203:5060 -> 216.87.144.196:5060
PRACK sip:92143357976@216.87.144.196:5060;user=phone SIP/2.0.
Record-Route: <sip:2143357976@216.87.144.203;branch=0>.
Via: SIP/2.0/UDP 216.87.144.203;branch=z9hG4bKe44a.ff0091c4.0.
Via: SIP/2.0/UDP 216.87.145.22:5060;branch=z9hG4bK-bec8z5qwsbqg.
Max-Forwards: 69.
RAck: 5620 2 INVITE.
From: "snom man" <sip:4695461245@augustvoice.net>;tag=1r1bpkl72i.
To: <sip:2143357976@augustvoice.net;user=phone>;tag=63631E34-197C.
Call-ID: 3c26f8de39d9-7dyvkrekeha3(a)216.87.145.22.
CSeq: 4 PRACK.
Contact: <sip:4695461245@216.87.145.22:5060;line=1>.
Content-Length: 0.
Authorization: Digest
username="4695461245",realm="augustvoice.net",nonce="3e640b3300000000dbb
edccd04f755cac7e3b6dd55d202c9",uri="sip:",response="3693b828395cd40fe1b1
ab5f9ad61308",algorithm=md5.
P-hint: ATEND.
.
#
U 2003/03/03 20:05:59.861477 216.87.144.196:5060 -> 216.87.144.203:5060
SIP/2.0 200 OK.
Via: SIP/2.0/UDP
216.87.144.203;branch=z9hG4bKe44a.ff0091c4.0,SIP/2.0/UDP
216.87.145.22:5060;branch=z9hG4bK-bec8z5qwsbqg.
From: "snom man" <sip:4695461245@augustvoice.net>;tag=1r1bpkl72i.
To: <sip:2143357976@augustvoice.net;user=phone>;tag=63631E34-197C.
Date: Tue, 04 Mar 2003 02:05:59 GMT.
Call-ID: 3c26f8de39d9-7dyvkrekeha3(a)216.87.145.22.
Server: Cisco-SIPGateway/IOS-12.x.
CSeq: 4 PRACK.
Content-Length: 0.
.
#
U 2003/03/03 20:05:59.861705 216.87.144.203:5060 -> 216.87.145.22:5060
SIP/2.0 200 OK.
Via:SIP/2.0/UDP 216.87.145.22:5060;branch=z9hG4bK-bec8z5qwsbqg.
From: "snom man" <sip:4695461245@augustvoice.net>;tag=1r1bpkl72i.
To: <sip:2143357976@augustvoice.net;user=phone>;tag=63631E34-197C.
Date: Tue, 04 Mar 2003 02:05:59 GMT.
Call-ID: 3c26f8de39d9-7dyvkrekeha3(a)216.87.145.22.
Server: Cisco-SIPGateway/IOS-12.x.
CSeq: 4 PRACK.
Content-Length: 0.
.
-----
There is a Record-route going out, but not one coming back.
Does a Record-route need to be injected into the last
OK back to the UA?
This is too hard :-)
---greg
4 Mar
4 Mar
7:42 p.m.
Greg,
the email exchange was too fast for me -- is there any open issue now
for which snom does not claim responsibility and the burden is on us?
-Jiri
At 03:47 AM 3/4/2003, Greg Fausak wrote:
I copied a few SNOM phone messages to the list.
I am having problems communicating with the
SNOM phone.
I guess it isn't working because the SNOM phone
sends a PRACK after the 183, and the received
OK doesn't have a 'Record-Route'. This doesn't make
sense to me. I don't know why the phone is listening
to the first OK (the OK to the PRACK) rather than the
second OK (the OK to the INVITE).
If that is the way it is then do I have the PROXY mis-configured?
-----
if(method=="INVITE" | method=="BYE" |
method=="PRACK")
{
log(1,"TRACE: addRecordRoute()");
setflag(1);
setflag(2);
addRecordRoute();
};
append_hf("P-hint: ATEND\r\n");
if(!t_relay())
{
sl_reply_error();
break;
};
When I do a ngrep trace, I see the packet being relayed...
----
#
U 2003/03/03 20:05:59.858473 216.87.145.22:5060 -> 216.87.144.203:5060
PRACK sip:2143357976@216.87.144.203;branch=0 SIP/2.0.
Via: SIP/2.0/UDP 216.87.145.22:5060;branch=z9hG4bK-bec8z5qwsbqg.
Max-Forwards: 70.
RAck: 5620 2 INVITE.
From: "snom man" <sip:4695461245@augustvoice.net>;tag=1r1bpkl72i.
To: <sip:2143357976@augustvoice.net;user=phone>;tag=63631E34-197C.
Call-ID: 3c26f8de39d9-7dyvkrekeha3(a)216.87.145.22.
CSeq: 4 PRACK.
Route: <sip:92143357976@216.87.144.196:5060;user=phone>.
Contact: <sip:4695461245@216.87.145.22:5060;line=1>.
Content-Length: 0.
Authorization: Digest
username="4695461245",realm="augustvoice.net",nonce="3e640b3300000000dbb
edccd04f755cac7e3b6dd55d202c9",uri="sip:",response="3693b828395cd40fe1b1
ab5f9ad61308",algorithm=md5.
.
#
U 2003/03/03 20:05:59.859540 216.87.144.203:5060 -> 216.87.144.196:5060
PRACK sip:92143357976@216.87.144.196:5060;user=phone SIP/2.0.
Record-Route: <sip:2143357976@216.87.144.203;branch=0>.
Via: SIP/2.0/UDP 216.87.144.203;branch=z9hG4bKe44a.ff0091c4.0.
Via: SIP/2.0/UDP 216.87.145.22:5060;branch=z9hG4bK-bec8z5qwsbqg.
Max-Forwards: 69.
RAck: 5620 2 INVITE.
From: "snom man" <sip:4695461245@augustvoice.net>;tag=1r1bpkl72i.
To: <sip:2143357976@augustvoice.net;user=phone>;tag=63631E34-197C.
Call-ID: 3c26f8de39d9-7dyvkrekeha3(a)216.87.145.22.
CSeq: 4 PRACK.
Contact: <sip:4695461245@216.87.145.22:5060;line=1>.
Content-Length: 0.
Authorization: Digest
username="4695461245",realm="augustvoice.net",nonce="3e640b3300000000dbb
edccd04f755cac7e3b6dd55d202c9",uri="sip:",response="3693b828395cd40fe1b1
ab5f9ad61308",algorithm=md5.
P-hint: ATEND.
.
#
U 2003/03/03 20:05:59.861477 216.87.144.196:5060 -> 216.87.144.203:5060
SIP/2.0 200 OK.
Via: SIP/2.0/UDP
216.87.144.203;branch=z9hG4bKe44a.ff0091c4.0,SIP/2.0/UDP
216.87.145.22:5060;branch=z9hG4bK-bec8z5qwsbqg.
From: "snom man" <sip:4695461245@augustvoice.net>;tag=1r1bpkl72i.
To: <sip:2143357976@augustvoice.net;user=phone>;tag=63631E34-197C.
Date: Tue, 04 Mar 2003 02:05:59 GMT.
Call-ID: 3c26f8de39d9-7dyvkrekeha3(a)216.87.145.22.
Server: Cisco-SIPGateway/IOS-12.x.
CSeq: 4 PRACK.
Content-Length: 0.
.
#
U 2003/03/03 20:05:59.861705 216.87.144.203:5060 -> 216.87.145.22:5060
SIP/2.0 200 OK.
Via:SIP/2.0/UDP 216.87.145.22:5060;branch=z9hG4bK-bec8z5qwsbqg.
From: "snom man" <sip:4695461245@augustvoice.net>;tag=1r1bpkl72i.
To: <sip:2143357976@augustvoice.net;user=phone>;tag=63631E34-197C.
Date: Tue, 04 Mar 2003 02:05:59 GMT.
Call-ID: 3c26f8de39d9-7dyvkrekeha3(a)216.87.145.22.
Server: Cisco-SIPGateway/IOS-12.x.
CSeq: 4 PRACK.
Content-Length: 0.
.
-----
There is a Record-route going out, but not one coming back.
Does a Record-route need to be injected into the last
OK back to the UA?
This is too hard :-)
---greg
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
--
Jiri Kuthan http://iptel.org/~jiri/
5 Mar
5 Mar
12:27 a.m.
Jiri,
Yes, it was kinda quick.
I have been living and breathing SIP for the
last several weeks. Issues come and go in hours :-)
I'll recount what is up:
Ten days ago I sent an email to you, to which
you kindly responded, about the SNOM (apparent) inability to
process Record-routes correctly. Your response was
The record-route is there, SNOM needs to do what it says.
I forwarded your response to SNOM, and I
got a reply yesterday (something about all engineers
being at SIPIT).
Yesterday they responded with 'the SNOM phone receives
an OK from the PROXY server, and that OK does not include
the Record-route, therefore, the SNOM phone is compelled
to respond directly to the originating gateway'.
The actual exchange between the SNOM phone and the PROXY:
INVITE -> *
401 Unauthorized <- *
ACK -> *
INVITE (with credentials) -> *
100 Trying <- *
183 Ringing <-
PRACK -> *
200 OK <- * (this is OK for the PRACK)
200 OK <-
This is where things get off track, the SNOM phone wants to send the
ACK to the GATEWAY instead of the PROXY. All of the messages
above that have an * means no record-route is present in the message.
What SNOM is saying is that the *first* OK from the PRACK sets up
Who to send the message back to....that doesn't make sense to me. The
*second* OK from the INVITE is that SNOM is responding to, so why don't
they
use the record-route that is in that message.
The long winded answer is yes, they think SER should be providing a
'Record-route' in the first OK.
At least this is what I understand.
Does all of that make sense to you?
I can send an ethereal dump if you want it.
---greg
-----Original Message-----
From: Jiri Kuthan [mailto:jiri@iptel.org]
Sent: Tuesday, March 04, 2003 11:42 AM
To: Greg Fausak; serusers(a)lists.iptel.org
Cc: sip(a)august.net
Subject: Re: [Serusers] PRACK
Greg,
the email exchange was too fast for me -- is there any open issue now
for which snom does not claim responsibility and the burden is on us?
-Jiri
At 03:47 AM 3/4/2003, Greg Fausak wrote:
I copied a few SNOM phone messages to the list.
I am having problems communicating with the
SNOM phone.
I guess it isn't working because the SNOM phone
sends a PRACK after the 183, and the received
OK doesn't have a 'Record-Route'. This doesn't make
sense to me. I don't know why the phone is listening
to the first OK (the OK to the PRACK) rather than the
second OK (the OK to the INVITE).
If that is the way it is then do I have the PROXY mis-configured?
-----
if(method=="INVITE" | method=="BYE" |
method=="PRACK")
{
log(1,"TRACE: addRecordRoute()");
setflag(1);
setflag(2);
addRecordRoute();
};
append_hf("P-hint: ATEND\r\n");
if(!t_relay())
{
sl_reply_error();
break;
};
When I do a ngrep trace, I see the packet being relayed...
----
#
U 2003/03/03 20:05:59.858473 216.87.145.22:5060 ->
216.87.144.203:5060
PRACK sip:2143357976@216.87.144.203;branch=0
SIP/2.0.
Via: SIP/2.0/UDP 216.87.145.22:5060;branch=z9hG4bK-bec8z5qwsbqg.
Max-Forwards: 70.
RAck: 5620 2 INVITE.
From: "snom man" <sip:4695461245@augustvoice.net>;tag=1r1bpkl72i.
To: <sip:2143357976@augustvoice.net;user=phone>;tag=63631E34-197C.
Call-ID: 3c26f8de39d9-7dyvkrekeha3(a)216.87.145.22.
CSeq: 4 PRACK.
Route: <sip:92143357976@216.87.144.196:5060;user=phone>.
Contact: <sip:4695461245@216.87.145.22:5060;line=1>.
Content-Length: 0.
Authorization: Digest
username="4695461245",realm="augustvoice.net",nonce="3e640b33
00000000dbb
edccd04f755cac7e3b6dd55d202c9",uri="sip:",response="3693b8283
95cd40fe1b1
ab5f9ad61308",algorithm=md5.
.
#
U 2003/03/03 20:05:59.859540 216.87.144.203:5060 ->
216.87.144.196:5060
PRACK
sip:92143357976@216.87.144.196:5060;user=phone SIP/2.0.
Record-Route: <sip:2143357976@216.87.144.203;branch=0>.
Via: SIP/2.0/UDP 216.87.144.203;branch=z9hG4bKe44a.ff0091c4.0.
Via: SIP/2.0/UDP 216.87.145.22:5060;branch=z9hG4bK-bec8z5qwsbqg.
Max-Forwards: 69.
RAck: 5620 2 INVITE.
From: "snom man" <sip:4695461245@augustvoice.net>;tag=1r1bpkl72i.
To: <sip:2143357976@augustvoice.net;user=phone>;tag=63631E34-197C.
Call-ID: 3c26f8de39d9-7dyvkrekeha3(a)216.87.145.22.
CSeq: 4 PRACK.
Contact: <sip:4695461245@216.87.145.22:5060;line=1>.
Content-Length: 0.
Authorization: Digest
username="4695461245",realm="augustvoice.net",nonce="3e640b33
00000000dbb
edccd04f755cac7e3b6dd55d202c9",uri="sip:",response="3693b8283
95cd40fe1b1
ab5f9ad61308",algorithm=md5.
P-hint: ATEND.
.
#
U 2003/03/03 20:05:59.861477 216.87.144.196:5060 ->
216.87.144.203:5060
SIP/2.0 200 OK.
Via: SIP/2.0/UDP
216.87.144.203;branch=z9hG4bKe44a.ff0091c4.0,SIP/2.0/UDP
216.87.145.22:5060;branch=z9hG4bK-bec8z5qwsbqg.
From: "snom man" <sip:4695461245@augustvoice.net>;tag=1r1bpkl72i.
To: <sip:2143357976@augustvoice.net;user=phone>;tag=63631E34-197C.
Date: Tue, 04 Mar 2003 02:05:59 GMT.
Call-ID: 3c26f8de39d9-7dyvkrekeha3(a)216.87.145.22.
Server: Cisco-SIPGateway/IOS-12.x.
CSeq: 4 PRACK.
Content-Length: 0.
.
#
U 2003/03/03 20:05:59.861705 216.87.144.203:5060 ->
216.87.145.22:5060
SIP/2.0 200 OK.
Via:SIP/2.0/UDP 216.87.145.22:5060;branch=z9hG4bK-bec8z5qwsbqg.
From: "snom man" <sip:4695461245@augustvoice.net>;tag=1r1bpkl72i.
To: <sip:2143357976@augustvoice.net;user=phone>;tag=63631E34-197C.
Date: Tue, 04 Mar 2003 02:05:59 GMT.
Call-ID: 3c26f8de39d9-7dyvkrekeha3(a)216.87.145.22.
Server: Cisco-SIPGateway/IOS-12.x.
CSeq: 4 PRACK.
Content-Length: 0.
.
-----
There is a Record-route going out, but not one coming back.
Does a Record-route need to be injected into the last
OK back to the UA?
This is too hard :-)
---greg
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
--
Jiri Kuthan http://iptel.org/~jiri/
1:07 a.m.
Greg,
thanks for updating me. I maintain ser is not guilty, snom is.
Replies bellow.
On Tue, 4 Mar 2003, Greg Fausak wrote:
[...]
INVITE -> *
401 Unauthorized <- *
ACK -> *
INVITE (with credentials) -> *
100 Trying <- *
183 Ringing <-
PRACK -> *
200 OK <- * (this is OK for the PRACK)
200 OK <-
This is where things get off track, the SNOM phone wants to send the
ACK to the GATEWAY instead of the PROXY. All of the messages
above that have an * means no record-route is present in the message.
What SNOM is saying is that the *first* OK from the PRACK sets up
Who to send the message back to....that doesn't make sense to me. The
*second* OK from the INVITE is that SNOM is responding to, so why don't
they
use the record-route that is in that message.
The long winded answer is yes, they think SER should be providing a
'Record-route' in the first OK.
Record-route is mirrored in replies from requests by phones, not by proxy
servers. If it is missing in replies to record-routed requests, it is
phone's fault.
The proper behaviour is imho as follows:
- INVITE is record-routed by proxy; 18x replies must mirror record-routes
(if they don't, it's phone's UAS bug)
- subsequent transactions must use route set learned from the INVITE
transaction; that means, PRACK should set Routes, and so should later
on the ACK too; (if that does not happen, it's phone's UAC bug)
So I think the snom-phone bugs encountered here are:
- route learned from INVITE 18x is not set for PRACK and ACK
- record-route is not mirrored in replies to PRACK
-Jiri
7936
days inactive
7937
days old
4 comments
3 participants
participants (3)
-
Greg Fausak -
jh＠lohi.eng.song.fi -
Jiri Kuthan