Subject: RE: [SIP] Contact in final INVITE response.

From: "Fairlie-Cuninghame, Robert" <[email-masked]>
Date: Tue, 18 Jul 2000 11:16:11 -0700

> 
> Let me summarize what you are trying to say here:
> 
> 1. a server sends a 4xx response
> 2. the UAC or proxy now needs to send an ACK
> 3. the 4xx response was sent with a source port the server is not
> listening on
> 4. the ACK will not be received by the server
> 
> I don't see why 4. follows, if that is what you are claiming. The ACK
> should be sent to the same address and port you sent the INVITE to.
> Obviously the server is listening there or it wouldn't have gotten the
> INVITE in the first place. So, the ACK will be received by the server.
> 
Thanks for the reply.

Sure, this is not a problem in the normal call flows (when you have that
information - ie, when you have cached state for the transaction) but there
is no way to respond to an error response you receive when you have no
cached transaction information.
Possible causes:
- Client crashes
- Client error which causes call state to be flushed (prehaps during to
handling of reinvite or CANCEL).
- Client does not cache original requests (for very long) after first ACK to
final response has been sent. [This is probably the most likely reason in
the field.] 

Admittedly, most of these cases result from implementation shortcuts (or
errors) but regardless of the cause, wouldn't it be more tidy from a
protocol point of view (in my mind) to be able to ACK to an error response
even when you don't have cached state for it. I think this should at the
very least to be "A sip URL MAY be added to Contact header of 4xx+ responses
(except for the pesky 485) to which the ACK should be sent"  - if not a
SHOULD or MUST.

Robert.

-- My opinions are my own. I tried selling them but everybody else 
	already seems to have one. --

_______________________________________________
SIP mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/sip

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 19 Jul 2000 01:04:43 -0400

> (except for the pesky 485) to which the ACK should be sent"  - if not a

Well, this wouldn't work for 3xx responses.

What you really want is a way to place state into a request, and get it
back in a response. There is already a way to do this - everyone's
favorite parameter - the Via branch ID. You could stick the request URI
+ Ip address/port in there when you forward the request. You could also
use a new via parameter instead.

-Jonathan R.
-- 
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com