13. Initiating a Session
13.1. Overview
When a user agent client desires to initiate a session (for example,
audio, video, or a game), it formulates an INVITE request. The
INVITE request asks a server to establish a session. This request
may be forwarded by proxies, eventually arriving at one or more UAS
that can potentially accept the invitation. These UASs will
frequently need to query the user about whether to accept the
invitation. After some time, those UASs can accept the invitation
(meaning the session is to be established) by sending a 2xx response.
If the invitation is not accepted, a 3xx, 4xx, 5xx or 6xx response is
sent, depending on the reason for the rejection. Before sending a
final response, the UAS can also send provisional responses (1xx) to
advise the UAC of progress in contacting the called user.
After possibly receiving one or more provisional responses, the UAC
will get one or more 2xx responses or one non-2xx final response.
Because of the protracted amount of time it can take to receive final
responses to INVITE, the reliability mechanisms for INVITE
transactions differ from those of other requests (like OPTIONS).
Once it receives a final response, the UAC needs to send an ACK for
every final response it receives. The procedure for sending this ACK
depends on the type of response. For final responses between 300 and
699, the ACK processing is done in the transaction layer and follows
one set of rules (See Section 17). For 2xx responses, the ACK is
generated by the UAC core.
A 2xx response to an INVITE establishes a session, and it also
creates a dialog between the UA that issued the INVITE and the UA
that generated the 2xx response. Therefore, when multiple 2xx
responses are received from different remote UAs (because the INVITE
forked), each 2xx establishes a different dialog. All these dialogs
are part of the same call.
This section provides details on the establishment of a session using
INVITE. A UA that supports INVITE MUST also support ACK, CANCEL and
BYE.
13.2. UAC Processing
13.2.1. Creating the Initial INVITE
Since the initial INVITE represents a request outside of a dialog,
its construction follows the procedures of Section 8.1.1. Additional
processing is required for the specific case of INVITE.
An Allow header field (Section 20.5) SHOULD be present in the INVITE.
It indicates what methods can be invoked within a dialog, on the UA
sending the INVITE, for the duration of the dialog. For example, a
UA capable of receiving INFO requests within a dialog [34] SHOULD
include an Allow header field listing the INFO method.
A Supported header field (Section 20.37) SHOULD be present in the
INVITE. It enumerates all the extensions understood by the UAC.
An Accept (Section 20.1) header field MAY be present in the INVITE.
It indicates which Content-Types are acceptable to the UA, in both
the response received by it, and in any subsequent requests sent to
it within dialogs established by the INVITE. The Accept header field
is especially useful for indicating support of various session
description formats.
The UAC MAY add an Expires header field (Section 20.19) to limit the
validity of the invitation. If the time indicated in the Expires
header field is reached and no final answer for the INVITE has been
received, the UAC core SHOULD generate a CANCEL request for the
INVITE, as per Section 9.
A UAC MAY also find it useful to add, among others, Subject (Section
20.36), Organization (Section 20.25) and User-Agent (Section 20.41)
header fields. They all contain information related to the INVITE.
The UAC MAY choose to add a message body to the INVITE. Section
8.1.1.10 deals with how to construct the header fields -- Content-
Type among others -- needed to describe the message body.
There are special rules for message bodies that contain a session
description - their corresponding Content-Disposition is "session".
SIP uses an offer/answer model where one UA sends a session
description, called the offer, which contains a proposed description
of the session. The offer indicates the desired communications means
(audio, video, games), parameters of those means (such as codec
types) and addresses for receiving media from the answerer. The
other UA responds with another session description, called the
answer, which indicates which communications means are accepted, the
parameters that apply to those means, and addresses for receiving
media from the offerer. An offer/answer exchange is within the
context of a dialog, so that if a SIP INVITE results in multiple
dialogs, each is a separate offer/answer exchange. The offer/answer
model defines restrictions on when offers and answers can be made
(for example, you cannot make a new offer while one is in progress).
This results in restrictions on where the offers and answers can
appear in SIP messages. In this specification, offers and answers
can only appear in INVITE requests and responses, and ACK. The usage
of offers and answers is further restricted. For the initial INVITE
transaction, the rules are:
o The initial offer MUST be in either an INVITE or, if not there,
in the first reliable non-failure message from the UAS back to
the UAC. In this specification, that is the final 2xx
response.
o If the initial offer is in an INVITE, the answer MUST be in a
reliable non-failure message from UAS back to UAC which is
correlated to that INVITE. For this specification, that is
only the final 2xx response to that INVITE. That same exact
answer MAY also be placed in any provisional responses sent
prior to the answer. The UAC MUST treat the first session
description it receives as the answer, and MUST ignore any
session descriptions in subsequent responses to the initial
INVITE.
o If the initial offer is in the first reliable non-failure
message from the UAS back to UAC, the answer MUST be in the
acknowledgement for that message (in this specification, ACK
for a 2xx response).
o After having sent or received an answer to the first offer, the
UAC MAY generate subsequent offers in requests based on rules
specified for that method, but only if it has received answers
to any previous offers, and has not sent any offers to which it
hasn't gotten an answer.
o Once the UAS has sent or received an answer to the initial
offer, it MUST NOT generate subsequent offers in any responses
to the initial INVITE. This means that a UAS based on this
specification alone can never generate subsequent offers until
completion of the initial transaction.
Concretely, the above rules specify two exchanges for UAs compliant
to this specification alone - the offer is in the INVITE, and the
answer in the 2xx (and possibly in a 1xx as well, with the same
value), or the offer is in the 2xx, and the answer is in the ACK.
All user agents that support INVITE MUST support these two exchanges.
The Session Description Protocol (SDP) (RFC 2327(-> 4566prop) [1]) MUST be
supported by all user agents as a means to describe sessions, and its
usage for constructing offers and answers MUST follow the procedures
defined in [13].
The restrictions of the offer-answer model just described only apply
to bodies whose Content-Disposition header field value is "session".
Therefore, it is possible that both the INVITE and the ACK contain a
body message (for example, the INVITE carries a photo (Content-
Disposition: render) and the ACK a session description (Content-
Disposition: session)).
If the Content-Disposition header field is missing, bodies of
Content-Type application/sdp imply the disposition "session", while
other content types imply "render".
Once the INVITE has been created, the UAC follows the procedures
defined for sending requests outside of a dialog (Section 8). This
results in the construction of a client transaction that will
ultimately send the request and deliver responses to the UAC.
13.2.2. Processing INVITE Responses
Once the INVITE has been passed to the INVITE client transaction, the
UAC waits for responses for the INVITE. If the INVITE client
transaction returns a timeout rather than a response the TU acts as
if a 408 (Request Timeout) response had been received, as described
in Section 8.1.3.
13.2.2.1. xx Responses
Zero, one or multiple provisional responses may arrive before one or
more final responses are received. Provisional responses for an
INVITE request can create "early dialogs". If a provisional response
has a tag in the To field, and if the dialog ID of the response does
not match an existing dialog, one is constructed using the procedures
defined in Section 12.1.2.
The early dialog will only be needed if the UAC needs to send a
request to its peer within the dialog before the initial INVITE
transaction completes. Header fields present in a provisional
response are applicable as long as the dialog is in the early state
(for example, an Allow header field in a provisional response
contains the methods that can be used in the dialog while this is in
the early state).
13.2.2.2. xx Responses
A 3xx response may contain one or more Contact header field values
providing new addresses where the callee might be reachable.
Depending on the status code of the 3xx response (see Section 21.3),
the UAC MAY choose to try those new addresses.
13.2.2.3. xx, 5xx and 6xx Responses
A single non-2xx final response may be received for the INVITE. 4xx,
5xx and 6xx responses may contain a Contact header field value
indicating the location where additional information about the error
can be found. Subsequent final responses (which would only arrive
under error conditions) MUST be ignored.
All early dialogs are considered terminated upon reception of the
non-2xx final response.
After having received the non-2xx final response the UAC core
considers the INVITE transaction completed. The INVITE client
transaction handles the generation of ACKs for the response (see
Section 17).
13.2.2.4. xx Responses
Multiple 2xx responses may arrive at the UAC for a single INVITE
request due to a forking proxy. Each response is distinguished by
the tag parameter in the To header field, and each represents a
distinct dialog, with a distinct dialog identifier.
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. The
route set only is recomputed for backwards compatibility. RFC
2543(-> 3265prop | 3264prop | 3263prop | 3262prop | 3261prop) did not mandate mirroring of the Record-Route header field in
a 1xx, only 2xx. However, we cannot update the entire state of
the dialog, since mid-dialog requests may have been sent within
the early dialog, modifying the sequence numbers, for example.
The UAC core MUST generate an ACK request for each 2xx received from
the transaction layer. The header fields of the ACK are constructed
in the same way as for any request sent within a dialog (see Section
12) with the exception of the CSeq and the header fields related to
authentication. The sequence number of the CSeq header field MUST be
the same as the INVITE being acknowledged, but the CSeq method MUST
be ACK. The ACK MUST contain the same credentials as the INVITE. If
the 2xx contains an offer (based on the rules above), the ACK MUST
carry an answer in its body. If the offer in the 2xx response is not
acceptable, the UAC core MUST generate a valid answer in the ACK and
then send a BYE immediately.
Once the ACK has been constructed, the procedures of [4] are used to
determine the destination address, port and transport. However, the
request is passed to the transport layer directly for transmission,
rather than a client transaction. This is because the UAC core
handles retransmissions of the ACK, not the transaction layer. The
ACK MUST be passed to the client transport every time a
retransmission of the 2xx final response that triggered the ACK
arrives.
The UAC core considers the INVITE transaction completed 64*T1 seconds
after the reception of the first 2xx response. At this point all the
early dialogs that have not transitioned to established dialogs are
terminated. Once the INVITE transaction is considered completed by
the UAC core, no more new 2xx responses are expected to arrive.
If, after acknowledging any 2xx response to an INVITE, the UAC does
not want to continue with that dialog, then the UAC MUST terminate
the dialog by sending a BYE request as described in Section 15.
13.3. UAS Processing
13.3.1. Processing of the INVITE
The UAS core will receive INVITE requests from the transaction layer.
It first performs the request processing procedures of Section 8.2,
which are applied for both requests inside and outside of a dialog.
Assuming these processing states are completed without generating a
response, the UAS core performs the additional processing steps:
1. If the request is an INVITE that contains an Expires header
field, the UAS core sets a timer for the number of seconds
indicated in the header field value. When the timer fires, the
invitation is considered to be expired. If the invitation
expires before the UAS has generated a final response, a 487
(Request Terminated) response SHOULD be generated.
2. If the request is a mid-dialog request, the method-independent
processing described in Section 12.2.2 is first applied. It
might also modify the session; Section 14 provides details.
3. If the request has a tag in the To header field but the dialog
identifier does not match any of the existing dialogs, the UAS
may have crashed and restarted, or may have received a request
for a different (possibly failed) UAS. Section 12.2.2 provides
guidelines to achieve a robust behavior under such a situation.
Processing from here forward assumes that the INVITE is outside of a
dialog, and is thus for the purposes of establishing a new session.
The INVITE may contain a session description, in which case the UAS
is being presented with an offer for that session. It is possible
that the user is already a participant in that session, even though
the INVITE is outside of a dialog. This can happen when a user is
invited to the same multicast conference by multiple other
participants. If desired, the UAS MAY use identifiers within the
session description to detect this duplication. For example, SDP
contains a session id and version number in the origin (o) field. If
the user is already a member of the session, and the session
parameters contained in the session description have not changed, the
UAS MAY silently accept the INVITE (that is, send a 2xx response
without prompting the user).
If the INVITE does not contain a session description, the UAS is
being asked to participate in a session, and the UAC has asked that
the UAS provide the offer of the session. It MUST provide the offer
in its first non-failure reliable message back to the UAC. In this
specification, that is a 2xx response to the INVITE.
The UAS can indicate progress, accept, redirect, or reject the
invitation. In all of these cases, it formulates a response using
the procedures described in Section 8.2.6.
13.3.1.1. Progress
If the UAS is not able to answer the invitation immediately, it can
choose to indicate some kind of progress to the UAC (for example, an
indication that a phone is ringing). This is accomplished with a
provisional response between 101 and 199. These provisional
responses establish early dialogs and therefore follow the procedures
of Section 12.1.1 in addition to those of Section 8.2.6. A UAS MAY
send as many provisional responses as it likes. Each of these MUST
indicate the same dialog ID. However, these will not be delivered
reliably.
If the UAS desires an extended period of time to answer the INVITE,
it will need to ask for an "extension" in order to prevent proxies
from canceling the transaction. A proxy has the option of canceling
a transaction when there is a gap of 3 minutes between responses in a
transaction. To prevent cancellation, the UAS MUST send a non-100
provisional response at every minute, to handle the possibility of
lost provisional responses.
An INVITE transaction can go on for extended durations when the
user is placed on hold, or when interworking with PSTN systems
which allow communications to take place without answering the
call. The latter is common in Interactive Voice Response (IVR)
systems.
13.3.1.2. The INVITE is Redirected
If the UAS decides to redirect the call, a 3xx response is sent. A
300 (Multiple Choices), 301 (Moved Permanently) or 302 (Moved
Temporarily) response SHOULD contain a Contact header field
containing one or more URIs of new addresses to be tried. The
response is passed to the INVITE server transaction, which will deal
with its retransmissions.
13.3.1.3. The INVITE is Rejected
A common scenario occurs when the callee is currently not willing or
able to take additional calls at this end system. A 486 (Busy Here)
SHOULD be returned in such a scenario. If the UAS knows that no
other end system will be able to accept this call, a 600 (Busy
Everywhere) response SHOULD be sent instead. However, it is unlikely
that a UAS will be able to know this in general, and thus this
response will not usually be used. The response is passed to the
INVITE server transaction, which will deal with its retransmissions.
A UAS rejecting an offer contained in an INVITE SHOULD return a 488
(Not Acceptable Here) response. Such a response SHOULD include a
Warning header field value explaining why the offer was rejected.
13.3.1.4. The INVITE is Accepted
The UAS core generates a 2xx response. This response establishes a
dialog, and therefore follows the procedures of Section 12.1.1 in
addition to those of Section 8.2.6.
A 2xx response to an INVITE SHOULD contain the Allow header field and
the Supported header field, and MAY contain the Accept header field.
Including these header fields allows the UAC to determine the
features and extensions supported by the UAS for the duration of the
call, without probing.
If the INVITE request contained an offer, and the UAS had not yet
sent an answer, the 2xx MUST contain an answer. If the INVITE did
not contain an offer, the 2xx MUST contain an offer if the UAS had
not yet sent an offer.
Once the response has been constructed, it is passed to the INVITE
server transaction. Note, however, that the INVITE server
transaction will be destroyed as soon as it receives this final
response and passes it to the transport. Therefore, it is necessary
to periodically pass the response directly to the transport until the
ACK arrives. The 2xx response is passed to the transport with an
interval that starts at T1 seconds and doubles for each
retransmission until it reaches T2 seconds (T1 and T2 are defined in
Section 17). Response retransmissions cease when an ACK request for
the response is received. This is independent of whatever transport
protocols are used to send the response.
Since 2xx is retransmitted end-to-end, there may be hops between
UAS and UAC that are UDP. To ensure reliable delivery across
these hops, the response is retransmitted periodically even if the
transport at the UAS is reliable.
If the server retransmits the 2xx response for 64*T1 seconds without
receiving an ACK, the dialog is confirmed, but the session SHOULD be
terminated. This is accomplished with a BYE, as described in Section
15.
