Subject: [sipcore] is Contact mandatory in 1xx responses to INVITE?

From: "Taisto Qvist XX" <[email-masked]>
Date: Fri, 6 Nov 2009 12:44:13 +0100

In a post regarding a different issue, one email response from Jeroen, 
indicated that he interpreted that the Contact is NOT mandatory in 
1xx responses for initial INVITE. (but not for re-invite...?)

Instead of trying to answer several different questions as once, I'll
put this question here, in a separate email.

My reading of 3261 says that it IS mandatory to add Contact in
1xx(!100), 
even though the "MUST" is spread over three different places.

First we have:

8.2.6.2

   in the response MUST equal that of the request.  However, if the To
   header field in the request did not contain a tag, the URI in the To
   header field in the response MUST equal the URI in the To header
   field; additionally, the UAS MUST add a tag to the To header field in
   the response (with the exception of the 100 (Trying) response, in
   which a tag MAY be present). 

So I MUST add a to-tag to all my 1xx, except 100 Trying, where it's
optional.

Secondly:
12.1 Creation of a Dialog

   Dialogs are created through the generation of non-failure responses
   to requests with specific methods.  Within this specification, only
   2xx and 101-199 responses with a To tag, where the request was
   INVITE, will establish a dialog.  A dialog established by a non-final
   response to a request is in the "early" state and it is called an
   early dialog.  

and then finally:

12.1.1 UAS behavior

   When a UAS responds to a request with a response that establishes a
   dialog (such as a 2xx to INVITE), the UAS MUST copy all Record-Route
   header field values from the request into the response (including the
   URIs, URI parameters, and any Record-Route header field parameters,
   whether they are known or unknown to the UAS) and MUST maintain the
   order of those values.  The UAS MUST add a Contact header field to
   the response.  The Contact header field contains an address where the
   UAS would like to be contacted for subsequent requests in the dialog
   (which includes the ACK for a 2xx response in the case of an INVITE).

So this means that 1) I MUST add a to-tag, 2) This creates a dialog, and
3) that means I MUST add Contact. 

Is that not a correct interpretation, for INVITE?

Regards 
Taisto Qvist
IP-Solutions

---

From: Brett Tate <[email-masked]>
Date: Fri, 6 Nov 2009 04:25:27 -0800

> Is that not a correct interpretation, for INVITE?

Yes; it is a correct interpretation.  However, there is nothing requiring the Contact within subsequent INVITE 1xx's within the dialog.  Even though it tends to cause interoperability problems, some vendors don't add the Contact since rfc3261 doesn't require it.  

Proxies generating 181 and 199 within another's dialog (i.e. they didn't generate the To tag) adds to the confusion of the appropriateness to update route set and target within the dialog.  If proxy doesn't add a Contact to the 1xx, it is malformed (per rfc3261) if the UAC did not see the prior 1xx which would have created the dialog.

---

From: "Sanjay Sinha (sanjsinh)" <[email-masked]>
Date: Fri, 6 Nov 2009 06:31:12 -0600

If 1xx is not sent reliably,  that is PRACK is not enabled, it is highly
recommended to add Contact header to it. If 1xx is sent reliably, then
UAS must add a Contact header.

Sanjay

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Taisto Qvist XX
Sent: Friday, November 06, 2009 5:14 PM
To: [email-masked]
Subject: [sipcore] is Contact mandatory in 1xx responses to INVITE?

First we have:

8.2.6.2

Secondly:

and then finally:

12.1.1 UAS behavior

Regards 
Taisto Qvist
IP-Solutions

_______________________________________________
sipcore mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sipcore

---

From: "Christer Holmberg" <[email-masked]>
Date: Fri, 6 Nov 2009 13:54:09 +0100

>Yes; it is a correct interpretation.  However, there is 
>nothing requiring the Contact within subsequent INVITE 1xx's 
>within the dialog.  Even though it tends to cause 
>interoperability problems, some vendors don't add the Contact 
>since rfc3261 doesn't require it.  

The world would be a much better place if implementors asked themsleves:
"Ok, now, if I do NOT receive this header in this resposne, does
something actually go wrong?".

Remember the SIP rule: "Be prepared to receive any crap, but try not to
send so much crap."

Regards,

Christer