dialog

12 Dialogs

A key concept for a user agent is that of a dialog. A dialog
represents a peer-to-peer SIP relationship between two user agents
that persists for some time. The dialog facilitates sequencing of
messages between the user agents and proper routing of requests
between both of them. The dialog represents a context in which to
interpret SIP messages. Section 8 discussed method independent UA
processing for requests and responses outside of a dialog. This
section discusses how those requests and responses are used to
construct a dialog, and then how subsequent requests and responses
are sent within a dialog.

A dialog is identified at each UA with a dialog ID, which consists of
a Call-ID value, a local tag and a remote tag. The dialog ID at each
UA involved in the dialog is not the same. Specifically, the local
tag at one UA is identical to the remote tag at the peer UA. The
tags are opaque tokens that facilitate the generation of unique
dialog IDs.

A dialog ID is also associated with all responses and with any
request that contains a tag in the To field. The rules for computing
the dialog ID of a message depend on whether the SIP element is a UAC
or UAS. For a UAC, the Call-ID value of the dialog ID is set to the
Call-ID of the message, the remote tag is set to the tag in the To
field of the message, and the local tag is set to the tag in the From


field of the message (these rules apply to both requests and
responses). As one would expect for a UAS, the Call-ID value of the
dialog ID is set to the Call-ID of the message, the remote tag is set
to the tag in the From field of the message, and the local tag is set
to the tag in the To field of the message.

A dialog contains certain pieces of state needed for further message
transmissions within the dialog. This state consists of the dialog
ID, a local sequence number (used to order requests from the UA to
its peer), a remote sequence number (used to order requests from its
peer to the UA), a local URI, a remote URI, remote target, a boolean
flag called "secure", and a route set, which is an ordered list of
URIs. The route set is the list of servers that need to be traversed
to send a request to the peer. A dialog can also be in the "early"
state, which occurs when it is created with a provisional response,
and then transition to the "confirmed" state when a 2xx final
response arrives. For other responses, or if no response arrives at
all on that dialog, the early dialog terminates.

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. Extensions MAY define other means for creating
dialogs. Section 13 gives more details that are specific to the
INVITE method. Here, we describe the process for creation of dialog
state that is not dependent on the method.

UAs MUST assign values to the dialog ID components as described
below.

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.

UAS 가 요청에 응답할 때 dialog 상태가 된다, UAS 요청에 의한 모든 Record-route 헤더 값을
응답에 복사한다. 그리고 그 값을 지속시킨다.

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).
UAS 응답하기 위해 contact 헤더필드에 추가 하는데 contact 헤더필드에는
UAS 가 접속 했었던 다이얼로그 내의 요청 주소

Generally, the host portion of this URI is the IP address or FQDN of
the host. The URI provided in the Contact header field MUST be a SIP
or SIPS URI. If the request that initiated the dialog contained a



SIPS URI in the Request-URI or in the top Record-Route header field
value, if there was any, or the Contact header field if there was no
Record-Route header field, the Contact header field in the response
MUST be a SIPS URI. The URI SHOULD have global scope (that is, the
same URI can be used in messages outside this dialog). The same way,
the scope of the URI in the Contact header field of the INVITE is not
limited to this dialog either. It can therefore be used in messages
to the UAC even outside this dialog.

The UAS then constructs the state of the dialog. This state MUST be
maintained for the duration of the dialog.

If the request arrived over TLS(transport layer security), and the Request-URI contained a SIPS
URI, the "secure" flag is set to TRUE.

The route set MUST be set to the list of URIs in the Record-Route
header field from the request, taken in order and preserving all URI
parameters. If no Record-Route header field is present in the
request, the route set MUST be set to the empty set. This route set,
even if empty, overrides any pre-existing route set for future
requests in this dialog. The remote target MUST be set to the URI
from the Contact header field of the request.

The remote sequence number MUST be set to the value of the sequence
number in the CSeq header field of the request. The local sequence
number MUST be empty. The call identifier component of the dialog ID
MUST be set to the value of the Call-ID in the request. The local
tag component of the dialog ID MUST be set to the tag in the To field
in the response to the request (which always includes a tag), and the
remote tag component of the dialog ID MUST be set to the tag from the
From field in the request. A UAS MUST be prepared to receive a
request without a tag in the From field, in which case the tag is
considered to have a value of null.

This is to maintain backwards compatibility with RFC 2543, which
did not mandate From tags.

The remote URI MUST be set to the URI in the From field, and the
local URI MUST be set to the URI in the To field.

12.1.2 UAC Behavior

When a UAC sends a request that can establish a dialog (such as an
INVITE) it MUST provide a SIP or SIPS URI with global scope (i.e.,
the same SIP URI can be used in messages outside this dialog) in the
Contact header field of the request. If the request has a Request-
URI or a topmost Route header field value with a SIPS URI, the
Contact header field MUST contain a SIPS URI.



