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 cc’s 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.