13 Initiating a Session
13.2 UAC Processing
2074
13.2.1 Creating the InitialINVITE
2075
Since the initialINVITErepresents a request outside of a dialog, its construction follows the procedures of
2076
Section 8.1.1. Additional processing is required for the specific case ofINVITE.
2077
AnAllowheader field (Section 20.5)SHOULDbe present in theINVITE. It indicates what methods can
2078
be invoked within a dialog, on the UA sending theINVITE, for the duration of the dialog. For example, a
2079
UA capable of receivingINFOrequests within a dialog [34]SHOULDinclude anAllowheader field listing
2080
theINFOmethod.
2081
A Supportedheader field (Section 20.37) SHOULD be present in the INVITE. It enumerates all the
2082
extensions understood by the UAC.
2083
AnAccept(Section 20.1) header fieldMAYbe present in theINVITE. It indicates which Content-Types
2084
are acceptable to the UA, in both the response received by it, and in any subsequent requests sent to it within
2085
dialogs established by theINVITE. TheAccept header field is especially useful for indicating support of
2086
various session description formats.
2087
The UACMAYadd anExpiresheader field (Section 20.19) to limit the validity of the invitation. If the
2088
time indicated in theExpiresheader field is reached and no final answer for theINVITEhas been received
2089
the UAC coreSHOULDgenerate aCANCELrequest for theINVITE, as per Section 9.
2090
A UAC MAY also find it useful to add, among others, Subject(Section 20.36), Organization
(Sec-2091
tion 20.25) and User-Agent (Section 20.41) header fields. They all contain information related to the
2092
INVITE.
2093
The UAC MAYchoose to add a message body to theINVITE. Section 8.1.1.10 deals with how to
con-2094
struct the header fields –Content-Typeamong others – needed to describe the message body.
2095
There are special rules for message bodies that contain a session description - their corresponding
2096
Content-Disposition is “session”. SIP uses an offer/answer model where one UA sends a session
de-2097
scription, called the offer, which contains a proposed description of the session. The offer indicates the
2098
desired communications means (audio, video, games), parameters of those means (such as codec types) and
2099
addresses for receiving media from the answerer. The other UA responds with another session description,
2100
called the answer, which indicates which communications means are accepted, the parameters that apply to
2101
those means, and addresses for receiving media from the offerer. The offer/answer model defines restrictions
2102
on when offers and answers can be made. This results in restrictions on where the offers and answers can
2103
appear in SIP messages. In this specification, offers and answers can only appear inINVITErequests and
re-2104
sponses, andACK. The usage of offers and answers is further restricted. For the initialINVITEtransaction,
2105
the rules are:
2106
• The initial offer MUSTbe in either anINVITEor, if not there, in the first reliable non-failure message
2107
from the UAS back to the UAC. In this specification, that is the final 2xx response.
2108
• If the initial offer is in an INVITE, the answerMUSTbe in a reliable non-failure message from UAS
2109
back to UAC which is correlated to that INVITE. For this specification, that is only the final 2xx
2110
response to thatINVITE. That same exact answerMAY also be placed in any provisional responses
2111
sent prior to the answer. The UACMUSTtreat the first session description it receives as the answer,
2112
andMUSTignore any session descriptions in subsequent responses to the initialINVITE.
2113
• If the initial offer is in the first reliable non-failure message from the UAS back to UAC, the answer
2114
MUSTbe in the acknowledgement for that message (in this specification,ACKfor a 2xx response).
2115
• After having sent or received an answer to the first offer, the UAC MAYgenerate subsequent offers
2116
in requests, but only if it has received answers to any previous offers, and has not sent any offers to
2117
which it hasn’t gotten an answer.
2118
• Once the UAS has sent or received an answer to the initial offer, it MUST NOTgenerate subsequent
2119
offers in any responses to the initialINVITE. This means that a UAS based on this specification alone
2120
can never generate subsequent offers until completion of the initial transaction.
2121
Concretely, the above rules specify two exchanges - the offer is in the INVITE, and the answer in the
2122
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
2123
ACK. All user agents that supportINVITEMUSTsupport these two exchanges.
2124
The Session Description Protocol (SDP) (RFC 2327 [1]) MUST be supported by all user agents as a
2125
means to describe sessions, and its usage for constructing offers and answersMUSTfollow the procedures
2126
defined in [13].
2127
The restrictions of the offer-answer model just described only apply to bodies whoseContent-Disposition
2128
header field value is “session”. Therefore, it is possible that both theINVITEand theACKcontain a body
2129
message (for example, theINVITEcarries a photo (Content-Disposition: render) and theACK a session
2130
description (Content-Disposition: session)).
2131
If theContent-Dispositionheader field is missing, bodies ofContent-Typeapplication/sdpimply the
2132
disposition “session”, while other content types imply “render”.
2133
Once theINVITEhas been created, the UAC follows the procedures defined for sending requests outside
2134
of a dialog (Section 8). This results in the construction of a client transaction that will ultimately send the
2135
request and deliver responses to the UAC.
2136
13.2.2 ProcessingINVITEResponses
2137
Once theINVITEhas been passed to the INVITEclient transaction, the UAC waits for responses for the
2138
INVITE. If theINVITEclient transaction returns a timeout rather than a response the TU acts as if a 408
2139
(Request Timeout) response had been received, as described in Section 8.1.3.
2140
13.2.2.1 1xx responses Zero, one or multiple provisional responses may arrive before one or more
2141
final responses are received. Provisional responses for anINVITErequest can create “early dialogs”. If a
2142
provisional response has a tag in theTofield, and if the dialog ID of the response does not match an existing
2143
dialog, one is constructed using the procedures defined in Section 12.1.2.
2144
The early dialog will only be needed if the UAC needs to send a request to its peer within the dialog
2145
before the initialINVITEtransaction completes. Header fields present in a provisional response are
appli-2146
cable as long as the dialog is in the early state (for example, anAllowheader field in a provisional response
2147
contains the methods that can be used in the dialog while this is in the early state).
2148
13.2.2.2 3xx responses A 3xx response may contain one or moreContactheader field values
provid-2149
ing new addresses where the callee might be reachable. Depending on the status code of the 3xx response
2150
(see Section 21.3) the UACMAYchoose to try those new addresses.
2151
13.2.2.3 4xx, 5xx and 6xx responses A single non-2xx final response may be received for the
IN-2152
VITE. 4xx, 5xx and 6xx responses may contain aContactheader field value indicating the location where
2153
additional information about the error can be found. Subsequent final responses (which would only arrive
2154
under error conditions)MUSTbe ignored.
2155
All early dialogs are considered terminated upon reception of the non-2xx final response.
2156
After having received the non-2xx final response the UAC core considers the INVITE transaction
com-2157
pleted. TheINVITEclient transaction handles generation ofACKs for the response (see Section 17).
2158
13.2.2.4 2xx responses Multiple 2xx responses may arrive at the UAC for a singleINVITErequest
2159
due to a forking proxy. Each response is distinguished by thetagparameter in theToheader field, and each
2160
represents a distinct dialog, with a distinct dialog identifier.
2161
If the dialog identifier in the 2xx response matches the dialog identifier of an existing dialog, the dialog
2162
MUSTbe transitioned to the “confirmed” state, and the route set for the dialogMUSTbe recomputed based
2163
on the 2xx response using the procedures of Section 12.2.1.2. Otherwise, a new dialog in the “confirmed”
2164
stateMUSTbe constructed using the procedures of Section 12.1.2.
2165
Note that the only piece of state that is recomputed is the route set. Other pieces of state such as the highest
2166
sequence numbers (remote and local) sent within the dialog are not recomputed. The route set only is recomputed
2167
for backwards compatibility. RFC 2543 did not mandate mirroring of theRecord-Routeheader field in a 1xx, only
2168
2xx. However, we cannot update the entire state of the dialog, since mid-dialog requests may have been sent within
2169
the early dialog, modifying the sequence numbers, for example.
2170
The UAC core MUSTgenerate an ACKrequest for each 2xx received from the transaction layer. The
2171
header fields of the ACK are constructed in the same way as for any request sent within a dialog (see
2172
Section 12) with the exception of the CSeqand the header fields related to authentication. The sequence
2173
number of the CSeq header field MUSTbe the same as theINVITE being acknowledged, but theCSeq
2174
method MUSTbe ACK. TheACK MUSTcontain the same credentials as the INVITE. If the 2xx contains
2175
an offer (based on the rules above), the ACK MUST carry an answer in its body. If the offer in the 2xx
2176
response is not acceptable, the UAC coreMUSTgenerate a valid answer in theACKand then send aBYE
2177
immediately.
2178
Once theACKhas been constructed, the procedures of [4] are used to determine the destination address,
2179
port and transport. However, the request is passed to the transport layer directly for transmission, rather than
2180
a client transaction. This is because the UAC core handles retransmissions of theACK, not the transaction
2181
layer. TheACKMUSTbe passed to the client transport every time a retransmission of the 2xx final response
2182
that triggered theACKarrives.
2183
The UAC core considers the INVITE transaction completed 64*T1 seconds after the reception of the
2184
first 2xx response. At this point all the early dialogs that have not transitioned to established dialogs are
2185
terminated. Once the INVITEtransaction is considered completed by the UAC core, no more new 2xx
2186
responses are expected to arrive.
2187
If, after acknowledging any 2xx response to an INVITE, the UAC does not want to continue with that
2188
dialog, then the UACMUSTterminate the dialog by sending aBYErequest as described in Section 15.
2189