When a UAC receives a response that establishes a dialog, it
constructs the state of the dialog. This state MUST be maintained
for the duration of the dialog.

If the request was sent over TLS, and the Request-URI contained a
SIPS URI, the "secure" flag is set to TRUE.

The route set MUST be set to the list of URIs in the Record-Route
header field from the response, taken in reverse order and preserving
all URI parameters. If no Record-Route header field is present in
the response, the route set MUST be set to the empty set. This route
set, even if empty, overrides any pre-existing route set for future
requests in this dialog. The remote target MUST be set to the URI
from the Contact header field of the response.

The local sequence number MUST be set to the value of the sequence
number in the CSeq header field of the request. The remote sequence
number MUST be empty (it is established when the remote UA sends a
request within the dialog). The call identifier component of the
dialog ID MUST be set to the value of the Call-ID in the request.
The local tag component of the dialog ID MUST be set to the tag in
the From field in the request, and the remote tag component of the
dialog ID MUST be set to the tag in the To field of the response. A
UAC MUST be prepared to receive a response without a tag in the To
field, in which case the tag is considered to have a value of null.

This is to maintain backwards compatibility with RFC 2543, which
did not mandate To tags.

The remote URI MUST be set to the URI in the To field, and the local
URI MUST be set to the URI in the From field.

12.2 Requests within a Dialog

Once a dialog has been established between two UAs, either of them
MAY initiate new transactions as needed within the dialog. The UA
sending the request will take the UAC role for the transaction. The
UA receiving the request will take the UAS role. Note that these may
be different roles than the UAs held during the transaction that
established the dialog.

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.

12.2.1 UAC Behavior

12.2.1.1 Generating the Request

A request within a dialog is constructed by using many of the
components of the state stored as part of the dialog.

The URI in the To field of the request MUST be set to the remote URI
from the dialog state. The tag in the To header field of the request
MUST be set to the remote tag of the dialog ID. The From URI of the
request MUST be set to the local URI from the dialog state. The tag
in the From header field of the request MUST be set to the local tag
of the dialog ID. If the value of the remote or local tags is null,
the tag parameter MUST be omitted from the To or From header fields,
respectively.

Usage of the URI from the To and From fields in the original
request within subsequent requests is done for backwards
compatibility with RFC 2543, which used the URI for dialog
identification. In this specification, only the tags are used for
dialog identification. It is expected that mandatory reflection
of the original To and From URI in mid-dialog requests will be
deprecated in a subsequent revision of this specification.

The Call-ID of the request MUST be set to the Call-ID of the dialog.
Requests within a dialog MUST contain strictly monotonically
increasing and contiguous CSeq sequence numbers (increasing-by-one)
in each direction (excepting ACK and CANCEL of course, whose numbers
equal the requests being acknowledged or cancelled). Therefore, if
the local sequence number is not empty, the value of the local
sequence number MUST be incremented by one, and this value MUST be
placed into the CSeq header field. If the local sequence number is
empty, an initial value MUST be chosen using the guidelines of
Section 8.1.1.5. The method field in the CSeq header field value
MUST match the method of the request.





With a length of 32 bits, a client could generate, within a single
call, one request a second for about 136 years before needing to
wrap around. The initial value of the sequence number is chosen
so that subsequent requests within the same call will not wrap
around. A non-zero initial value allows clients to use a time-
based initial sequence number. A client could, for example,
choose the 31 most significant bits of a 32-bit second clock as an
initial sequence number.

The UAC uses the remote target and route set to build the Request-URI
and Route header field of the request.

If the route set is empty, the UAC MUST place the remote target URI
into the Request-URI. The UAC MUST NOT add a Route header field to
the request.

If the route set is not empty, and the first URI in the route set
contains the lr parameter (see Section 19.1.1), the UAC MUST place
the remote target URI into the Request-URI and MUST include a Route
header field containing the route set values in order, including all
parameters.

If the route set is not empty, and its first URI does not contain the
lr parameter, the UAC MUST place the first URI from the route set
into the Request-URI, stripping any parameters that are not allowed
in a Request-URI. The UAC MUST add a Route header field containing
the remainder of the route set values in order, including all
parameters. The UAC MUST then place the remote target URI into the
Route header field as the last value.

For example, if the remote target is sip:user@remoteua and the route
set contains:

,,,

The request will be formed with the following Request-URI and Route
header field:

METHOD sip:proxy1
Route: ,,,

If the first URI of the route set does not contain the lr
parameter, the proxy indicated does not understand the routing
mechanisms described in this document and will act as specified in
RFC 2543, replacing the Request-URI with the first Route header
field value it receives while forwarding the message. Placing the
Request-URI at the end of the Route header field preserves the




information in that Request-URI across the strict router (it will
be returned to the Request-URI when the request reaches a loose-
router).

