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

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

Jo,

Forgive me, I wrote the statement backwards, I meant to say a number of
people were sending INVITE error responses from ports they were not
expecting the ACK to be sent to. [The ACK is sort of a response to the
response.] This is perfectly legal.

The received response will have a Via field that only has your own IP
address/hostname in it (which is of not use in routing the ACK). 

You seem to have worked out what I meant anyway. [Thank-you]

Yes the bis says something about error-information in 4xx,5xx,6xx but I
don't think this is necessarily mutually exclusive with putting a sip: URL
in there for ACK routing (as for 2xx). I don't think that a SIP URL
providing error-information for a SIP error is a good thing (although I'm
sure we can find some people to disagree).

Yes there is still a problem for 3xx & 485 Ambiguous but its better to fix
what can be fixed, right. Interestingly, if a redirect server is idempotent
in its routing then it can be stateless (ie, it wouldn't retransmit the
final response).

No, I'm sure 7 retransmissions wouldn't kill the network but it makes it
more difficult to diagnose real problems if you don't fix the "not-really"
real protocol problems, right?

Robert.

> -----Original Message-----
> From: Jo Hornsby [mailto:[email-masked]]
> Sent: Tuesday, July 18, 2000 5:23 PM
> To: Fairlie-Cuninghame, Robert; 'Jonathan Rosenberg'
> Cc: [email-masked]
> Subject: RE: [SIP] Contact in final INVITE response.
> 
> 
> > At the SuperOp interop testing I found that some implementations
> > were sending SIP messages from source ports that they did not
> > expect responses on.
> 
> I suspect this is not atypical, which is why the use of
> a received-port parameter in Vias is of dubious merit (there was
> some discussion about this a while back, as I remember).
> 
> > This is fine in itself but causes problems when
> > you receive final INVITE
> > responses that 
> > a) you do not have call state for (early teardown or crash 
> perhaps?).
> > b) and do not contain a Contact.
> 
> Interesting.
> 
> > Now for 2xx responses the RFC2543bis already says the a Contact
> > MUST be included so this is not an issue.
> > For 3xx responses the Contact has a different purpose.
> > 
> > But for error responses, there is no way to return the ACK to 
> > stop the final response retransmission. You can simply "guess" a
> > return address/port by simply sending it back to the where it can
> > from but that doesn't work in the situation above.
> 
> You are right in that it won't typically work for UDP, but you
> might get away with it over TCP.
> 
> > So, do we need to change this section to say that a Contact MUST 
> > be included in all 4xx,5xx,6xx responses as well? [It isn't possible
> > to say that a Contact is only a MUST if the source port cannot be
> > used for a return address.]
> 
> I recall some discussion a while back about using Contact to give
> some sort of "error information" in the case of 4xx, 5xx, 6xx; if
> you look in the most recent bis (July), there is also some wording
> to that affect.
> 
> Note that this aside, making Contact mandatory for 4xx, 5xx, 6xx
> doesn't solve all problems, since it is defined to have different
> semantics for a 485 (Ambiguous), and, indeed, 3xx.
> 
> If we don't get a solution for this, in the worse case scenario,
> it's only going to result in 7 pointless transmissions...is this
> so much of a problem (whatever it was failed anyhoo)?
> 
> Cheers,
> 
> 
>  - Jo.
> 
> 
> 
> _______________________________________________
> SIP mailing list
> [email-masked]
> http://lists.bell-labs.com/mailman/listinfo/sip
> 

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 18 Jul 2000 13:38:42 -0400

> sure we can find some people to disagree).

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.

-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