draft-ietf-sipping-sip-offeranswer-04.txt   draft-ietf-sipping-sip-offeranswer-05.txt 
SIPPING Working Group T. Sawada SIPPING Working Group T. Sawada
Internet Draft KDDI Corporation Internet Draft KDDI Corporation
Intended status: Informational P. Kyzivat Intended status: Informational P. Kyzivat
Expires: April 2008 Cisco Systems, Inc. Expires: July 2008 Cisco Systems, Inc.
October 24, 2007 January 13, 2008
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-04.txt draft-ietf-sipping-sip-offeranswer-05.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that By submitting this Internet-Draft, each author represents that
any applicable patent or other IPR claims of which he or she is any applicable patent or other IPR claims of which he or she is
aware have been or will be disclosed, and any of which he or she aware have been or will be disclosed, and any of which he or she
becomes aware will be disclosed, in accordance with Section 6 of becomes aware will be disclosed, in accordance with Section 6 of
BCP 79. 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 other groups may also distribute working documents as Internet-
Internet-Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six
and may be updated, replaced, or obsoleted by other documents at any months and may be updated, replaced, or obsoleted by other
time. It is inappropriate to use Internet-Drafts as reference documents at any time. It is inappropriate to use Internet-Drafts
material or to cite them other than as "work in progress." as reference 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 November 24, 2007. This Internet-Draft will expire on November 13, 2007.
Abstract Abstract
SIP utilizes the offer/answer model to establish and update The Session Initiation Protocol (SIP) utilizes the offer/answer
multimedia sessions. The descriptions on how to use offer/answer in model to establish and update multimedia sessions using the Session
SIP are dispersed in the multiple RFCs. This document summarizes all Description Protocol (SDP). The description of the offer/answer
the current usage of the offer/answer model in SIP communication. 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...................................................3
2. Summary of SIP usage of the Offer/Answer Model.................3 1. Introduction..................................................3
2.1. Offer/Answer Exchange Pairs in SIP Messages...............3 2. Summary of SIP usage of the Offer/Answer Model................3
2.2. Rejection against an Offer................................5 2.1. Offer/Answer Exchange Pairs in SIP Messages..............3
2.3. Session Description which is not Offer nor Answer.........6 2.2. Rejection of an Offer....................................5
3. Detailed Discussion on the Offer/Answer Model for SIP..........6 2.3. Session Description which is not Offer nor Answer........6
3.1. Offer/Answer for INVITE method with 100rel extension......6 3. Detailed Discussion of the Offer/Answer Model for SIP.........6
3.1.1. INVITE Request with SDP..............................7 3.1. Offer/Answer for the INVITE method with 100rel extension.6
3.1.2. INVITE request without SDP...........................9 3.1.1. INVITE Request with SDP.............................7
3.2. Offer/Answer Exchange in Early Dialog....................10 3.1.2. INVITE request without SDP..........................9
3.3. Offer/Answer Exchange in Established Dialog..............10 3.2. Offer/Answer Exchange in Early Dialog...................10
4. Exceptional Case Handling.....................................11 3.3. Offer/Answer Exchange in an Established Dialog..........10
4.1. Message Crossing Case Handling...........................11 4. Exceptional Case Handling....................................11
4.2. Glare Case Handling......................................13 4.1. Message Crossing Case Handling..........................11
5. Content of Offers and Answers.................................14 4.2. Glare Case Handling.....................................14
5.1. General Principle for Constructing Offers and Answers....15 5. Content of Offers and Answers................................15
5.2. Choice of Media Types and Formats to Include and Exclude.15 5.1. General Principle for Constructing Offers and Answers...15
5.2.1. Sending Initial INVITE with Offer...................15 5.2. Choice of Media Types and Formats to Include and Exclude16
5.2.2. Responding with Offer when Initial INVITE has no Offer16 5.2.1. Sending an Initial INVITE with Offer...............16
5.2.3. Answering Initial INVITE with Offer.................16 5.2.2. Responding with an Offer when the Initial INVITE has
5.2.4. Answering when Initial INVITE had no Offer..........17 no Offer..................................................16
5.2.5. Subsequent Offers and Answers.......................17 5.2.3. Answering an Initial INVITE with Offer.............17
5.3. Hold and Resume of media.................................18 5.2.4. Answering when the Initial INVITE had no Offer.....18
5.4. Behavior on receiving SDP with c=IN IP4 0.0.0.0..........19 5.2.5. Subsequent Offers and Answers......................18
6. Remaining Issues or Best Practices on Offer/Answer............20 5.3. Hold and Resume of media................................19
6.1. Rejecting PRACK Offer....................................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.1. Rejecting PRACK Offer...................................21
6.2. Commit/Rollback of Offer/Answer on Unsuccessful re-INVITE 6.2. Commit/Rollback of Offer/Answer on Unsuccessful re-INVITE
Transaction...................................................20 Transaction..................................................21
6.3. Offer in a Reliable Response.............................22 6.3. Offer in a Reliable Response............................23
7. Add New Offer/Answer Usage in SIP.............................22 6.4. Requesting Hold while already on Hold...................23
7.1. Explicit Usage...........................................22 7. Add New Offer/Answer Usage in SIP............................24
7.2. Rejection of an Offer....................................23 7.1. Explicit Usage..........................................24
7.3. Backward Compatibility...................................23 7.2. Rejection of an Offer...................................24
7.4. Exceptional Case Handling................................23 7.3. Backward Compatibility..................................24
8. IANA Considerations...........................................23 7.4. Exceptional Case Handling...............................24
9. Security Considerations.......................................23 8. IANA Considerations..........................................24
10. Acknowledgement..............................................23 9. Security Considerations......................................24
11. References...................................................23 10. References..................................................25
11.1. Normative References....................................23 10.1. Normative References...................................25
11.2. Informative References..................................24 10.2. Informative References.................................25
Author's Addresses...............................................24 Author's Addresses..............................................25
Full Copyright Statement.........................................24 Full Copyright Statement........................................26
Intellectual Property Statement..................................25 Intellectual Property Statement.................................26
Acknowledgment...................................................25 Acknowledgment..................................................27
1. Introduction 1. Introduction
SIP utilizes the offer/answer model to establish and update the SIP utilizes the offer/answer model to establish and update the
session. The rules to govern the offer/answer behaviors in SIP are session. The rules to govern the offer/answer behaviors in SIP are
described in the several RFCs. described in the several RFCs.
The primary purpose of this document is to describe the whole set of 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 SIP usage of the offer/answer model in one document to help the
readers to fully understand it. Also, this document tries to readers to fully understand it. Also, this document tries to
incorporate the results of the discussions on the controversial incorporate the results of the discussions on the controversial
issues to avoid repeating the same discussions later. issues to avoid repeating the same discussions later.
This document is not intended to create any new normative methods. This document is not intended to make normative changes. Rather, it
Rather, it makes the remaining issues clear and leaves them for makes the remaining open issues clear and leaves them for further
further study. study.
2. Summary of SIP usage of the Offer/Answer Model 2. Summary of SIP usage of the Offer/Answer Model
The offer/answer model itself is independent from the higher layer The offer/answer model itself is independent from the higher layer
application protocols which utilize it. SIP is one of the application protocols which utilize it. SIP is one of the
applications using the offer/answer model. RFC 3264 [3] defines the applications using the offer/answer model. RFC 3264 [3] defines the
offer/answer model, but does not specify which SIP message 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
and extensions RFCs. core 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 the session description that conforms to an offer or an answer. Only certain session description usages that
the rules described in the standards-track RFCs can be interpreted as conform to the rules described in standards-track RFCs can be
an offer or an answer. The rules for how to handle the offer/answer interpreted as an offer or an answer. The rules for how to handle
model are currently defined in several RFCs. the offer/answer model are currently defined in several RFCs.
The offer/answer model defines the update of sessions. In SIP, dialog The offer/answer model defines a mechanism for update of sessions.
is used to match the offer/answer exchange to the session which is to In SIP, a dialog is used to associate an offer/answer exchange with
be updated with it. In other words, only the offer/answer exchange in the session which it is to update. In other words, only the
the SIP dialog can update the session which is managed with it. offer/answer exchange in the SIP dialog can update the session
which is 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 RFC Currently, the rules on the offer/answer model are defined in RFC
3261 [1], RFC 3262 [2] and RFC 3311 [4]. In these RFCs, only the six 3261 [1], RFC 3262 [2] and RFC 3311 [4]. In these RFCs, only the
patterns shown in Table 1 are defined for exchanging an offer and an six patterns shown in Table 1 are defined for exchanging an offer
answer with SIP messages. 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. exchange is carried out independently in each distinct dialog. When
Pattern 2 and pattern 4 can occur only when the INVITE request does an INVITE request contains no offer, only pattern 2 or pattern 4
not include an offer. 'The first reliable non-failure message' must apply. 'The first reliable non-failure message' must have an offer
have an offer if there is no offer in the INVITE request. This means if there is no offer in the INVITE request. This means that UA
that UA which receives the INVITE request without an offer must which receives the INVITE request without an offer must include an
include an offer in the first reliable response with 100rel offer in the first reliable response with 100rel extension. If no
extension. If no reliable provisional response has been sent, the UAS reliable provisional response has been sent, the UAS must include
must include an offer when sending 2xx response. an offer when sending 2xx response.
In pattern 3, the first reliable provisional response may or may not In pattern 3, the first reliable provisional response may or may
have an answer. When a reliable provisional response contains a not have an answer. When a reliable provisional response contains a
session description, and is the first to do so, then that session session description, and is the first to do so, then that session
description is the answer to the offer in the INVITE request. The description is the answer to the offer in the INVITE request. The
answer can not be updated, and a new offer can not be sent, in a answer can not be updated, and a new offer can not be sent in a
subsequent reliable response for the same INVITE transaction. subsequent reliable response for the same INVITE transaction.
In pattern 5, a PRACK request can contain an offer only if the In pattern 5, a PRACK request can contain an offer only if the
reliable response which it acknowledges contains an answer in the reliable response which it acknowledges contains an answer to the
previous offer/answer exchange. previous offer/answer exchange.
NOTE: It is legal to have UPDATE/2xx exchanges without NOTE: It is legal to have UPDATE/2xx exchanges without
offer/answer exchanges (pattern 6). As opposed to that, when re- offer/answer exchanges (pattern 6). However when re-INVITEs
INVITEs are sent without a desire for an offer/answer exchange, are sent for non-offer/answer purposes, an offer/answer
an offer/answer exchange cannot be avoided. In that case it is exchange is required. In that case the prior SDP will
often possible to use the current SDP. (See section 5. for typically be repeated.
details.)
There may be ONLY ONE offer/answer negotiation in progress for a There may be ONLY ONE offer/answer negotiation in progress for a
single dialog at any point in time. Section 4 explains how to ensure single dialog at any point in time. Section 4 explains how to
this. When an INVITE results in multiple dialogs each has a separate ensure this. When an INVITE results in multiple dialogs each has a
offer/answer negotiation. separate offer/answer negotiation.
NOTE: This is when using a Content-Disposition of "session". NOTE: This is when using a Content-Disposition of "session".
There may be a second offer/answer negotiation in progress using There may be a second offer/answer negotiation in progress
a Content-Disposition of "early-session" [6]. That is not using a Content-Disposition of "early-session" [6]. That is
addressed by this draft. not addressed by this draft.
Offer Answer RFC Ini Est Early Offer Answer RFC Ini Est Early
------------------------------------------------------------------- -------------------------------------------------------------------
1. INVITE Req. 2xx INVITE Resp. RFC 3261 Y Y N 1. INVITE Req. 2xx INVITE Resp. RFC 3261 Y Y N
2. 2xx INVITE Resp. ACK Req. RFC 3261 Y Y N 2. 2xx INVITE Resp. ACK Req. RFC 3261 Y Y N
3. INVITE Req. 1xx-rel INVITE Resp. RFC 3262 Y Y N 3. INVITE Req. 1xx-rel INVITE Resp. RFC 3262 Y Y N
4. 1xx-rel INVITE Resp. PRACK Req. RFC 3262 Y Y N 4. 1xx-rel INVITE Resp. PRACK Req. RFC 3262 Y Y N
5. PRACK Req. 200 PRACK Resp. RFC 3262 N Y Y 5. PRACK Req. 200 PRACK Resp. RFC 3262 N Y Y
6. UPDATE Req. 2xx UPDATE Resp. RFC 3311 N Y Y 6. UPDATE Req. 2xx UPDATE Resp. RFC 3311 N Y Y
skipping to change at page 5, line 4 skipping to change at page 5, line 15
Offer Answer RFC Ini Est Early Offer Answer RFC Ini Est Early
------------------------------------------------------------------- -------------------------------------------------------------------
1. INVITE Req. 2xx INVITE Resp. RFC 3261 Y Y N 1. INVITE Req. 2xx INVITE Resp. RFC 3261 Y Y N
2. 2xx INVITE Resp. ACK Req. RFC 3261 Y Y N 2. 2xx INVITE Resp. ACK Req. RFC 3261 Y Y N
3. INVITE Req. 1xx-rel INVITE Resp. RFC 3262 Y Y N 3. INVITE Req. 1xx-rel INVITE Resp. RFC 3262 Y Y N
4. 1xx-rel INVITE Resp. PRACK Req. RFC 3262 Y Y N 4. 1xx-rel INVITE Resp. PRACK Req. RFC 3262 Y Y N
5. PRACK Req. 200 PRACK Resp. RFC 3262 N Y Y 5. PRACK Req. 200 PRACK Resp. RFC 3262 N Y Y
6. UPDATE Req. 2xx UPDATE Resp. RFC 3311 N Y Y 6. UPDATE Req. 2xx UPDATE Resp. RFC 3311 N Y Y
Table 1. Summary of SIP Usage of the Offer/Answer Model Table 1. Summary of SIP Usage of the Offer/Answer Model
In Table 1, '1xx-rel' corresponds to the reliable provisional In Table 1, '1xx-rel' corresponds to the reliable provisional
response which contains the 100rel option defined in RFC 3262 [2]. response which contains the 100rel option defined in RFC 3262 [2].
The 'Ini' column shows the ability to exchange the offer/answer to The 'Ini' column shows the ability to exchange the offer/answer to
initiate the session. 'Y' indicates that the pattern can be used in initiate the session. 'Y' indicates that the pattern can be used in
the initial offer/answer exchange, while 'N' indicates that it can the initial offer/answer exchange, while 'N' indicates that it can
not. Only the initial INVITE transaction can be used to exchange the not. Only the initial INVITE transaction can be used to exchange
offer/answer to establish multimedia session. the 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
established session in an early dialog. There are two ways to the 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 against an Offer 2.2. Rejection of an Offer
How to reject an offer when it can not be accepted is not so clear It is not entirely clear how to reject an offer when it is
and some methods can not allow explicit rejection against an offer. unacceptable, and some methods do not allow explicit rejection of
Corresponding to the patterns in Table 1, how to reject an offer is an offer. For each of the patterns in Table 1, Table 2 shows how to
shown in Table 2. 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
code is more appropriate to reject it. (Pattern 1 and Pattern 3) response code is more appropriate to reject it. (Pattern 1 and
Pattern 3)
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
header field indicating the reason of the rejection, unless another Warning header field indicating the reason of the rejection, unless
response code is more appropriate to reject it. (Pattern 6) another 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 followed by an UPDATE request possibly to correct session description. This may optionally be followed by an
rearrange the session parameters if both ends support UPDATE method, UPDATE request to rearrange the session parameters if both ends
or alternatively terminate the dialog and send an error response to support the UPDATE method. Alternatively the UA may terminate the
the INVITE request. (Pattern 5) dialog and send an error response to the INVITE request. (Pattern
5)
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,
a 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
rearrange the session parameters by initiating a new offer/answer and rearrange the session parameters by initiating a new
exchange, or alternatively terminate the session. (Pattern 2 and offer/answer exchange, or alternatively terminate the session.
Pattern 4) When initiating a new offer/answer, a UA should take care (Pattern 2 and Pattern 4.) When initiating a new offer/answer, a UA
not to cause a never-ending offer/answer loop. should take care 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
Table 2. Rejection against an Offer Table 2. Rejection of an Offer
(*) UA should only use PRACK to send an offer when it has strong (*) A UA should only use PRACK to send an offer when it has strong
reasons to assume the receiver will accept. reasons to expect the receiver will accept the 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 session necessarily an offer or an answer. For example, SIP can use a
description to describe capabilities apart from offer/answer session description to describe capabilities apart from
exchange. Examples of this are 200 OK responses for OPTIONS and 488 offer/answer exchange. Examples of this are 200 OK responses for
responses for INVITE. OPTIONS and 488 responses for INVITE.
3. Detailed Discussion on the Offer/Answer Model for SIP 3. Detailed Discussion of the Offer/Answer Model for SIP
3.1. Offer/Answer for INVITE method with 100rel extension 3.1. Offer/Answer for the INVITE method with 100rel extension
The INVITE method provides the basic procedure for offer/answer The INVITE method provides the basic procedure for offer/answer
exchange in SIP. Without the 100rel option, the rules are simple as exchange in SIP. Without the 100rel option, the rules are simple as
described in RFC 3261 [1]. If an INVITE request includes a session described in RFC 3261 [1]. If an INVITE request includes a session
description, pattern 1 is applied and if an INVITE request does not description, pattern 1 is applied and if an INVITE request does not
include a session description, pattern 2 is applied. include a session description, pattern 2 is applied.
With 100rel, pattern 3 and pattern 4 are added and this makes the With 100rel, pattern 3 and pattern 4 are added and this complicates
rules complicated. An INVITE request may cause multiple responses. the rules. An INVITE request may cause multiple responses. Note
Note that even if both UAs support the 100rel extension, not all the that even if both UAs support the 100rel extension, not all the
provisional responses may be sent reliably. Note also that a reliable provisional responses may be sent reliably. Note also that a
provisional response is allowed without a session description if the reliable provisional response is allowed without a session
UAS does not wish to send the answer yet. An unreliable provisional description if the UAS does not wish to send the answer yet. An
response may include a session description in the body if the UAS has unreliable provisional response may include a session description
not sent a reliable response, but its session description is neither in the body if the UAS has not sent a reliable response, but its
an offer nor an answer. All the session descriptions in the session description is neither an offer nor an answer. All the
unreliable responses to the INVITE request must be identical to the session descriptions in the unreliable responses to the INVITE
answer which is included in the reliable response. Session request must be identical to the answer which is included in the
descriptions in an unreliable response that precedes a reliable reliable response. A session description in an unreliable response
response can be considered a "preview" of the answer that will be that precedes a reliable response can be considered a "preview" of
coming, and hence may be treated like an answer until the actual one the answer that will be coming, and hence may be treated like an
arrives. answer until the actual one arrives.
NOTE: This "preview" session description rule applies to a NOTE: This "preview" session description rule applies to a
single offer/answer exchange. In parallel offer/answer exchanges single offer/answer exchange. In parallel offer/answer
(caused by forking) a UA may obviously receive the different exchanges (caused by forking) a UA may obviously receive a
"preview" of answer in each dialog. UAs are expected to deal different "preview" of an answer in each dialog. UAs are
with this. expected to deal with this.
Although RFC 3261 says a UA should accept media once the INVITE has Although RFC 3261 says a UA should accept media once an INVITE with
been sent, in many cases, an answer (or, at least a preview of it) is an offer has been sent, in many cases, an answer (or, at least a
required in order for media to be accepted. Therefore, a UAS should preview of it) is required in order for media to be accepted.
send an SDP answer reliably (if possible) before it starts sending Therefore, a UAS should send an SDP answer reliably (if possible)
media. And, if either the UAC or the UAS does not support 100rel, it before it starts sending media. And, if neither the UAC nor the UAS
should still send a preview of the answer before it starts sending support 100rel, the UAS should send a preview of the answer before
media. it starts sending media.
3.1.1. INVITE Request with SDP 3.1.1. INVITE Request with SDP
When a UAC includes an SDP body in the INVITE request as an offer, it When a UAC includes an SDP body in the INVITE request as an offer,
expects the answer to be received with one of the reliable responses. it expects the answer to be received with one of the reliable
Other than that, no offer/answer exchanges can occur in the messages responses. Other than that, no offer/answer exchanges can occur in
within the INVITE transaction. the messages within the INVITE transaction.
UAC UAS UAC UAS
| F1 INVITE (SDP) | <- The offer in the offer/answer model | F1 INVITE (SDP) | <- The offer in the offer/answer model
|-------------------->| |-------------------->|
| F2 1xx (SDP) | <- The offer/answer exchange is not closed | F2 1xx (SDP) | <- The offer/answer exchange is not
|<--------------------| yet, but UAC acts as if it receives the |<--------------------| closed yet, but UAC acts as if it
| | ^ answer. | | ^ receives the answer.
| F3 1xx-rel (no SDP) | |<- a 1xx-rel may be sent without answer | F3 1xx-rel (no SDP) | |<- a 1xx-rel may be sent without answer
|<--------------------| | SDP. |<--------------------| | SDP.
| F4 PRACK (no SDP) | | | F4 PRACK (no SDP) | |
|-------------------->| | UAC must not send a new offer. |-------------------->| | UAC must not send a new offer.
| F5 2xx PRA (no SDP) | | | F5 2xx PRA (no SDP) | |
|<--------------------| v |<--------------------| v
| | | |
| F6 1xx-rel (SDP) | <- The answer in the offer/ answer model | F6 1xx-rel (SDP) | <- The answer in the offer/ answer model
|<--------------------| - |<--------------------| -
| F7 PRACK | | UAC can send a new offer in a PRACK | F7 PRACK | | UAC can send a new offer in a PRACK
|-------------------->| | request to acknowledge F6. |-------------------->| | request to acknowledge F6.
| F8 2xx PRA | | After F7 UAC and UAS can send a new offer | F8 2xx PRA | | After F7 UAC and UAS can send a new
|<--------------------| v in an UPDATE request. |<--------------------| v offer in an UPDATE request.
| | | |
| F9 1xx-rel | <- SDP should not be included in the | F9 1xx-rel | <- SDP should not be included in the
|<--------------------| subsequent 1xx-rel once offer/answer |<--------------------| subsequent 1xx-rel once offer/answer
| F10 PRACK | has been completed. | F10 PRACK | has been completed.
|-------------------->| |-------------------->|
| F11 2xx PRA | | F11 2xx PRA |
|<--------------------| |<--------------------|
| | | |
| F12 2xx INV | <- SDP should not be included in the final | F12 2xx INV | <- SDP should not be included in the
|<--------------------| response once offer/answer has been |<--------------------| final response once offer/answer has
| F13 ACK | completed. | F13 ACK | been completed.
|-------------------->| |-------------------->|
Figure 1 Example of Offer/Answer with 100rel Extension (1) Figure 1 Example of Offer/Answer with 100rel Extension (1)
For example, in Figure 1, only the SDP in F6 is the answer. The SDP For example, in Figure 1, only the SDP in F6 is the answer. The SDP
in the non-reliable response (F2) is the preview of the answer and in the non-reliable response (F2) is the preview of the answer and
must be the same as the answer in F6. Receiving F2, UAC should act as must be the same as the answer in F6. Receiving F2, the UAC should
if it receives the answer. However, offer/answer exchange is not act as if it receives the answer. However, offer/answer exchange is
completed yet and UAC must not send a new offer until it receives the not completed yet and the UAC must not send a new offer until it
same SDP in the first reliable response, which is the real answer. receives the same SDP in the first reliable response, which is the
After sending the SDP in F6, UAS must prepare to receive new offer real answer. After sending the SDP in F6, the UAS must prepare to
from UAC with an UPDATE request or a PRACK request. receive a new offer from the UAC with an UPDATE request or a PRACK
request.
UAS does not include an SDP in the responses F9 and F12. However, UAC The UAS does not include SDP in responses F9 and F12. However, the
should prepare to receive SDP bodies in F9 and/or F12, and just UAC should prepare to receive SDP bodies in F9 and/or F12, and just
ignore them for the case that the peer does not conform to the ignore them, to handle a peer that does not conform to the
recommended implementation. recommended implementation.
3.1.2. INVITE request without SDP 3.1.2. INVITE request without SDP
When UAC does not include an SDP body in the INVITE request, it When a UAC does not include an SDP body in the INVITE request, it
expects the offer to be received with the first reliable response. expects the offer to be received with the first reliable response.
UAC will send the answer in the request to acknowledge the response, The UAC will send the answer in the request to acknowledge the
i.e. PRACK or ACK request for the reliable response. Other than that, response, i.e. PRACK or ACK request of the reliable response. Other
no offer/answer exchanges can occur in the messages within the INVITE than that, no offer/answer exchanges can occur in the messages
transaction. within the INVITE transaction.
NOTE: UAS should not include SDP in the responses F6 and F9. NOTE: The UAS should not include SDP in the responses F6 and
However, UAC should prepare to receive SDP bodies in F6 and/or F9. However, the UAC should prepare to receive SDP bodies in
F9, and just ignore them for the case that the peer does not F6 and/or F9, and just ignore them to handle a peer that does
conform to the recommended implementation. not conform to the recommended implementation.
UAC UAS UAC UAS
| F1 INVITE (no SDP) | | F1 INVITE (no SDP) |
|-------------------->| |-------------------->|
| F2 1xx | | F2 1xx |
|<--------------------| |<--------------------|
| | | |
| F3 1xx-rel (SDP) | <- The first 1xx-rel must contain an SDP | F3 1xx-rel (SDP) | <- The first 1xx-rel must contain SDP
|<--------------------| as the offer. |<--------------------| as the offer.
| F4 PRACK (SDP) | <- A PRACK request to the first 1xx-rel | F4 PRACK (SDP) | <- A PRACK request to the first 1xx-rel
|-------------------->| must contain an SDP as the answer. |-------------------->| must contain SDP as the answer.
| F5 2xx PRA (no SDP) | - | F5 2xx PRA (no SDP) | -
|<--------------------| | |<--------------------| |
| | | | | |
| F6 1xx-rel (no SDP) | <- The subsequent 1xx-rel should not | F6 1xx-rel (no SDP) | <- The subsequent 1xx-rel should not
|<--------------------| | contain an SDP. |<--------------------| | contain SDP.
| F7 PRACK | | | F7 PRACK | |
|-------------------->| | UAC can send a new offer in an UPDATE |-------------------->| | UAC can send a new offer in an UPDATE
| F8 2xx PRA | | request after F4. | F8 2xx PRA | | request after F4.
|<--------------------| v |<--------------------| v
| | | |
| F9 2xx INV (no SDP) | <- The final response should not | F9 2xx INV (no SDP) | <- The final response should not
|<--------------------| contain an SDP. |<--------------------| contain SDP.
| F10 ACK | | F10 ACK |
|-------------------->| |-------------------->|
Figure 2 Example of Offer/Answer with 100rel Extension (2) Figure 2 Example of Offer/Answer with 100rel Extension (2)
Note that in the case that UAC needs to prompt the user to accept or Note that in the case that the UAC needs to prompt the user to
reject the offer, the reliable provisional response with an SDP as an accept or reject the offer, the reliable provisional response with
offer (pattern 4) can result in the retransmission until the PRACK SDP as an offer (pattern 4) can result in the retransmission until
request can be sent. UAC should take care to avoid this situation the PRACK request can be sent. The UAC should take care to avoid
when it sends the INVITE request without an SDP. this situation when it sends the INVITE request without SDP.
3.2. Offer/Answer Exchange in Early Dialog 3.2. Offer/Answer Exchange in Early Dialog
When both UAs support the 100rel extension, they can update the When both UAs support the 100rel extension, they can update the
session in the early dialog once the first offer/answer exchange has session in the early dialog once the first offer/answer exchange
been completed. has been completed.
From UA sending an INVITE request: From a UA sending an INVITE request:
UA can send an UPDATE request with a new offer if both ends support A UA can send an UPDATE request with a new offer if both ends
the UPDATE method. Note that in the case that UAS needs to prompt the support the UPDATE method. Note that if the UAS needs to prompt the
user to accept or reject the offer, an UPDATE request may need to be user to accept or reject the offer, the delay can result in
retransmitted. retransmission of the UPDATE request.
UA can send a PRACK request with a new offer only when acknowledging A UA can send a PRACK request with a new offer only when
the reliable provisional response with the answer to the offer in the acknowledging the reliable provisional response carrying the answer
INVITE request. Compared to using the UPDATE method, using PRACK can to an offer in the INVITE request. Compared to using the UPDATE
save messages to be exchanged between the UAs. However, as a PRACK method, using PRACK can reduce the number of messages exchanged
request should not be rejected, UA is recommended to send a PRACK between the UAs. However, as a PRACK request should not be rejected,
request only when it has strong reasons to assume the receiver will the UA is recommended to send a PRACK request only when it has
accept it. For example, the procedure used in precondition extension strong reasons to expect the receiver will accept it. For example,
[5] is a case where a PRACK request should be used for updating the the procedure used in precondition extension [5] is a case where a
session status in the early dialog. Note also that in the case that PRACK request should be used for updating the session status in an
UAS needs to prompt the user to accept or reject the offer, a PRACK early dialog. Note also that if a UAS needs to prompt the user to
request may need to be retransmitted. accept or reject the offer, the delay can result in retransmission
of the PRACK request.
From UA receiving an INVITE request: From a UA receiving an INVITE request:
UA can send an UPDATE request with a new offer if both ends support A UA can send an UPDATE request with a new offer if both ends
UPDATE method. UAS can not send a new offer in the reliable support the UPDATE method. A UAS can not send a new offer in the
provisional response. So the UPDATE method is the only method for UAS reliable provisional response, so the UPDATE method is the only
to update the early session. method for a UAS to update an early session.
3.3. Offer/Answer Exchange in Established Dialog 3.3. Offer/Answer Exchange in an Established Dialog
The re-INVITE and UPDATE methods can be used in the established Both the re-INVITE and UPDATE methods can be used in an established
dialog to update the session. dialog to update the session.
The UPDATE method is simpler and can save at least one message The UPDATE method is simpler and can save at least one message
compared with INVITE method. But both ends must support the UPDATE compared with the INVITE method. But both ends must support the
method for it to be used. UPDATE method for it to be used.
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
be answered automatically by the UAS. It is noted that re-INVITE to 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.
4. Exceptional Case Handling 4. Exceptional Case Handling
In RFC 3264 [3], the following restrictions are defined with regard In RFC 3264 [3], the following restrictions are defined with regard
to sending a new offer. to sending a new offer.
"It MUST NOT generate a new offer if it has received an offer "It MUST NOT generate a new offer if it has received an offer
which it has not yet answered or rejected. It MUST NOT generate a which it has not yet answered or rejected. It MUST NOT generate
new offer if it has generated a prior offer for which it has not a new offer if it has generated a prior offer for which it has
yet received an answer or a rejection." not yet received an answer or a rejection."
Assuming that the above rules are guaranteed, there seems to be two Assuming that the above rules are guaranteed, there seem to be two
possible 'exceptional' cases to be considered in SIP offer/answer possible 'exceptional' cases to be considered in SIP offer/answer
usage, which are the 'message crossing' case and the 'glare' case. usage: the 'message crossing' case, and the 'glare' case. One of
One of the reasons why the usage of a SIP method to exchange the reasons why the usage of SIP methods to exchange offer/answer
offer/answer needs to be carefully restricted in the RFCs is to make needs to be carefully restricted in the RFCs is to ensure that the
sure that UA can detect and handle appropriately the 'exceptional' UA can detect and handle appropriately the 'exceptional' cases to
cases to avoid the confusion. avoid incompatible behavior.
4.1. Message Crossing Case Handling 4.1. Message Crossing Case Handling
When message packets are crossed in the transport network, an offer When message packets crossed in the transport network, an offer may
may be received before the answer for the previous offer/answer be received before the answer for the previous offer/answer
exchange as described in Figure 3. In such a case, UA A must detect exchange, as described in Figure 3. In such a case, UA A must
the session description of the offer2 is not the answer to the detect the session description of the offer2 is not the answer to
offer1. offer1.
A B A B
|offer1 | |offer1 |
|----------------->| |----------------->|
| answer1| | answer1|
|<------\ /-------| |<------\ /-------|
| \/ | | \/ |
| /\ offer2| | /\ offer2|
|<------/ \-------| |<------/ \-------|
skipping to change at page 11, line 41 skipping to change at page 11, line 45
offer1. offer1.
A B A B
|offer1 | |offer1 |
|----------------->| |----------------->|
| answer1| | answer1|
|<------\ /-------| |<------\ /-------|
| \/ | | \/ |
| /\ offer2| | /\ offer2|
|<------/ \-------| |<------/ \-------|
Figure 3 Message Crossing Case Figure 3 Message Crossing Case
When offer2 is in an UPDATE request or a re-INVITE request, a session When offer2 is in an UPDATE request or a re-INVITE request, a
description can never be the answer. Then UA A must reject the session description cannot be the expected answer. Then UA A must
message including offer2 with a 491 response with Retry-After header reject the message including offer2 with a 491 response with Retry-
field. After header field.
When offer2 is in a PRACK request, that is, when a PRACK request to When offer2 is in a PRACK request(as shown in Figure 4), that is,
acknowledge the reliable provisional response with an answer to the when the PRACK request is acknowledging a reliable provisional
offer in the INVITE request contains a session description, UA A response with an answer to an offer in an INVITE request containing
knows it is an offer. As a PRACK request should not be rejected, UA A a session description, UA A knows it is an offer. As a PRACK
is recommended to wait for the answer1 before sending a PRACK request should not be rejected, UA A is recommended to wait for
response with the answer to the offer2. Note that if UA A does not answer1 before sending a PRACK response with the answer to the
send a new offer until the reliable provisional response with an offer2. Note that if UA A does not send a new offer until the
answer to the offer in the INVITE request is acknowledged with a reliable provisional response with an answer to the offer in the
PRACK request, this case never happens. Therefore, to make INVITE request is acknowledged with a PRACK request, this case
implementations simple, a UA acting as a UAS for an INVITE never happens. Therefore, to simplify implementations, a UA acting
transaction is recommended not to send an UPDATE request with an as a UAS for an INVITE transaction is recommended not to defer
offer until the reliable response with an answer to the offer in the sending an UPDATE request with an offer until after the reliable
INVITE request is acknowledged with a PRACK request. response with an answer to the offer in the INVITE request is
acknowledged with a PRACK request.
When offer2 is in a reliable provisional response or a successful When offer2 is in a reliable provisional response or a successful
final response, UA A knows it is not the answer to the offer1. For a final response (as shown in Figure 5), UA A knows it is not the
reliable response to an initial INVITE request, this case never answer to the offer1. For a reliable response to an initial INVITE
happens. For a reliable response to a re-INVITE request, UA A can request, this case never happens. For a reliable response to a re-
detect the offer2 is not the answer1. In this case, UA A can not INVITE request, UA A can infer that offer2 is not the answer1. In
reject offer2 in a reliable response, it is recommended to wait for this case, since UA A can not reject offer2 in a reliable response,
answer1 before sending a PRACK request with the answer to offer2. it is recommended that it wait for answer1 before sending a PRACK
Note that this case only occurs when UA A, while waiting for an request with the answer to offer2. Note that this case only occurs
answer, sends an INVITE request without session description. when UA A, while waiting for an answer, sends an INVITE request
without session description.
Table 3 summarizes the discussions above. Table 3 summarizes the discussions above.
offer2 | How to know it's not answer1 | Actions to take offer2 | How to know it's not answer1 | Actions to take
-------+------------------------------+-------------------------- -------+------------------------------+--------------------------
INVITE | Never be an answer | 491 response INVITE | Never be an answer | 491 response
UPDATE | Glare case for UA A | with Retry-After UPDATE | Glare case for UA A | with Retry-After
-------+------------------------------+-------------------------- -------+------------------------------+--------------------------
PRACK | Not a pattern 4. in Table 1. | Wait sending response PRACK | Not a pattern 4. in Table 1. | Delay sending response
| 1xx-rel must have an answer, | until answer1 is received | 1xx-rel must have an answer, | until answer1 is received
| not an offer. | | not an offer. |
-------+------------------------------+-------------------------- -------+------------------------------+--------------------------
1xx-rel| Only one INVITE transaction | Wait sending acknowledge 1xx-rel| Only one INVITE transaction | Delay ACK/PRACK
2xx | at a time. Then UA can know | until answer1 is received 2xx | at a time. Then UA can know | until answer1 is received
-------+------------------------------+-------------------------- -------+------------------------------+--------------------------
NOTE: PRACK and 1xx-rel/2xx case is extremely rare case and easily NOTE: PRACK and 1xx-rel/2xx case is extremely rare case and easily
avoidable. See Figure 4 and Figure 5. avoidable. See Figure 4 and Figure 5.
Table 3. UA's action to the offer (offer2) overtaken the previous Table 3. UA's action to an offer (offer2) overtaking the previous
answer (answer1) answer (answer1)
A B A B
| | | |
| INV (offer0)| | INV (offer0)|
|<------------------------------| |<------------------------------|
| 1xx-rel (answer0) | | 1xx-rel (answer0) |
|------------------------------>| --+ |------------------------------>| --+
|offer1(e.g. UPD) | | |offer1(e.g. UPD) | |
|==============================>| | |==============================>| |
| answer1 (2xx-UPD)| | Acknowledge | answer1 (2xx-UPD)| | Acknowledge
|<===========\ /===============| | |<===========\ /===============| |
skipping to change at page 13, line 21 skipping to change at page 13, line 41
|==============================>| | |==============================>| |
| answer1 (2xx-UPD)| | Acknowledge | answer1 (2xx-UPD)| | Acknowledge
|<===========\ /===============| | |<===========\ /===============| |
| \/ | | | \/ | |
| /\ offer2(PRA)| | | /\ offer2(PRA)| |
|<===========/ \===============| <-+ |<===========/ \===============| <-+
| answer2 (2xx-PRA) | | answer2 (2xx-PRA) |
|------------------------------>| Wait until answer1 |------------------------------>| Wait until answer1
| | | |
Figure 4 PRACK as a message with offer2 in message cross case Figure 4 PRACK as a message with offer2 in message crossing case
A B A B
| | | |
|offer1(e.g. UPD) | |offer1(e.g. UPD) |
|==============================>| |==============================>|
|re-INV (no offer) | |re-INV (no offer) |
|------------------------------>| --+ |------------------------------>| --+
| answer1 (2xx-UPD)| | | answer1 (2xx-UPD)| |
|<===========\ /===============| | The first reliable response |<===========\ /===============| | The first reliable response
| \/ offer2| | | \/ offer2| |
| /\ (1xx-rel/2xx)| | | /\ (1xx-rel/2xx)| |
|<===========/ \===============| <-+ |<===========/ \===============| <-+
| answer2 (PRACK/ACK) | | answer2 (PRACK/ACK) |
|------------------------------>| Wait until answer1 |------------------------------>| Wait until answer1
| | | |
Figure 5 Reliable response as a message with offer2 in message cross Figure 5 Reliable response as a message with offer2 in message
case crossing case
4.2. Glare Case Handling 4.2. Glare Case Handling
When both ends in a dialog send a new offer at nearly the same time, When both ends in a dialog send a new offer at nearly the same time,
UA may receive a new offer before it receives the answer to the offer as described in Figure 6, a UA may receive a new offer before it
it sent as described in Figure 6. This case is called a 'glare' case receives the answer to the offer it sent. This case is usually
in general. called a 'glare' case.
A B A B
|offer1 offer2| |offer1 offer2|
|-------\ /-------| |-------\ /-------|
| \/ | | \/ |
| /\ | | /\ |
|<------/ \------>| |<------/ \------>|
Figure 6 Glare Case Figure 6 Glare Case
When offer2 is in an UPDATE request or (re-)INVITE request, it must When offer2 is in an UPDATE request or (re-)INVITE request, it must
be rejected with a 491 response. be rejected with a 491 response.
When offer2 is in a PRACK request (within the current rules, only When offer2 is in a PRACK request (within the current rules, only
possible if offer1 is in an UPDATE request), the PRACK may be possible if offer1 is in an UPDATE request), the PRACK may be
accepted with 200 or may be rejected with a 491 response. A 491 accepted with 200 or may be rejected with a 491 response. A 491
response is valid to satisfy the offer/answer model but it may delay response is valid to satisfy the offer/answer model but it may
the completion of the reliable response transfer mechanism or, in delay the completion of the reliable response transfer mechanism or,
worst case, may result in the failure to complete the SIP transaction in worst case, may result in the failure to complete the SIP
because there is no clear retry rule when a PRACK request is rejected transaction because there is no clear retry rule when a PRACK
with a 491 response. To avoid this glare condition, UA A should not request is rejected with a 491 response. To avoid this glare
send an offer if it has already sent a reliable provisional response condition, UA A should not send an offer if it has already sent a
containing an answer to a previous offer and has not received the reliable provisional response containing an answer to a previous
corresponding PRACK request. offer and has not received the corresponding PRACK request.
To avoid a glare condition involving an offer in a response, when UA To avoid a glare condition involving an offer in a response, when
A has sent a (re)INVITE request without session description, it UA A has sent a (re)INVITE request without session description, it
should not send an offer until it has received an offer in a reliable should not send an offer until it has received an offer in a
response to the (re)INVITE, and sent an answer to that offer. reliable response to the (re)INVITE, and sent an answer to that
offer.
5. Content of Offers and Answers 5. Content of Offers and Answers
While RFCs 3264[3] and 3312[5] give some guidance, questions remain While RFCs 3264[3] and 3312[5] give some guidance, questions remain
about exactly what should be included in an offer or answer. This is about exactly what should be included in an offer or answer. This
especially a problem when the common "hold" feature has been is especially a problem when the common "hold" feature has been
activated, and when there is the potential for a multimedia call. activated, and when there is the potential for a multimedia call.
Details of behavior depend on the capabilities and state of the User Details of behavior depend on the capabilities and state of the
Agent. The kinds of recommendations that can be made are limited by User Agent. The kinds of recommendations that can be made are
the model of device capabilities and state that is presumed to exist. limited by the model of device capabilities and state that is
presumed to exist.
This section focuses on a few key aspects of offers and answers that This section focuses on a few key aspects of offers and answers
have been identified as troublesome, and will consider other aspects that have been identified as troublesome, and will consider other
to be out of scope. This section considers: aspects to be out of scope. This section considers:
- choice of supported media types and formats to include and exclude - choice of supported media types and formats to include and
exclude
- hold and resume of media - hold and resume of media
The following are out of scope for this document: The following are out of scope for this document:
- NAT traversal and ICE - NAT traversal and ICE
- specific codecs and their parameters - specific codecs and their parameters
- the negotiation of secure media streams - the negotiation of secure media streams
- grouping of media streams - grouping of media streams
skipping to change at page 15, line 22 skipping to change at page 16, line 6
- grouping of media streams - grouping of media streams
- preconditions - preconditions
5.1. General Principle for Constructing Offers and Answers 5.1. General Principle for Constructing Offers and Answers
A UA should send an offer that indicates what it, and its user, are A UA should send an offer that indicates what it, and its user, are
interested in using/doing at that time, without regard for what the interested in using/doing at that time, without regard for what the
other party in the call may have indicated previously. This is the other party in the call may have indicated previously. This is the
case even when the offer is sent in response to an INVITE or re- case even when the offer is sent in response to an INVITE or re-
INVITE that contains no offer. (However in the case of re-INVITE the INVITE that contains no offer. (However in the case of re-INVITE
constraints of RFCs 3261 and 3264 must be observed.) the constraints of RFCs 3261 and 3264 must be observed.)
A UA should send an answer that includes as close an approximation to A UA should send an answer that includes as close an approximation
what the UA and its user are interested in doing at that time, while to what the UA and its user are interested in doing at that time,
remaining consistent with the offer/answer rules of RFC 3264[3] and while remaining consistent with the offer/answer rules of RFC
other RFCs. 3264[3] and other RFCs.
NOTE: "at that time" is important. The device may permit the NOTE: "at that time" is important. The device may permit the
user to configure which supported media are to be used by user to configure which supported media are to be used by
default. default.
In some cases a UA may not have direct knowledge of what it is In some cases a UA may not have direct knowledge of what it is
interested in doing at a particular time. If it is an intermediary it interested in doing at a particular time. If it is an intermediary
may be able to delegate the decision. In the worst case it may apply it may be able to delegate the decision. In the worst case it may
a default, such as assuming it wants to use all of its capabilities. apply a default, such as assuming it wants to use all of its
capabilities.
5.2. Choice of Media Types and Formats to Include and Exclude 5.2. Choice of Media Types and Formats to Include and Exclude
5.2.1. Sending Initial INVITE with Offer 5.2.1. Sending an Initial INVITE with Offer
When a UAC sends an initial INVITE with an offer, it has complete When a UAC sends an initial INVITE with an offer, it has complete
freedom to choose which media type(s) and media format(s) (payload freedom to choose which media type(s) and media format(s) (payload
types in the case of RTP) it should include in the offer. types in the case of RTP) it should include in the offer.
The media types may be all or a subset of the media the UAC is The media types may be all or a subset of the media the UAC is
capable of supporting, with the particular subset being determined by capable of supporting, with the particular subset being determined
the design and configuration [6] of the UAC combined with input from by the design and configuration [6] of the UAC combined with input
the user interface of the UAC. from the user interface of the UAC.
The media formats may be all or a subset of the media formats the UAC The media formats may be all or a subset of the media formats the
is capable of supporting for the corresponding media type, with the UAC is capable of supporting for the corresponding media type, with
particular subset being determined by the design and configuration the particular subset being determined by the design and
[6] of the UAC combined with input from the user interface of the configuration [6] of the UAC combined with input from the user
UAC. interface of the UAC.
Including all supported media formats will maximize the possibility Including all supported media formats will maximize the possibility
that the other party will have a supported format in common. But that the other party will have a supported format in common. But
including many can result in an unacceptably large SDP body. including many can result in an unacceptably large SDP body.
5.2.2. Responding with Offer when Initial INVITE has no Offer 5.2.2. Responding with an Offer when the Initial INVITE has no Offer
When a UAS has received an initial INVITE without an offer, it must When a UAS has received an initial INVITE without an offer, it must
include an offer in the first reliable response to the INVITE. It has include an offer in the first reliable response to the INVITE. It
largely the same options as when sending an initial INVITE with an has largely the same options as when sending an initial INVITE with
offer, but there are some differences. The choice may be governed by an offer, but there are some differences. The choice may be
both static (default) selections of media types as well as dynamic governed by both static (default) selections of media types as well
selections made by a user via interaction with the device while it is as dynamic selections made by a user via interaction with the
alerting. device while it is alerting.
NOTE: The offer may be sent in a provisional response, before NOTE: The offer may be sent in a provisional response, before
the user of the device has been alerted and had an opportunity the user of the device has been alerted and had an opportunity
to select media options for the call. In this case the UAS to select media options for the call. In this case the UAS
cannot include any call-specific options from the user of the cannot include any call-specific options from the user of the
device. If there is a possibility that the user of the device device. If there is a possibility that the user of the device
will wish to change what is offered before answering the call, will wish to change what is offered before answering the call,
then special care should be taken. If PRACK and UPDATE are then special care should be taken. If PRACK and UPDATE are
supported by caller and callee then an initial offer can be sent supported by caller and callee then an initial offer can be
reliably, and changed with an UPDATE if the user desires a sent reliably, and changed with an UPDATE if the user desires
change. If PRACK and UPDATE are not supported then the initial a change. If PRACK and UPDATE are not supported then the
offer cannot be changed until the call is fully established. In initial offer cannot be changed until the call is fully
that case either the offer should be delayed until the 200 is established. In that case either the offer should be delayed
sent, or else the offer should include the minimum set of media until the 200 is sent, or else the offer should include the
the user is able to select. minimum set of media the user is able to select.
5.2.3. Answering Initial INVITE with Offer 5.2.3. Answering an Initial INVITE with Offer
When a UAS receives an initial INVITE with an offer, what media lines When a UAS receives an initial INVITE with an offer, what media
the answer may contain is constrained by RFC 3264.[3] The answer must lines the answer may contain is constrained by RFC 3264.[3] The
contain the same number of m-lines as the offer, and they must answer must contain the same number of m-lines as the offer, and
contain the same media types. Each media line may be accepted, by they must contain the same media types. Each media line may be
including a non-zero port number, or rejected by including a zero accepted, by including a non-zero port number, or rejected by
port number in the answer. The media lines that are accepted should including a zero port number in the answer. The media lines that
typically be those that would have been offered had the INVITE not are accepted should typically be those that would have been offered
contained an offer, but with those not offered removed. had the INVITE not contained an offer, excluding those not offered.
The media formats the answer may contain are constrained by RFC 3264 The media formats the answer may contain are constrained by RFC
[3]. For each accepted m-line in the answer, there must be at least 3264 [3]. For each accepted m-line in the answer, there must be at
one media format in common with the corresponding m-line of the least one media format in common with the corresponding m-line of
offer. The UAS may also include other media formats it is able to the offer. The UAS may also include other media formats it is able
support at this time. However there is little benefit to including to support at this time. However there is little benefit to
added types. including added types.
If the UAS does not wish to indicate support for any of the media If the UAS does not wish to indicate support for any of the media
types in a particular media line of the offer it must reject the types in a particular media line of the offer it must reject the
corresponding media line, by setting the port number to zero. corresponding media line, by setting the port number to zero.
5.2.4. Answering when Initial INVITE had no Offer 5.2.4. Answering when the Initial INVITE had no Offer
When a UAC has sent an initial INVITE without an offer, and then When a UAC has sent an initial INVITE without an offer, and then
receives a response with the first offer, it should answer in the receives a response with the first offer, it should answer in the
same way as a UAS receiving an initial INVITE with an offer. same way as a UAS receiving an initial INVITE with an offer.
5.2.5. Subsequent Offers and Answers 5.2.5. Subsequent Offers and Answers
The guidelines above (sections 5.1. and 5.2.1. through 5.2.4.) apply, The guidelines above (sections 5.1. and 5.2.1. through 5.2.4. )
but constraints in RFC 3264 [3] must also be followed. The following apply, but constraints in RFC 3264 [3] must also be followed. The
are of particular note because they have proven troublesome: following are of particular note because they have proven
troublesome:
o The number of m-lines may not be reduced in a subsequent offer. o The number of m-lines may not be reduced in a subsequent offer.
Previously rejected media streams must remain, or be reused to Previously rejected media streams must remain, or be reused to
offer the same or a different stream. offer the same or a different stream. (RFC 3264[3] section 6.)
o In the o-line, only the version number may change, and if it o In the o-line, only the version number may change, and if it
changes it must increment by one from the one previously sent as changes it must increment by one from the one previously sent as
an offer or answer. If it doesn't change then the entire SDP body an offer or answer. (RFC 3264[3] section 8.) If it doesn't
must be identical to what was previously sent as an offer or change then the entire SDP body must be identical to what was
answer. Changing the o-line, except version number value, during previously sent as an offer or answer. Changing the o-line,
the session is an error case. The behavior when receiving such a except version number value, during the session is an error case.
non-compliant offer/answer SDP is implementation dependent. If a The behavior when receiving such a non-compliant offer/answer
UA needs to negotiate a 'new' SDP session, it should use the SDP body is implementation dependent. If a UA needs to negotiate
INVITE/Replaces method. a 'new' SDP session, it should use the INVITE/Replaces method.
o In the case of RTP, the mapping from a particular dynamic payload o In the case of RTP, the mapping from a particular dynamic
type number to a particular codec within that media stream (m- payload type number to a particular codec within that media
line) must not change for the duration of the session. stream (m-line) must not change for the duration of the session.
(RFC 3264[3] section 8.3.2.)
NOTE: This may be impossible for a B2BUA to follow in some cases NOTE: This may be impossible for a B2BUA to follow in some
(e.g. 3pcc transfer) if it does not terminate media. cases (e.g. 3pcc transfer) if it does not terminate media.
When the new offer is sent in response to an offerless (re)INVITE, When the new offer is sent in response to an offerless (re)INVITE,
all codecs the UA wishes to use at this time are to be included, not all codecs supported by the UA are to be included, not just the
just the ones that were negotiated by previous offer/answer ones that were negotiated by previous offer/answer exchanges. The
exchanges. Same with media types - so if UA A initially offered audio same is true for media types - so if UA A initially offered audio
and video to UA B, and they end up with only audio, and UA B sends an and video to UA B, and they end up with only audio, and UA B sends
offerless (re)INVITE to UA A, A's resulting offer should re-attempt an offerless (re)INVITE to UA A, A's resulting offer should re-
video, by reusing the zeroed m-line used previously if it still attempt video, by reusing the zeroed m-line used previously.
wishes to use video.
NOTE: The behavior above is recommended, but it is not always to NOTE: The behavior above is recommended, but it is not always
achieve - for example in some interworking scenarios. Or, the achievable - for example in some interworking scenarios. Or,
offerer may simply not have enough resources to offer the offerer may simply not have enough resources to offer
"everything" at that point. Even if the UAS is not able to offer "everything" at that point. Even if the UAS is not able to
any other SDP that the one currently using, it should not reject offer any other SDP that the one currently being used, it
the re-INVITE. Instead, it should generate an offer with the should not reject the re-INVITE. Instead, it should generate
currently used SDP with o- line unchanged. an offer with the currently used SDP with o- line unchanged.
5.3. Hold and Resume of media 5.3. Hold and Resume of media
RFC 3264 [3] specifies (non-normatively) that "hold" should be RFC 3264 [3] specifies (non-normatively) that "hold" should be
indicated in an established session by sending a new offer containing indicated in an established session by sending a new offer
"a=sendonly" for each media stream to be held. An answerer is then to containing "a=sendonly" for each media stream to be held. An
respond with "a=recvonly" to acknowledge that the hold request has answerer is then to respond with "a=recvonly" to acknowledge that
been understood. the 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.
may be used for other reasons, such as devices that are only capable These may be used for other reasons, such as devices that are only
of sending or receiving. So receiving an offer with "a=sendonly" must capable of sending or receiving. So receiving an offer with
not be treated as a certain indication that the offerer has placed "a=sendonly" must not be treated as a certain indication that the
the media stream on hold. offerer has 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
will want to play Music on Hold, which is not always the case. A UA hold will want to play Music on Hold, which is not always the case.
may, if desired, initiate hold by offering "a=inactive" if it does A UA may, if desired, initiate hold by offering "a=inactive" if it
not intend to transmit any media while in hold status. does not intend to transmit any media while in hold status.
The rules of RFC 3264 [3] constrain what may be in an answer when the The rules of RFC 3264 [3] constrain what may be in an answer when
offer contains "sendonly", "recvonly", or "inactive" in an a= line. the offer contains "sendonly", "recvonly", or "inactive" in an a=
But they do not constrain what must be in a subsequent offer. The line. But they do not constrain what must be in a subsequent offer.
General Principle for Constructing Offers and Answers (section 5.1. ) The General Principle for Constructing Offers and Answers (section
is important here. The initiation of "hold" is a local action. It 5.1. ) is important here. The initiation of "hold" is a local
should affect the desired state of the UA. It then affects what the action. It should reflect the desired state of the UA. It then
UA includes in offers and answers until the local state is reset. affects what the UA includes in offers and answers until the local
state is reset.
The receipt of an offer containing "a=sendonly" or "a=inactive" and The receipt of an offer containing "a=sendonly" or "a=inactive" and
the sending of a compatible answer should not change the desired the sending of a compatible answer should not change the desired
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
may itself desire to initiate its own hold status, based on local hold" may itself desire to initiate its own hold status, based on
input. local 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
answer with "a=inactive" because that is the only valid answer that will answer with "a=inactive" because that is the only valid answer
reflects its desire not to receive media. that reflects its desire not to receive media.
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
its desired state of "a=sendonly" because that is a permitted with its desired state of "a=sendonly" because that is a permitted
response. When UA2 desires to also resume, it will send an offer with response. When UA2 desires to also resume, it will send an offer
"a=sendrecv". In this case, because UA1 has the same desire it will with "a=sendrecv". In this case, because UA1 has the same desire it
respond with "a=sendrecv".In the same case, when UA2 receives the will respond with "a=sendrecv". In the same case, when UA2 receives
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
local hold but has not yet signaled the intent, it may send its local hold but has not yet signaled the intent, it may send
"a=sendrecv" in the answer. "a=sendrecv" in the answer.
If UA2 has been "placed on hold" by UA1 via receipt of "a=inactive", If UA2 has been "placed on hold" by UA1 via receipt of "a=inactive",
and subsequently wants to initiate its own hold, also using and subsequently wants to initiate its own hold, also using
"a=inactive", it need not send a new offer, since the only valid "a=inactive", it need not send a new offer, since the only valid
response is "a=inactive" and that is already in effect. However, its response is "a=inactive" and that is already in effect. However,
local desired state will now be either "inactive" or "a=sendonly". its local desired state will now be either "inactive" or
This affects what it will send in future offers and answers. "a=sendonly". This affects what it will send in future offers and
answers.
If a UA has occasion to send another offer in the session, without If a UA has occasion to send another offer in the session, without
any desire to change the hold status (e.g. in response to a re-INVITE any desire to change the hold status (e.g. in response to a re-
without an offer, or when sending a re-INVITE to refresh the session INVITE without an offer, or when sending a re-INVITE to refresh the
timer) it should follow the General Principle for Constructing Offers session timer) it should follow the General Principle for
and Answers (section 5.1. ). If it previously initiated a "hold" by Constructing Offers and Answers (section 5.1. ). If it previously
sending "a=sendonly" or "a=inactive" then it should offer that again. initiated a "hold" by sending "a=sendonly" or "a=inactive" then it
If it had not previously initiated "hold" then it should offer should offer that again. If it had not previously initiated "hold"
"a=sendrecv", even if it had previously been forced to answer then it should offer "a=sendrecv", even if it had previously been
something else. Without this behavior it is possible to get "stuck on forced to answer something else. Without this behavior it is
hold" in some cases, especially when a third-party call controller is possible to get "stuck on hold" in some cases, especially when a
involved. third-party call controller is involved.
5.4. Behavior on receiving SDP with c=IN IP4 0.0.0.0 5.4. Behavior on receiving SDP with c=0.0.0.0
RFC 3264[3] specifies that An agent MUST be capable of receiving SDP RFC 3264[3] specifies that An agent MUST be capable of receiving
with a connection address of 0.0.0.0, in which case it means that SDP with a connection address of 0.0.0.0, in which case it means
neither RTP nor RTCP should be sent to the peer. that neither RTP nor RTCP should be sent to the peer.
If a UA generates an answer to the offer received with a connection If a UA generates an answer to the offer received with c=0.0.0.0,
address of 0.0.0.0, the direction attribute of the accepted media the direction attribute of the accepted media stream in the answer
stream in the answer must be based on direction attribute of the must be based on direction attribute of the offered stream and
offered stream and rules specified in RFC 3264 to form the a-line in rules specified in RFC 3264 to form the a-line in the answer.
the answer. A connection address of 0.0.0.0 has no special meaning c=0.0.0.0 has no special meaning for the direction attribute of the
for the direction attribute of the accepted stream in the answer. accepted stream in the answer.
6. Remaining Issues or Best Practices on Offer/Answer 6. Remaining Issues or Best Practices on Offer/Answer
This document clarifies the offer/answer usage in SIP and summarizes This document clarifies the offer/answer usage in SIP and
the correct or recommended behaviors along with the existing RFCs. To summarizes the correct or recommended behaviors along with the
create any new normative behaviors beyond these RFCs is not the existing RFCs. To create any new normative behaviors beyond these
intent of this document. RFCs is not the intent of this document.
However, through the scrutiny of the offer/answer model in SIP, some However, through the scrutiny of the offer/answer model in SIP,
issues are found to be unresolved within the current set of RFCs. some issues are found to be unresolved within the current set of
Those remaining issues are described in this section mainly for RFCs. Those remaining issues are described in this section mainly
further study. for further study.
6.1. Rejecting PRACK Offer 6.1. Rejecting PRACK Offer
As stated in section 2.2. and 3.2. , it is recommended not to send an As stated in section 2.2. and 3.2. , it is recommended that an
offer in a PRACK request unless UAC has strong reasons to assume the offer not be sent in a PRACK request unless UAC has strong reasons
receiver will accept it. Even so, there may be the cases when the UAS to assume the receiver will accept it. Even so, there may be cases
has to reject the offer for some reason. The current RFCs do not when the UAS has to reject the offer for some reason. The current
provide the way to reject the offer and at the same time to RFCs do not provide a way to reject the offer and at the same time
acknowledge the reliable response. to acknowledge the reliable response.
Several ideas were presented to resolve this issue, such as sending Several ideas were presented to resolve this issue, such as sending
2xx PRACK response without SDP to reject the offer, or sending an SDP 2xx PRACK response without SDP to reject the offer, or sending SDP
with decreased o-line version value. Some of the candidates may also with a decreased version value in the o-line. Some of the
be adapted as a way to reject an unacceptable offer in a response. candidates may also be adapted as a way to reject an unacceptable
Anyway, those candidates violate the current rules and lose backward offer in a response. Anyway, those proposals violate the current
compatibility to some extent (e.g. section 5 of RFC 3262). It is rules and lose backward compatibility to some extent (e.g. section
beyond the scope of this document and remains for further study. 5 of RFC 3262). It is beyond the scope of this document and remains
for further study.
NOTE: Deprecation of the usage of offer in PRACK may be another NOTE: Deprecation of the usage of offer in PRACK may be
solution. As the precondition mechanism specification [2] another solution. As the precondition mechanism specification
explicitly shows a usage of sending offer in PRACK, its [2] explicitly shows a usage of sending offer in PRACK, its
deprecation could cause backward compatibility issues. deprecation could cause backward compatibility issues.
6.2. Commit/Rollback of Offer/Answer on Unsuccessful re-INVITE 6.2. Commit/Rollback of Offer/Answer on Unsuccessful re-INVITE
Transaction Transaction
When a re-INVITE transaction fails, often the dialog remains with the When a re-INVITE transaction fails, the dialog remains with the
session bound to it. The issue here is what the session status is if session bound to it. The issue here is: what is the session status
offer/answer exchange has been completed (if a session description if an offer/answer exchange has been completed (if a session
has been sent in a reliable provisional response to the re-INVITE description has been sent in a reliable provisional response to the
request), or if subsequent offer/answer exchanges have taken place re-INVITE request), or if subsequent offer/answer exchanges have
(using UPDATE or PRACK transactions), before the re-INVITE taken place (using UPDATE or PRACK transactions), before the re-
transaction is terminated with a final error response (Figure 7). One INVITE transaction is terminated with a final error response
option is to take those offer/answer exchanges not committed yet and (Figure 7). One option is to take those offer/answer exchanges not
to make the session status rollback to the one before re-INVITE committed yet and to make the session status rollback to the one
transaction was initiated. Another option is to take those exchanges before re-INVITE transaction was initiated. Another option is to
committed and to keep the session status as it is even after re- take those exchanges committed and to keep the session status as it
INVITE fails. There is no clear consensus on which one is the correct is even after re-INVITE fails. There is no clear consensus on which
behavior. one is the correct behavior.
There are some cases where it is useful to exchange There are some cases where it is useful to exchange
offer(s)/answer(s) even before re-INVITE completes. The case of offer(s)/answer(s) even before re-INVITE completes. The case of
adding a new media (like adding video to audio only session) which adding a new media (like adding video to audio only session) which
requires permission from the peer through some user interaction is requires permission from the peer through some user interaction is
one example. Precondition procedures can be another case which may one example. Precondition procedures can be another case which may
require several offer/answer exchanges in one re-INVITE transaction. require several offer/answer exchanges in one re-INVITE transaction.
UAC UAS UAC UAS
| session established | | session established |
|<===================>| |<===================>|
| | | |
| F1 re-INVITE (SDP) | | F1 re-INVITE (SDP) |
|-------------------->| |-------------------->|
| F2 1xx-rel (SDP) | | F2 1xx-rel (SDP) |
|<--------------------| |<--------------------|
| F3 PRACK | <- PRACK request may include new offer and | F3 PRACK | <- PRACK request may include new offer
|-------------------->| can complete the offer/answer with |-------------------->| and can complete the offer/answer with
| F4 2xx PRA | the answer in 2xx PRACK response. | F4 2xx PRA | the answer in 2xx PRACK response.
|<--------------------| |<--------------------|
| | <- UPDATE method can update the session | | <- UPDATE method can update the session
| | status before receiving the final | | status before receiving the final
| F5 4xx/5xx/6xx INV | response to re-INVITE request (F1). | F5 4xx/5xx/6xx INV | response to re-INVITE request (F1).
|<--------------------| |<--------------------|
| F6 ACK | | F6 ACK |
|-------------------->| Issue: What is the correct session status |-------------------->| Issue: What is the correct session
| | after re-INVITE transaction. | | status after re-INVITE transaction.
Figure 7 Commit/Rollback Issue with re-INVITE transaction Figure 7 Commit/Rollback Issue with re-INVITE transaction
To make bad things worse, if a new offer from UAC and the final 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 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 not know whether this new offer was sent before or after UAC
the final failure response (Figure 8). Note that the ACK request to received the final failure response (Figure 8). Note that the ACK
the failure response is sent hop-by-hop basis, therefore even after request to the failure response is sent hop-by-hop basis, therefore
receiving the ACK request, UAS can not make sure that UPDATE request even after receiving the ACK request, UAS can not make sure that
was sent after the final response had been reached to the other end. 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 Sending a new UPDATE request from UAC to synchronize the status
anytime after the re-INVITE fails may be a good option. This anytime after the re-INVITE fails may be a good option. This
solution, however, requires that the UPDATE method be supported by solution, however, requires that the UPDATE method be supported by
both ends and needs care to avoid flapping when each end tries to both ends and needs care to avoid flapping when each end tries to
advertise their different views of the session status. advertise their different views of the session status.
The proper handling of this issue is undefined by existing standards. The proper handling of this issue is undefined by existing
Resolution is beyond the scope of this document, and will require a standards. Resolution is beyond the scope of this document, and
new normative document. Such a document is the responsibility of the will require a new normative document.
SIP working group, and is for further study.
UAC UAS UAC UAS
| session established | | session established |
|<===================>| |<===================>|
| | | |
| F1 re-INVITE (SDP) | | F1 re-INVITE (SDP) |
|-------------------->| |-------------------->|
| F2 1xx-rel (SDP) | | F2 1xx-rel (SDP) |
|<--------------------| |<--------------------|
| F3 PRACK | | F3 PRACK |
skipping to change at page 22, line 36 skipping to change at page 23, line 31
| /\ | | /\ |
|<--------/ \------->| |<--------/ \------->|
| | | |
Figure 8 Commit/Rollback Issue with Race Condition Figure 8 Commit/Rollback Issue with Race Condition
6.3. Offer in a Reliable Response 6.3. Offer in a Reliable Response
In RFC 3261, it is stated that when an INVITE is sent without an 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 offer, the first reliable response MUST contain an offer. There was
discussion on whether this rule can be loosened up. There is no clear discussion on whether this rule can be loosened up. There is no
explanation why this restriction is defined. However, this rule will clear explanation why this restriction is defined. However, this
be left as it is, unless the strong necessity to loose it up will rule will be left as it is, unless the strong necessity to loosen
come up in the future. 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 best practice
recommentation 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 7. Add New Offer/Answer Usage in SIP
This document recommends against the addition of new offer/answer This document recommends against the addition of new offer/answer
methods using SIP. However, it may be necessary to define new methods using SIP. However, it may be necessary to define new
offer/answer exchange methods as SIP extensions evolve. In this offer/answer exchange methods as SIP extensions evolve. This
section, what should be taken into considerations is noted. section recommends some things that should be taken into
considerations in that case.
7.1. Explicit Usage 7.1. Explicit Usage
New method definitions should define offer/answer usage explicitly New method definitions should define offer/answer usage explicitly
without any ambiguity. without any ambiguity.
7.2. Rejection of an Offer 7.2. Rejection of an Offer
New method definitions should define how to reject an offer where New method definitions should define how to reject an offer where
possible. possible.
skipping to change at page 23, line 30 skipping to change at page 24, line 47
This document has no actions for IANA. This document has no actions for IANA.
9. Security Considerations 9. Security Considerations
There are not any security issues beyond the referenced RFCs. There are not any security issues beyond the referenced RFCs.
10. Acknowledgement 10. 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 and Jonathan Rosenberg for their
reviews and comments. Many of their suggestions and ideas are thorough reviews and comments. Many of their suggestions and ideas
incorporated to complete this document. are incorporated to complete this document.
11. References 11. References
11.1. Normative References 11.1. Normative References
[1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002. Session Initiation Protocol", RFC 3261, June 2002.
[2] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional [2] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional
Responses in the Session Initiation Protocol (SIP)", RFC 3262, Responses in the Session Initiation Protocol (SIP)", RFC 3262,
June 2002. June 2002.
[3] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with [3] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
SDP", RFC 3264, June 2002. SDP", RFC 3264, June 2002.
[4] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE [4] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE
Method", RFC 3311, September 2002. Method", RFC 3311, September 2002.
[5] Camarillo, G., Marshall, W., and J. Rosenberg, "Integration of [5] Camarillo, G., Marshall, W., and J. Rosenberg, "Integration
Resource Management and Session Initiation Protocol (SIP)", RFC of Resource Management and Session Initiation Protocol (SIP)",
3312, October 2002. RFC 3312, October 2002.
11.2. Informative References 11.2. Informative References
[6] G. Camarillo, "The Early Session Disposition Type for the [6] G. Camarillo, "The Early Session Disposition Type for the
Session Initiation Protocol (SIP)", RFC 3959, December 2004. Session Initiation Protocol (SIP)", RFC 3959, December 2004.
[7] Hilt, V., Camarillo, G., and J. Rosenberg, "A User Agent [7] Hilt, V., Camarillo, G., and J. Rosenberg, "A User Agent
Profile Data Set for Media Policy", draft-ietf-sipping-media- Profile Data Set for Media Policy", draft-ietf-sipping-media-
policy-dataset-04 (work in progress), May 2007. policy-dataset-05 (work in progress), November 2007.
Author's Addresses Author's Addresses
Takuya Sawada Takuya Sawada
KDDI Corporation KDDI Corporation
3-10-10, Iidabashi, Chiyoda-ku, Tokyo, Japan 3-10-10, Iidabashi, Chiyoda-ku, Tokyo, Japan
Email: tu-sawada@kddi.com 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
Full Copyright Statement Full Copyright Statement
skipping to change at page 24, line 36 skipping to change at page 26, line 14
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
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
FOR A PARTICULAR PURPOSE.
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed
pertain to the implementation or use of the technology described in to pertain to the implementation or use of the technology described
this document or the extent to which any license under such rights in this document or the extent to which any license under such
might or might not be available; nor does it represent that it has rights might or might not be available; nor does it represent that
made any independent effort to identify any such rights. Information it has made any independent effort to identify any such rights.
on the procedures with respect to rights in RFC documents can be Information on the procedures with respect to rights in RFC
found in BCP 78 and BCP 79. documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of attempt made to obtain a general license or permission for the use
such proprietary rights by implementers or users of this of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository
at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Acknowledgment Acknowledgment
 End of changes. 137 change blocks. 
510 lines changed or deleted 553 lines changed or added

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