Subject: [SIP] Contact in final INVITE response.

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

Hi Jonathan,

At the SuperOp interop testing I found that some implementations were
sending SIP messages from source ports that they did not expect responses
on. 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.

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.

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.]

Regards,

Robert.

-- My opinions are my own. Nobody else listens to them anyway. --

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

---

From: "Jo Hornsby" <[email-masked]>
Date: Tue, 18 Jul 2000 10:22:38 +0100

> 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 

Interesting.

> Now for 2xx responses the RFC2543bis already says the a Contact
> MUST be included so this is not an issue.
> 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.