>Sections 12.1.1 says:
>------------------------------------
> 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.
>------------------------------------
>
>Now in 12.1.1 it says that the UAS MUST add a Contact header if the
>response establishes a dialog.
>What is now a "dialog"? a real "dialog" (2XX) or both a real dialog and
>an "early-dialog" (1XX)?
>
>* Question: If it means both then any 1XX (non 100) MUST contain a
>Contact header, is it?
Yes, that is my interpretation. Note that a "MUST" in the text of RFC 3261
takes precedence over the content of Table 2.
If any in-dialog request needs to be sent prior to receipt of the final
response, then the Remote Target (from the Contact) and Route Set (from the
Record-Route) must be set up based on the 1xx response. This is needed
especially if reliable provisional responses are being used. The PRACK needs
the remote target and route set. Some User Agents like to send DTMF in INFO
requests, and like to do it before the session is established.
[RL]Mostly agree. My interpretation is
12.1.1 means contact header must be added if response establish a dialog.
So the question becomes which response establishes dialog?
in RFC3261,2xx and 101-199 responses with a To tag would establish
dialog, ***if not yet***.
So Contact header must be present, for each different to tag from
RFC3261's perspective
1)2xx to ini-INVITE
2)each unreliable non-100 1xx response to ini-INVITE
3)first reliable non-100 1xx response
>
>
>But is also says that UAS MUST copy RR headers into the response, and
>this only makes sense in a 200 response, so:
See above. All User Agent implementations should include Record-Route and
Contact in 1xx response just like they would be included in a 2xx response. I
don't see any reason not to, and not including them breaks things.
[RL] RR is the same as Contact case above...
Note that the Record-Route headers and Contact header in a 2xx final response
will replace the route set and remote target of the dialog from the 1xx
response. But they usually will be the same.
[RL] Contact in 2xx might not replace remote target of early dialog, if they
are different.
13.2.2.4 2xx Responses
If the dialog identifier in the 2xx response matches the dialog
identifier of an existing dialog, the dialog MUST be transitioned to
the "confirmed" state, and the route set for the dialog MUST be
recomputed based on the 2xx response using the procedures of Section
12.2.1.2. Otherwise, a new dialog in the "confirmed" state MUST be
constructed using the procedures of Section 12.1.2.
Note that the ***only*** piece of state that is recomputed is the route
set. Other pieces of state such as the highest sequence numbers
(remote and local) sent within the dialog are not recomputed.
-Rockson
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
