Thanks to everyone who responded to my earlier query (Target Refresh Request
and Contact Header thread).
I now have a similar query for establishing the Remote Target. Please
forgive the length in advance and feel free to insert corrections/input as
necessary.
>From section 12.1 of RFC 3261, the following is stated:
Within this specification, only 2xx and 101-199 responses with a To tag,
where the request was INVITE, will establish a dialog.
This seems to indicate that either a 2xx or 101-199 response (with a To tag)
to the initial INVITE can establish a dialog (confirmed vs early dialog
respectively), correct?
Then, from section 12.1.1 of RFC 3261, the following is added about the
response that establishes the dialog:
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.
This seems to indicate that the first 101-199 response sent from the
UAS/received at the UAC (with a To Tag) must contain a Contact header (to
set the Remote Target at the UAC), correct? So, if the Contact header is not
received in this response, this would be considered a violation of the spec
and an invalid response, correct? Also, according to the following section (
12.1.2), this also sets up the dialog state (items like the route set, if
not empty, and the Remote Target).
Section 12.2 of RFC 3261 goes into additional details of when the Remote
Target can be changed (ie, Remote Target Refresh):
Requests within a dialog MAY contain Record-Route and Contact header
fields. However, these requests do not cause the dialog's route set to be
modified, although they may modify the remote target URI. Specifically,
requests that are not target refresh requests do not modify the dialog's
remote target URI, and requests that are target refresh requests do. For
dialogs that have been established with an INVITE, the only target refresh
request defined is re-INVITE (see Section 14). Other extensions may define
different target refresh requests for dialogs established in other ways.
Note that an ACK is NOT a target refresh request.
Target refresh requests only update the dialog's remote target URI, and not
the route set formed from the Record-Route. Updating the latter would
introduce severe backwards compatibility problems with RFC 2543-compliant
systems.
This seems to indicate that after the 101-199 response is received (that
establishes the dialog), only the re-INVITE and its 2xx response and UPDATE
(per RFC 3311) and its 2xx response can change the Remote Target. Therefore,
if a subsequent provisional response to the INVITE (ie, 180 Ringing that
followed a 183 Session Progress) is received, it is not allowed to update
the Remote Target if it contains a Contact header, correct? What about an
UPDATE received in the early dialog state? This would also allow the Remote
Target to be updated, correct?
Thanks again,
David Roan
_______________________________________________
Sip mailing list http://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
