draft-ietf-sipping-sip-offeranswer-10.txt   draft-ietf-sipping-sip-offeranswer-11.txt 
Sipping T. Sawada Sipping P. Kyzivat
Internet-Draft KDDI Corporation Internet-Draft Cisco Systems, Inc.
Intended status: Informational P. Kyzivat Intended status: Informational T. Sawada
Expires: July 5, 2009 Cisco Systems, Inc. Expires: July 22, 2010 KDDI Corporation
January 1, 2009 January 18, 2010
SIP (Session Initiation Protocol) Usage of the Offer/Answer Model SIP (Session Initiation Protocol) Usage of the Offer/Answer Model
draft-ietf-sipping-sip-offeranswer-10 draft-ietf-sipping-sip-offeranswer-11
Abstract
The Session Initiation Protocol (SIP) utilizes the offer/answer model
to establish and update multimedia sessions using the Session
Description Protocol (SDP). The description of the offer/answer
model in SIP is dispersed across multiple RFCs. This document
summarizes all the current usages of the offer/answer model in SIP
communication.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 33 skipping to change at page 1, line 42
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on July 5, 2009. This Internet-Draft will expire on July 22, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
Abstract the Trust Legal Provisions and are provided without warranty as
described in the BSD License.
The Session Initiation Protocol (SIP) utilizes the offer/answer model
to establish and update multimedia sessions using the Session
Description Protocol (SDP). The description of the offer/answer
model in SIP is dispersed across multiple RFCs. This document
summarizes all the current usages of the offer/answer model in SIP
communication.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Summary of SIP usage of the Offer/Answer Model . . . . . . . . 4 2. Summary of SIP usage of the Offer/Answer Model . . . . . . . . 3
2.1. Offer/Answer Exchange Pairs in SIP Messages . . . . . . . 5 2.1. Offer/Answer Exchange Pairs in SIP Messages . . . . . . . 4
2.2. Rejection of an Offer . . . . . . . . . . . . . . . . . . 6 2.2. Rejection of an Offer . . . . . . . . . . . . . . . . . . 5
2.3. Session Description which is not Offer nor Answer . . . . 7 2.3. Session Description which is not Offer nor Answer . . . . 6
3. Detailed Discussion of the Offer/Answer Model for SIP . . . . 7 3. Detailed Discussion of the Offer/Answer Model for SIP . . . . 7
3.1. Offer/Answer for the INVITE method with 100rel 3.1. Offer/Answer for the INVITE method with 100rel
extension . . . . . . . . . . . . . . . . . . . . . . . . 7 extension . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1.1. INVITE Request with SDP . . . . . . . . . . . . . . . 8 3.1.1. INVITE Request with SDP . . . . . . . . . . . . . . . 8
3.1.2. INVITE request without SDP . . . . . . . . . . . . . . 10 3.1.2. INVITE request without SDP . . . . . . . . . . . . . . 9
3.2. Offer/Answer Exchange in Early Dialog . . . . . . . . . . 11 3.2. Offer/Answer Exchange in Early Dialog . . . . . . . . . . 10
3.3. Offer/Answer Exchange in an Established Dialog . . . . . . 11 3.3. Offer/Answer Exchange in an Established Dialog . . . . . . 11
3.4. Recovering From a Failed ReINVITE . . . . . . . . . . . . 11
4. Exceptional Case Handling . . . . . . . . . . . . . . . . . . 12 4. Exceptional Case Handling . . . . . . . . . . . . . . . . . . 12
4.1. Message Crossing Case Handling . . . . . . . . . . . . . . 12 4.1. Message Crossing Case Handling . . . . . . . . . . . . . . 12
4.2. Glare Case Handling . . . . . . . . . . . . . . . . . . . 14 4.2. Glare Case Handling . . . . . . . . . . . . . . . . . . . 14
5. Content of Offers and Answers . . . . . . . . . . . . . . . . 15 5. Content of Offers and Answers . . . . . . . . . . . . . . . . 15
5.1. General Principle for Constructing Offers and Answers . . 16 5.1. General Principle for Constructing Offers and Answers . . 16
5.2. Choice of Media Types and Formats to Include and 5.2. Choice of Media Types and Formats to Include and
Exclude . . . . . . . . . . . . . . . . . . . . . . . . . 16 Exclude . . . . . . . . . . . . . . . . . . . . . . . . . 16
5.2.1. Sending an Initial INVITE with Offer . . . . . . . . . 16 5.2.1. Sending an Initial INVITE with Offer . . . . . . . . . 16
5.2.2. Responding with an Offer when the Initial INVITE 5.2.2. Responding with an Offer when the Initial INVITE
has no Offer . . . . . . . . . . . . . . . . . . . . . 17 has no Offer . . . . . . . . . . . . . . . . . . . . . 17
5.2.3. Answering an Initial INVITE with Offer . . . . . . . . 17 5.2.3. Answering an Initial INVITE with Offer . . . . . . . . 17
5.2.4. Answering when the Initial INVITE had no Offer . . . . 18 5.2.4. Answering when the Initial INVITE had no Offer . . . . 18
5.2.5. Subsequent Offers and Answers . . . . . . . . . . . . 18 5.2.5. Subsequent Offers and Answers . . . . . . . . . . . . 18
5.3. Hold and Resume of media . . . . . . . . . . . . . . . . . 19 5.3. Hold and Resume of media . . . . . . . . . . . . . . . . . 19
5.4. Behavior on receiving SDP with c=0.0.0.0 . . . . . . . . . 20 5.4. Behavior on receiving SDP with c=0.0.0.0 . . . . . . . . . 20
6. Remaining Issues or Best Practices on Offer/Answer . . . . . . 20 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
6.1. Rejecting PRACK Offer . . . . . . . . . . . . . . . . . . 21 7. Security Considerations . . . . . . . . . . . . . . . . . . . 21
6.2. Commit/Rollback of Offer/Answer on Unsuccessful 8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 21
re-INVITE Transaction . . . . . . . . . . . . . . . . . . 21 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
6.3. Offer in a Reliable Response . . . . . . . . . . . . . . . 23 9.1. Normative References . . . . . . . . . . . . . . . . . . . 21
6.4. Requesting Hold while already on Hold . . . . . . . . . . 23 9.2. Informative References . . . . . . . . . . . . . . . . . . 22
7. Add New Offer/Answer Usage in SIP . . . . . . . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22
7.1. Explicit Usage . . . . . . . . . . . . . . . . . . . . . . 24
7.2. Rejection of an Offer . . . . . . . . . . . . . . . . . . 24
7.3. Backward Compatibility . . . . . . . . . . . . . . . . . . 24
7.4. Exceptional Case Handling . . . . . . . . . . . . . . . . 24
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
9. Security Considerations . . . . . . . . . . . . . . . . . . . 24
10. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 25
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25
11.1. Normative References . . . . . . . . . . . . . . . . . . . 25
11.2. Informative References . . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26
1. Introduction 1. Introduction
SIP utilizes the offer/answer model to establish and update sessions. SIP utilizes the offer/answer model to establish and update sessions.
The rules to govern the offer/answer behaviors in SIP are described The rules to govern the offer/answer behaviors in SIP are described
in the several RFCs. ([RFC3261], [RFC3262], [RFC3264], and in the several RFCs. ([RFC3261], [RFC3262], [RFC3264], [RFC3311],
[RFC3311].) and [I-D.camarillo-sipcore-reinvite].)
The primary purpose of this document is to describe all forms of SIP The primary purpose of this document is to describe all forms of SIP
usage of the offer/answer model in one document to help the readers usage of the offer/answer model in one document to help the readers
to fully understand it. Also, this document tries to incorporate the to fully understand it. Also, this document tries to incorporate the
results of the discussions on the controversial issues to avoid results of the discussions on the controversial issues to avoid
repeating the same discussions later. repeating the same discussions later.
This document is not intended to make normative changes. Rather, it This document does not make normative changes. Rather, it recommends
makes the remaining open issues clear and leaves them for further how to use the existing standards to best effect.
study.
1.1. Terminology 1.1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
This document only uses these key words when referencing normative This document only uses these key words when referencing normative
statements in existing RFCs. statements in existing RFCs.
2. Summary of SIP usage of the Offer/Answer Model 2. Summary of SIP usage of the Offer/Answer Model
skipping to change at page 4, line 44 skipping to change at page 3, line 43
applications using the offer/answer model. [RFC3264] defines the applications using the offer/answer model. [RFC3264] defines the
offer/answer model, but does not specify which SIP messages should offer/answer model, but does not specify which SIP messages should
convey an offer or an answer. This should be defined in the SIP core convey an offer or an answer. This should be defined in the SIP core
and extensions RFCs. and extensions RFCs.
In theory, any SIP message can include a session description in its In theory, any SIP message can include a session description in its
body. But a session description in a SIP message is not necessarily body. But a session description in a SIP message is not necessarily
an offer or an answer. Only certain session description usages that an offer or an answer. Only certain session description usages that
conform to the rules described in standards-track RFCs can be conform to the rules described in standards-track RFCs can be
interpreted as an offer or an answer. The rules for how to handle interpreted as an offer or an answer. The rules for how to handle
the offer/answer model are currently defined in several RFCs. the offer/answer model are defined in several RFCs.
The offer/answer model defines a mechanism for update of sessions. The offer/answer model defines a mechanism for update of sessions.
In SIP, a dialog is used to associate an offer/answer exchange with In SIP, a dialog is used to associate an offer/answer exchange with
the session which it is to update. In other words, only the offer/ the session which it is to update. In other words, only the offer/
answer exchange in the SIP dialog can update the session which is answer exchange in the SIP dialog can update the session which is
managed by that dialog. managed by that dialog.
2.1. Offer/Answer Exchange Pairs in SIP Messages 2.1. Offer/Answer Exchange Pairs in SIP Messages
Currently, the rules on the offer/answer model are defined in Currently, the rules on the offer/answer model are defined in
[RFC3261], [RFC3262], [RFC3264], and [RFC3311]. In these RFCs, only [RFC3261], [RFC3262], [RFC3264], [RFC3311] and
the six patterns shown in Table 1 are defined for exchanging an offer [I-D.camarillo-sipcore-reinvite]. In these RFCs, only the six
and an answer with SIP messages. patterns shown in Table 1 are defined for exchanging an offer and an
answer with SIP messages.
Note that an offer/answer exchange initiated by an INVITE request Note that an offer/answer exchange initiated by an INVITE request
must follow exactly one of the patterns 1, 2, 3, 4. When an initial must follow exactly one of the patterns 1, 2, 3, 4. When an initial
INVITE causes multiple dialogs due to forking, an offer/answer INVITE causes multiple dialogs due to forking, an offer/answer
exchange is carried out independently in each distinct dialog. When exchange is carried out independently in each distinct dialog. When
an INVITE request contains no offer, only pattern 2 or pattern 4 an INVITE request contains no offer, only pattern 2 or pattern 4
apply. 'The first reliable non-failure message' must have an offer apply. 'The first reliable non-failure message' must have an offer
if there is no offer in the INVITE request. This means that UA which if there is no offer in the INVITE request. This means that UA which
receives the INVITE request without an offer must include an offer in receives the INVITE request without an offer must include an offer in
the first reliable response with 100rel extension. If no reliable the first reliable response with 100rel extension. If no reliable
skipping to change at page 6, line 33 skipping to change at page 5, line 33
offer/answer to establish a multimedia session. offer/answer to establish a multimedia session.
The 'Est' column shows the ability to update the established session. The 'Est' column shows the ability to update the established session.
The 'Early' column indicates which patterns may be used to modify the The 'Early' column indicates which patterns may be used to modify the
established session in an early dialog. There are two ways to established session in an early dialog. There are two ways to
exchange a subsequent offer/answer in an early dialog. exchange a subsequent offer/answer in an early dialog.
2.2. Rejection of an Offer 2.2. Rejection of an Offer
It is not entirely clear how to reject an offer when it is It is not always clear how to reject an offer when it is
unacceptable, and some methods do not allow explicit rejection of an unacceptable, and some methods do not allow explicit rejection of an
offer. For each of the patterns in Table 1, Table 2 shows how to offer. For each of the patterns in Table 1, Table 2 shows how to
reject an offer. reject an offer.
When a UA receives an INVITE request with an unacceptable offer, it When a UA receives an INVITE request with an unacceptable offer, it
should respond with a 488 response, preferably with Warning header should respond with a 488 response, preferably with Warning header
field indicating the reason of the rejection, unless another response field indicating the reason of the rejection, unless another response
code is more appropriate to reject it. (Pattern 1 and Pattern 3) code is more appropriate to reject it. (Pattern 1 and Pattern 3.)
If this is a reINVITE extra care must be taken, as detailed in
[I-D.camarillo-sipcore-reinvite]. Specifically, if the offer
contains any changes or additions to media stream properties, and
those have already been used to transmit/receive media before the
final response is sent, then a 2xx response should be sent, with a
syntactically correct response. This may optionally be followed by
an UPDATE request to rearrange the session parameters if both ends
support the UPDATE method. Alternatively the UA may terminate the
dialog and send an error response to the INVITE request.
When a UA receives an UPDATE request with an offer which it can not When a UA receives an UPDATE request with an offer which it can not
accept, it should respond with a 488 response preferably with Warning accept, it should respond with a 488 response preferably with Warning
header field indicating the reason of the rejection, unless another header field indicating the reason of the rejection, unless another
response code is more appropriate to reject it. (Pattern 6) response code is more appropriate to reject it. (Pattern 6)
When a UA receives a PRACK request with an offer which it can not When a UA receives a PRACK request with an offer which it can not
accept, it may respond with a 200 response with a syntactically accept, it may respond with a 200 response with a syntactically
correct session description. This may optionally be followed by an correct session description. This may optionally be followed by an
UPDATE request to rearrange the session parameters if both ends UPDATE request to rearrange the session parameters if both ends
support the UPDATE method. Alternatively the UA may terminate the support the UPDATE method. Alternatively the UA may terminate the
dialog and send an error response to the INVITE request. The dialog and send an error response to the INVITE request. (Pattern 5)
validity and consequences of a 488 response to PRACK is an open issue (While it may be tempting to respond with a 488 response in this
which is discussed in Section 6.1. (Pattern 5) case, that is not recommended, because it does not acknowledge the
response.)
When a UA receives a response with an offer which it can not accept, When a UA receives a response with an offer which it can not accept,
the UA does not have a way to reject it explicitly. Therefore, a UA the UA does not have a way to reject it explicitly. Therefore, a UA
should respond to the offer with the correct session description and should respond to the offer with the correct session description and
rearrange the session parameters by initiating a new offer/answer rearrange the session parameters by initiating a new offer/answer
exchange, or alternatively terminate the session. (Pattern 2 and exchange, or alternatively terminate the session. (Pattern 2 and
Pattern 4) When initiating a new offer/answer, a UA should take care Pattern 4) When initiating a new offer/answer, a UA should take care
not to cause an infinite offer/answer loop. not to cause an infinite offer/answer loop.
Offer Rejection Offer Rejection
----------------------------------------------------- -----------------------------------------------------
1. INVITE Req. 488 INVITE Response 1. INVITE Req. (*) 488 INVITE Response
2. 2xx INVITE Resp. Answer in ACK Req. followed by new offer 2. 2xx INVITE Resp. Answer in ACK Req. followed by new offer
OR termination of dialog OR termination of dialog
3. INVITE Req. 488 INVITE Response (same as Pattern 1.) 3. INVITE Req. 488 INVITE Response (same as Pattern 1.)
4. 1xx-rel INVITE Resp. Answer in PRACK Req. followed by new offer 4. 1xx-rel INVITE Resp. Answer in PRACK Req. followed by new offer
5. PRACK Req. (*) 200 PRACK Resp. followed by new offer 5. PRACK Req. (**) 200 PRACK Resp. followed by new offer
OR termination of dialog OR termination of dialog
6. UPDATE Req. 488 UPDATE Response 6. UPDATE Req. 488 UPDATE Response
(*) A UA should only use PRACK to send an offer when it has strong (*) If this was a reINVITE, a failure response should not be sent if
media has already been exchanged using the new offer.
(**) A UA should only use PRACK to send an offer when it has strong
reasons to expect the receiver will accept the offer. reasons to expect the receiver will accept the offer.
Table 2. Rejection of an Offer Table 2. Rejection of an Offer
2.3. Session Description which is not Offer nor Answer 2.3. Session Description which is not Offer nor Answer
As previously stated, a session description in a SIP message is not As previously stated, a session description in a SIP message is not
necessarily an offer or an answer. For example, SIP can use a necessarily an offer or an answer. For example, SIP can use a
session description to describe capabilities apart from offer/answer session description to describe capabilities apart from offer/answer
exchange. Examples of this are 200 OK responses for OPTIONS and 488 exchange. Examples of this are 200 OK responses for OPTIONS and 488
skipping to change at page 12, line 7 skipping to change at page 11, line 40
The INVITE method needs at least three messages to complete but no The INVITE method needs at least three messages to complete but no
extensions are needed. Additionally, the INVITE method allows the extensions are needed. Additionally, the INVITE method allows the
peer to take time to decide whether it will accept a session update peer to take time to decide whether it will accept a session update
or not by sending provisional responses. That is, re-INVITE allows or not by sending provisional responses. That is, re-INVITE allows
the UAS to interact with the user at the peer, while UPDATE needs to the UAS to interact with the user at the peer, while UPDATE needs to
be answered automatically by the UAS. It is noted that re-INVITE be answered automatically by the UAS. It is noted that re-INVITE
should be answered immediately unless such a user interaction is should be answered immediately unless such a user interaction is
needed. Otherwise, some 3pcc flows will break. needed. Otherwise, some 3pcc flows will break.
3.4. Recovering From a Failed ReINVITE
If a reINVITE fails, the session parameters in effect prior to the
reINVITE MUST remain unchanged, as if no re-INVITE had been issued.
([RFC3261] section 14.1.) This remains the case even if multiple
offer/answer exchanges have occurred between the sending of the
reINVITE and its failure, and even if media has been exchanged using
the proposed changes in the session. Because this can be difficult
to achieve in practice, newer specifications call for the UAS to send
a 2xx response to a reINVITE in cases where rolling back changes
would be problematic.
Nevertheless, a UAC may receive a failure response to a reINVITE
after proposed changes that must be rolled back have already been
used. In such a case, the UAC should send an UPDATE offering the SDP
that has been reinstated. (See [I-D.camarillo-sipcore-reinvite] for
details.)
4. Exceptional Case Handling 4. Exceptional Case Handling
In [RFC3264], the following restrictions are defined with regard to In [RFC3264], the following restrictions are defined with regard to
sending a new offer. sending a new offer.
"At any time, either agent MAY generate a new offer that updates "At any time, either agent MAY generate a new offer that updates
the session. However, it MUST NOT generate a new offer if it has the session. However, it MUST NOT generate a new offer if it has
received an offer which it has not yet answered or rejected. It received an offer which it has not yet answered or rejected. It
MUST NOT generate a new offer if it has generated a prior offer MUST NOT generate a new offer if it has generated a prior offer
for which it has not yet received an answer or a rejection." for which it has not yet received an answer or a rejection."
skipping to change at page 19, line 7 skipping to change at page 19, line 7
NOTE: The behavior above is recommended, but it is not always NOTE: The behavior above is recommended, but it is not always
achievable - for example in some interworking scenarios. Or, the achievable - for example in some interworking scenarios. Or, the
offerer may simply not have enough resources to offer "everything" offerer may simply not have enough resources to offer "everything"
at that point. Even if the UAS is not able to offer any other SDP at that point. Even if the UAS is not able to offer any other SDP
that the one currently being used, it should not reject the re- that the one currently being used, it should not reject the re-
INVITE. Instead, it should generate an offer with the currently INVITE. Instead, it should generate an offer with the currently
used SDP with o- line unchanged. used SDP with o- line unchanged.
5.3. Hold and Resume of media 5.3. Hold and Resume of media
[RFC3264] specifies (non-normatively) that "hold" should be indicated [RFC3264] specifies (using non-normative language) that "hold" should
in an established session by sending a new offer containing be indicated in an established session by sending a new offer
"a=sendonly" for each media stream to be held. An answerer is then containing "a=sendonly" for each media stream to be held. An
to respond with "a=recvonly" to acknowledge that the hold request has answerer is then to respond with "a=recvonly" to acknowledge that the
been understood. hold request has been understood.
Note that the use of sendonly/recvonly is not limited to hold. These Note that the use of sendonly/recvonly is not limited to hold. These
may be used for other reasons, such as devices that are only capable may be used for other reasons, such as devices that are only capable
of sending or receiving. So receiving an offer with "a=sendonly" of sending or receiving. So receiving an offer with "a=sendonly"
must not be treated as a certain indication that the offerer has must not be treated as a certain indication that the offerer has
placed the media stream on hold. placed the media stream on hold.
This model is based on an assumption that the UA initiating the hold This model is based on an assumption that the UA initiating the hold
will want to play Music on Hold, which is not always the case. A UA will want to play Music on Hold, which is not always the case. A UA
may, if desired, initiate hold by offering "a=inactive" if it does may, if desired, initiate hold by offering "a=inactive" if it does
skipping to change at page 19, line 44 skipping to change at page 19, line 44
state of the recipient. However, a UA that has been "placed on hold" state of the recipient. However, a UA that has been "placed on hold"
may itself desire to initiate its own hold status, based on local may itself desire to initiate its own hold status, based on local
input. input.
If UA2 has previously been "placed on hold" by UA1, via receipt of If UA2 has previously been "placed on hold" by UA1, via receipt of
"a=sendonly", then it may initiate its own hold by sending a new "a=sendonly", then it may initiate its own hold by sending a new
offer containing "a=sendonly" to UA1. Upon receipt of that, UA1 will offer containing "a=sendonly" to UA1. Upon receipt of that, UA1 will
answer with "a=inactive" because that is the only valid answer that answer with "a=inactive" because that is the only valid answer that
reflects its desire not to receive media. reflects its desire not to receive media.
NOTE: Section 8.4 of RFC3264 contains a conflicting recommendation
that the offer contain "a=inactive" in this case. We interpret
that recommendation to be non-normative. The use of "a=sendonly"
in this case will never produce a worse outcome, and can produce a
better outcome in useful cases.
Once in this state, to resume a two way exchange of media each side Once in this state, to resume a two way exchange of media each side
must reset its local hold status. If UA1 is first to go off hold it must reset its local hold status. If UA1 is first to go off hold it
will then send an offer with "a=sendrecv". The UA2 will respond with will then send an offer with "a=sendrecv". The UA2 will respond with
its desired state of "a=sendonly" because that is a permitted its desired state of "a=sendonly" because that is a permitted
response. When UA2 desires to also resume, it will send an offer response. When UA2 desires to also resume, it will send an offer
with "a=sendrecv". In this case, because UA1 has the same desire it with "a=sendrecv". In this case, because UA1 has the same desire it
will respond with "a=sendrecv". In the same case, when UA2 receives will respond with "a=sendrecv". In the same case, when UA2 receives
the offer with "a=sendrecv", if it has decided it wants to reset its the offer with "a=sendrecv", if it has decided it wants to reset its
local hold but has not yet signaled the intent, it may send local hold but has not yet signaled the intent, it may send
"a=sendrecv" in the answer. "a=sendrecv" in the answer.
skipping to change at page 20, line 38 skipping to change at page 20, line 44
with a connection address of 0.0.0.0, in which case it means that with a connection address of 0.0.0.0, in which case it means that
neither RTP nor RTCP should be sent to the peer. neither RTP nor RTCP should be sent to the peer.
If a UA generates an answer to the offer received with c=0.0.0.0, the If a UA generates an answer to the offer received with c=0.0.0.0, the
direction attribute of the accepted media stream in the answer must direction attribute of the accepted media stream in the answer must
be based on direction attribute of the offered stream and rules be based on direction attribute of the offered stream and rules
specified in RFC 3264 to form the a-line in the answer. c=0.0.0.0 has specified in RFC 3264 to form the a-line in the answer. c=0.0.0.0 has
no special meaning for the direction attribute of the accepted stream no special meaning for the direction attribute of the accepted stream
in the answer. in the answer.
6. Remaining Issues or Best Practices on Offer/Answer 6. IANA Considerations
This document clarifies the offer/answer usage in SIP and summarizes
the correct or recommended behaviors along with the existing RFCs.
To create any new normative behaviors beyond these RFCs is not the
intent of this document.
However, through the scrutiny of the offer/answer model in SIP, some
issues are found to be unresolved within the current set of RFCs.
Those remaining issues are described in this section mainly for
further study.
6.1. Rejecting PRACK Offer
As stated in Section 2.2 and Section 3.2, it is recommended that an
offer not be sent in a PRACK request unless UAC has strong reasons to
assume the receiver will accept it. Even so, there may be cases when
the UAS has to reject the offer for some reason. The current RFCs do
not provide a way to reject the offer and at the same time to
indicate that the PRACK adequately acknowledged the reliable
response. It is unclear whether a non-200 response can still
indicate an acknowledgement of the reliable response.
Several ideas were presented to resolve this issue, such as sending
2xx PRACK response without SDP to reject the offer, or sending SDP
with a decreased version value in the o-line. Some of the candidates
may also be adapted as a way to reject an unacceptable offer in a
response. Anyway, those proposals violate the current rules and lose
backward compatibility to some extent (e.g. section 5 of [RFC3262]).
It is beyond the scope of this document and remains for further
study.
The 488 response is another proposed solution; however the validity
and consequences of a 488 response to PRACK is an open issue.
Because the 488 response may be sent by a proxy, the UAC cannot
assume the reliable transaction has been adequately acknowledged. If
a 488 response is received, the UAC should ensure acknowledgment of
the reliable response by sending a new PRACK with the offer removed
or modified based upon the received 488 response. If the 488
response is sent by UAS (open issue), it cannot assume that the UAC
thinks that the reliable transaction has been adequately acknowledged
even though the UAS may treat otherwise (open issue). If a 488
response is sent by UAS, the UAC should accommodate receiving the
altered PRACK with higher CSeq without expecting it to trigger a 481
response (open issue).
NOTE: Deprecation of the usage of offer in PRACK may be another
solution. As the precondition mechanism specification [RFC3262]
explicitly shows a usage of sending offer in PRACK, its
deprecation could cause backward compatibility issues.
6.2. Commit/Rollback of Offer/Answer on Unsuccessful re-INVITE
Transaction
When a re-INVITE transaction fails, the dialog remains with the
session bound to it. The issue here is: what is the session status
if an offer/answer exchange has been completed (if a session
description has been sent in a reliable provisional response to the
re-INVITE request), or if subsequent offer/answer exchanges have
taken place (using UPDATE or PRACK transactions), before the re-
INVITE transaction is terminated with a final error response (Figure
6). One option is to take those offer/answer exchanges not committed
yet and to make the session status rollback to the one before re-
INVITE transaction was initiated. Another option is to take those
exchanges committed and to keep the session status as it is even
after re-INVITE fails. There is no clear consensus on which one is
the correct behavior.
There are some cases where it is useful to exchange offer(s)/
answer(s) even before re-INVITE completes. The case of adding a new
media (like adding video to audio only session) which requires
permission from the peer through some user interaction is one
example. Precondition procedures can be another case which may
require several offer/answer exchanges in one re-INVITE transaction.
UAC UAS
| session established |
|<===================>|
| |
| F1 re-INVITE (SDP) |
|-------------------->|
| F2 1xx-rel (SDP) |
|<--------------------|
| F3 PRACK | <- PRACK request may include new offer
|-------------------->| and can complete the offer/answer with
| F4 2xx PRA | the answer in 2xx PRACK response.
|<--------------------|
| | <- UPDATE method can update the session
| | status before receiving the final
| F5 4xx/5xx/6xx INV | response to re-INVITE request (F1).
|<--------------------|
| F6 ACK |
|-------------------->| Issue: What is the correct session
| | status after re-INVITE transaction.
Figure 6 Commit/Rollback Issue with re-INVITE transaction
To make bad things worse, if a new offer from UAC and the final
response to re-INVITE are sent at nearly the same time, the UAS can
not know whether this new offer was sent before or after UAC received
the final failure response (Figure 7). Note that the ACK request to
the failure response is sent hop-by-hop basis, therefore even after
receiving the ACK request, UAS can not make sure that UPDATE request
was sent after the final response had been reached to the other end.
Sending a new UPDATE request from UAC to synchronize the status
anytime after the re-INVITE fails may be a good option. This
solution, however, requires that the UPDATE method be supported by
both ends and needs care to avoid flapping when each end tries to
advertise their different views of the session status.
The proper handling of this issue is undefined by existing standards.
Resolution is beyond the scope of this document, and will require a
new normative document.
UAC UAS
| session established |
|<===================>|
| |
| F1 re-INVITE (SDP) |
|-------------------->|
| F2 1xx-rel (SDP) |
|<--------------------|
| F3 PRACK |
|-------------------->|
| F4 2xx PRA |
|<--------------------|
| |
|UPDATE(SDP) 4xx INV |
|---------\ /--------|
| \/ |
| /\ |
|<--------/ \------->|
| |
Figure 7 Commit/Rollback Issue with Race Condition
6.3. Offer in a Reliable Response
In RFC 3261, it is stated that when an INVITE is sent without an
offer, the first reliable response MUST contain an offer. There was
discussion on whether this rule can be loosened up. There is no
clear explanation why this restriction is defined. However, this
rule will be left as it is, unless the strong necessity to loosen it
up is raised in the future.
6.4. Requesting Hold while already on Hold
RFC 3264, section 8.4, contains procedures for putting a unicast
media stream on hold. Of particular note, it states:
"If the stream to be placed on hold was previously a recvonly
media stream, it is placed on hold by marking it inactive."
Section 5.3 of the current document makes a recommendation for this
case which conflicts with that, and explains why. Some concerns have
been raised that such a recommendation is invalid because RFC 3264 is
normative on this subject.
This document takes the position that Section 8.4 of RFC 3264 is non-
normative, and so may be overridden. It is further recommended that
RFC 3264 be revised to avoid the confusion.
7. Add New Offer/Answer Usage in SIP
This document recommends against the addition of new offer/answer
methods using SIP. However, it may be necessary to define new offer/
answer exchange methods as SIP extensions evolve. This section
recommends some things that should be taken into considerations in
that case.
7.1. Explicit Usage
New method definitions should define offer/answer usage explicitly
without any ambiguity.
7.2. Rejection of an Offer
New method definitions should define how to reject an offer where
possible.
7.3. Backward Compatibility
New methods must keep backward compatibility.
7.4. Exceptional Case Handling
New methods should take care of how to handle exceptional cases,
message crossing case and glare case.
8. IANA Considerations
This document has no actions for IANA. This document has no actions for IANA.
9. Security Considerations 7. Security Considerations
There are not any security issues beyond the referenced RFCs. There are not any security issues beyond the referenced RFCs.
10. Acknowledgement 8. Acknowledgement
The authors would like to thank Christer Holmberg, Rajeev Seth, The authors would like to thank Christer Holmberg, Rajeev Seth,
Nataraju A B, Byron Campen and Jonathan Rosenberg for their thorough Nataraju A B, Byron Campen, Jonathan Rosenberg, Gonzalo Camarillo and
reviews and comments. Many of their suggestions and ideas are Shinji Okumura for their thorough reviews and comments. Many of
incorporated to complete this document. their suggestions and ideas have been incorporated in this document.
11. References 9. References
11.1. Normative References 9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002. June 2002.
[RFC3262] Rosenberg, J. and H. Schulzrinne, "Reliability of [RFC3262] Rosenberg, J. and H. Schulzrinne, "Reliability of
skipping to change at page 25, line 39 skipping to change at page 21, line 43
with Session Description Protocol (SDP)", RFC 3264, with Session Description Protocol (SDP)", RFC 3264,
June 2002. June 2002.
[RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP) [RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP)
UPDATE Method", RFC 3311, October 2002. UPDATE Method", RFC 3311, October 2002.
[RFC3312] Camarillo, G., Marshall, W., and J. Rosenberg, [RFC3312] Camarillo, G., Marshall, W., and J. Rosenberg,
"Integration of Resource Management and Session Initiation "Integration of Resource Management and Session Initiation
Protocol (SIP)", RFC 3312, October 2002. Protocol (SIP)", RFC 3312, October 2002.
11.2. Informative References [I-D.camarillo-sipcore-reinvite]
Camarillo, G., Holmberg, C., and G. yang, "Re-INVITE and
Target-refresh Request Handling in the Session Initiation
Protocol (SIP)", draft-camarillo-sipcore-reinvite-01 (work
in progress), October 2009.
9.2. Informative References
[RFC3959] Camarillo, G., "The Early Session Disposition Type for the [RFC3959] Camarillo, G., "The Early Session Disposition Type for the
Session Initiation Protocol (SIP)", RFC 3959, Session Initiation Protocol (SIP)", RFC 3959,
December 2004. December 2004.
[I-D.ietf-sipping-config-framework] [I-D.ietf-sipping-config-framework]
Channabasappa, S., "A Framework for Session Initiation Channabasappa, S., "A Framework for Session Initiation
Protocol User Agent Profile Delivery", Protocol User Agent Profile Delivery",
draft-ietf-sipping-config-framework-15 (work in progress), draft-ietf-sipping-config-framework-16 (work in progress),
February 2008. September 2009.
Authors' Addresses Authors' Addresses
Takuya Sawada
KDDI Corporation
3-10-10, Iidabashi, Chiyoda-ku
Tokyo
Japan
Email: tu-sawada@kddi.com
Paul H. Kyzivat Paul H. Kyzivat
Cisco Systems, Inc. Cisco Systems, Inc.
1414 Massachusetts Avenue 1414 Massachusetts Avenue
Boxborough, MA 01719 Boxborough, MA 01719
USA USA
Email: pkyzivat@cisco.com Email: pkyzivat@cisco.com
Takuya Sawada
KDDI Corporation
3-10-10, Iidabashi, Chiyoda-ku
Tokyo
Japan
Email: tu-sawada@kddi.com
 End of changes. 32 change blocks. 
275 lines changed or deleted 114 lines changed or added

This html diff was produced by rfcdiff 1.37b. The latest version is available from http://tools.ietf.org/tools/rfcdiff/