4 Mar
2003
4 Mar
'03
2:12 a.m.
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(a)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.