A UAC SHOULD include a Contact header field in any target refresh
requests within a dialog, and unless there is a need to change it,
the URI SHOULD be the same as used in previous requests within the
dialog. If the "secure" flag is true, that URI MUST be a SIPS URI.
As discussed in Section 12.2.2, a Contact header field in a target
refresh request updates the remote target URI. This allows a UA to
provide a new contact address, should its address change during the
duration of the dialog.

However, requests that are not target refresh requests do not affect
the remote target URI for the dialog.

The rest of the request is formed as described in Section 8.1.1.

Once the request has been constructed, the address of the server is
computed and the request is sent, using the same procedures for
requests outside of a dialog (Section 8.1.2).

The procedures in Section 8.1.2 will normally result in the
request being sent to the address indicated by the topmost Route
header field value or the Request-URI if no Route header field is
present. Subject to certain restrictions, they allow the request
to be sent to an alternate address (such as a default outbound
proxy not represented in the route set).

12.2.1.2 Processing the Responses

The UAC will receive responses to the request from the transaction
layer. If the client transaction returns a timeout, this is treated
as a 408 (Request Timeout) response.

The behavior of a UAC that receives a 3xx response for a request sent
within a dialog is the same as if the request had been sent outside a
dialog. This behavior is described in Section 8.1.3.4.

Note, however, that when the UAC tries alternative locations, it
still uses the route set for the dialog to build the Route header
of the request.

When a UAC receives a 2xx response to a target refresh request, it
MUST replace the dialog's remote target URI with the URI from the
Contact header field in that response, if present.





If the response for a request within a dialog is a 481
(Call/Transaction Does Not Exist) or a 408 (Request Timeout), the UAC
SHOULD terminate the dialog. A UAC SHOULD also terminate a dialog if
no response at all is received for the request (the client
transaction would inform the TU about the timeout.)

For INVITE initiated dialogs, terminating the dialog consists of
sending a BYE.

12.2.2 UAS Behavior

Requests sent within a dialog, as any other requests, are atomic. If
a particular request is accepted by the UAS, all the state changes
associated with it are performed. If the request is rejected, none
of the state changes are performed.

Note that some requests, such as INVITEs, affect several pieces of
state.

The UAS will receive the request from the transaction layer. If the
request has a tag in the To header field, the UAS core computes the
dialog identifier corresponding to the request and compares it with
existing dialogs. If there is a match, this is a mid-dialog request.
In that case, the UAS first applies the same processing rules for
requests outside of a dialog, discussed in Section 8.2.

If the request has a tag in the To header field, but the dialog
identifier does not match any existing dialogs, the UAS may have
crashed and restarted, or it may have received a request for a
different (possibly failed) UAS (the UASs can construct the To tags
so that a UAS can identify that the tag was for a UAS for which it is
providing recovery). Another possibility is that the incoming
request has been simply misrouted. Based on the To tag, the UAS MAY
either accept or reject the request. Accepting the request for
acceptable To tags provides robustness, so that dialogs can persist
even through crashes. UAs wishing to support this capability must
take into consideration some issues such as choosing monotonically
increasing CSeq sequence numbers even across reboots, reconstructing
the route set, and accepting out-of-range RTP timestamps and sequence
numbers.

If the UAS wishes to reject the request because it does not wish to
recreate the dialog, it MUST respond to the request with a 481
(Call/Transaction Does Not Exist) status code and pass that to the
server transaction.




Requests that do not change in any way the state of a dialog may be
received within a dialog (for example, an OPTIONS request). They are
processed as if they had been received outside the dialog.

If the remote sequence number is empty, it MUST be set to the value
of the sequence number in the CSeq header field value in the request.
If the remote sequence number was not empty, but the sequence number
of the request is lower than the remote sequence number, the request
is out of order and MUST be rejected with a 500 (Server Internal
Error) response. If the remote sequence number was not empty, and
the sequence number of the request is greater than the remote
sequence number, the request is in order. It is possible for the
CSeq sequence number to be higher than the remote sequence number by
more than one. This is not an error condition, and a UAS SHOULD be
prepared to receive and process requests with CSeq values more than
one higher than the previous received request. The UAS MUST then set
the remote sequence number to the value of the sequence number in the
CSeq header field value in the request.

If a proxy challenges a request generated by the UAC, the UAC has
to resubmit the request with credentials. The resubmitted request
will have a new CSeq number. The UAS will never see the first
request, and thus, it will notice a gap in the CSeq number space.
Such a gap does not represent any error condition.

When a UAS receives a target refresh request, it MUST replace the
dialog's remote target URI with the URI from the Contact header field
in that request, if present.

12.3 Termination of a Dialog

Independent of the method, if a request outside of a dialog generates
a non-2xx final response, any early dialogs created through
provisional responses to that request are terminated. The mechanism
for terminating confirmed dialogs is method specific. In this
specification, the BYE method terminates a session and the dialog
associated with it. See Section 15 for details.