14. Modifying an Existing Session
A successful INVITE request (see Section 13) establishes both a
dialog between two user agents and a session using the offer-answer
model. Section 12 explains how to modify an existing dialog using a
target refresh request (for example, changing the remote target URI
of the dialog). This section describes how to modify the actual
session. This modification can involve changing addresses or ports,
adding a media stream, deleting a media stream, and so on. This is
accomplished by sending a new INVITE request within the same dialog
that established the session. An INVITE request sent within an
existing dialog is known as a re-INVITE.
Note that a single re-INVITE can modify the dialog and the
parameters of the session at the same time.
Either the caller or callee can modify an existing session.
The behavior of a UA on detection of media failure is a matter of
local policy. However, automated generation of re-INVITE or BYE is
NOT RECOMMENDED to avoid flooding the network with traffic when there
is congestion. In any case, if these messages are sent
automatically, they SHOULD be sent after some randomized interval.
Note that the paragraph above refers to automatically generated
BYEs and re-INVITEs. If the user hangs up upon media failure, the
UA would send a BYE request as usual.
The same offer-answer model that applies to session descriptions in
INVITEs (Section 13.2.1) applies to re-INVITEs. As a result, a UAC
that wants to add a media stream, for example, will create a new
offer that contains this media stream, and send that in an INVITE
request to its peer. It is important to note that the full
description of the session, not just the change, is sent. This
supports stateless session processing in various elements, and
supports failover and recovery capabilities. Of course, a UAC MAY
send a re-INVITE with no session description, in which case the first
reliable non-failure response to the re-INVITE will contain the offer
(in this specification, that is a 2xx response).
If the session description format has the capability for version
numbers, the offerer SHOULD indicate that the version of the session
description has changed.
The To, From, Call-ID, CSeq, and Request-URI of a re-INVITE are set
following the same rules as for regular requests within an existing
dialog, described in Section 12.
A UAC MAY choose not to add an Alert-Info header field or a body with
Content-Disposition "alert" to re-INVITEs because UASs do not
typically alert the user upon reception of a re-INVITE.
Unlike an INVITE, which can fork, a re-INVITE will never fork, and
therefore, only ever generate a single final response. The reason a
re-INVITE will never fork is that the Request-URI identifies the
target as the UA instance it established the dialog with, rather than
identifying an address-of-record for the user.
Note that a UAC MUST NOT initiate a new INVITE transaction within a
dialog while another INVITE transaction is in progress in either
direction.
1. If there is an ongoing INVITE client transaction, the TU MUST
wait until the transaction reaches the completed or terminated
state before initiating the new INVITE.
2. If there is an ongoing INVITE server transaction, the TU MUST
wait until the transaction reaches the confirmed or terminated
state before initiating the new INVITE.
However, a UA MAY initiate a regular transaction while an INVITE
transaction is in progress. A UA MAY also initiate an INVITE
transaction while a regular transaction is in progress.
If a UA receives a non-2xx final response to a re-INVITE, the session
parameters MUST remain unchanged, as if no re-INVITE had been issued.
Note that, as stated in Section 12.2.1.2, if the non-2xx final
response is a 481 (Call/Transaction Does Not Exist), or a 408
(Request Timeout), or no response at all is received for the re-
INVITE (that is, a timeout is returned by the INVITE client
transaction), the UAC will terminate the dialog.
If a UAC receives a 491 response to a re-INVITE, it SHOULD start a
timer with a value T chosen as follows:
1. If the UAC is the owner of the Call-ID of the dialog ID
(meaning it generated the value), T has a randomly chosen value
between 2.1 and 4 seconds in units of 10 ms.
2. If the UAC is not the owner of the Call-ID of the dialog ID, T
has a randomly chosen value of between 0 and 2 seconds in units
of 10 ms.
When the timer fires, the UAC SHOULD attempt the re-INVITE once more,
if it still desires for that session modification to take place. For
example, if the call was already hung up with a BYE, the re-INVITE
would not take place.
The rules for transmitting a re-INVITE and for generating an ACK for
a 2xx response to re-INVITE are the same as for the initial INVITE
(Section 13.2.1).
Section 13.3.1 describes the procedure for distinguishing incoming
re-INVITEs from incoming initial INVITEs and handling a re-INVITE for
an existing dialog.
A UAS that receives a second INVITE before it sends the final
response to a first INVITE with a lower CSeq sequence number on the
same dialog MUST return a 500 (Server Internal Error) response to the
second INVITE and MUST include a Retry-After header field with a
randomly chosen value of between 0 and 10 seconds.
A UAS that receives an INVITE on a dialog while an INVITE it had sent
on that dialog is in progress MUST return a 491 (Request Pending)
response to the received INVITE.
If a UA receives a re-INVITE for an existing dialog, it MUST check
any version identifiers in the session description or, if there are
no version identifiers, the content of the session description to see
if it has changed. If the session description has changed, the UAS
MUST adjust the session parameters accordingly, possibly after asking
the user for confirmation.
Versioning of the session description can be used to accommodate
the capabilities of new arrivals to a conference, add or delete
media, or change from a unicast to a multicast conference.
If the new session description is not acceptable, the UAS can reject
it by returning a 488 (Not Acceptable Here) response for the re-
INVITE. This response SHOULD include a Warning header field.
If a UAS generates a 2xx response and never receives an ACK, it
SHOULD generate a BYE to terminate the dialog.
A UAS MAY choose not to generate 180 (Ringing) responses for a re-
INVITE because UACs do not typically render this information to the
user. For the same reason, UASs MAY choose not to use an Alert-Info
header field or a body with Content-Disposition "alert" in responses
to a re-INVITE.
A UAS providing an offer in a 2xx (because the INVITE did not contain
an offer) SHOULD construct the offer as if the UAS were making a
brand new call, subject to the constraints of sending an offer that
updates an existing session, as described in [13] in the case of SDP.
Specifically, this means that it SHOULD include as many media formats
and media types that the UA is willing to support. The UAS MUST
ensure that the session description overlaps with its previous
session description in media formats, transports, or other parameters
that require support from the peer. This is to avoid the need for
the peer to reject the session description. If, however, it is
unacceptable to the UAC, the UAC SHOULD generate an answer with a
valid session description, and then send a BYE to terminate the
session.
