Kevin,
I initially sent the packet:
This is that packet that came from the last 200 OK <- PROXY:
# U 2003/02/24 07:56:52.503535 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-ng5tokyx448r. From: "snom man" sip:4695461245@augustvoice.net;tag=8u6ju8wxuc. To: sip:2143357976@augustvoice.net;user=phone;tag=3CBB0360-532. Date: Mon, 24 Feb 2003 13:56:43 GMT. Call-ID: 3c267202b6a8-lgseu8olovlp@216.87.145.22. Server: Cisco-SIPGateway/IOS-12.x. CSeq: 2 INVITE. Session-Expires: 7200;refresher=uac. Require: timer. Allow-Events: telephone-event. Contact: sip:92143357976@216.87.144.196:5060;user=phone. Record-Route: sip:2143357976@216.87.144.203;ftag=8u6ju8wxuc;lr. Content-Type: application/sdp. Content-Length: 209. . v=0. o=CiscoSystemsSIP-GW-UserAgent 7543 5694 IN IP4 216.87.144.196. s=SIP Call. c=IN IP4 216.87.144.196. t=0 0. m=audio 16632 RTP/AVP 0 100. a=rtpmap:0 PCMU/8000. a=rtpmap:100 X-NSE/8000. a=fmtp:100 192-194.
This is the 200 OK (response to the INVITE) message as delivered to the phone.
I couldn't figure out what you were saying, so I went back to the ethereal trace. After the snom phone receives a 183 status message, it sends a PRACK to the PROXY. This PRACK is OKed, without a Record-route. The next message is an OK responding to the original INVITE, which does indeed have a Record-Route.
So, you are saying that the OK to your PRACK needs a record route? I can do that I think, because the OK to the INVITE does indeed have a Record-route.
I don't even know what a PRACK is for...
---greg
-----Original Message----- From: Kevin [mailto:kmoroz@abpintl.com] Sent: Monday, March 03, 2003 5:19 PM To: Greg Fausak Cc: 'Robert Messer' Subject: FW: Snom phone (fwd)
Hi Greg,
Sorry it took so long to get back to you. Normally it is faster but as I stated the SIP inter- operability was last week which caused the delay. Looks like the issue is with the SER proxy. If I knew the specification deeper I should have been able to answer it myself. Engineering ccs Jiri on their response to me so he is aware of the issue.
Regards,
Kevin
-----Original Message-----
The phone updates the route until it receives a 2xx code. The 200 Ok response does not contain such a route therefore the phone uses the last route it receives in the 200 which is empty. Therefore, the phone MUST send the ACK directly to the gateway.
§ 12.1.2 of the RFC3261. The dialog is NOT established by the 401-challened request.
The proxy can very easily solve the problem by putting itself into the routing path of the 200 Ok.