draft-ietf-sipping-sip-offeranswer-08.txt   draft-ietf-sipping-sip-offeranswer-09.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: October 2008 Cisco Systems, Inc. Expires: April 2009 Cisco Systems, Inc.
April 25, 2008 November 3, 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-08.txt draft-ietf-sipping-sip-offeranswer-09.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
skipping to change at page 1, line 37 skipping to change at page 1, line 37
documents at any time. It is inappropriate to use Internet-Drafts documents at any time. It is inappropriate to use Internet-Drafts
as reference material or to cite them other than as "work in as reference material or to cite them other than as "work in
progress." 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 25, 2007. This Internet-Draft will expire on November 3, 2007.
Abstract Abstract
The Session Initiation Protocol (SIP) utilizes the offer/answer The Session Initiation Protocol (SIP) utilizes the offer/answer
model to establish and update multimedia sessions using the Session model to establish and update multimedia sessions using the Session
Description Protocol (SDP). The description of the offer/answer Description Protocol (SDP). The description of the offer/answer
model in SIP is dispersed across multiple RFCs. This document model in SIP is dispersed across multiple RFCs. This document
summarizes all the current usages of the offer/answer model in SIP summarizes all the current usages of the offer/answer model in SIP
communication. communication.
Table of Contents Table of Contents
1. Introduction.................................................. 3 1. Introduction................................................3
1.1. Terminology.............................................. 3 1.1. Terminology............................................3
2. Summary of SIP usage of the Offer/Answer Model................ 3 2. Summary of SIP usage of the Offer/Answer Model...............3
2.1. Offer/Answer Exchange Pairs in SIP Messages.............. 4 2.1. Offer/Answer Exchange Pairs in SIP Messages.............4
2.2. Rejection of an Offer.................................... 5 2.2. Rejection of an Offer...................................5
2.3. Session Description which is not Offer nor Answer........ 6 2.3. Session Description which is not Offer nor Answer.......6
3. Detailed Discussion of the Offer/Answer Model for SIP......... 7 3. Detailed Discussion of the Offer/Answer Model for SIP........7
3.1. Offer/Answer for the INVITE method with 100rel extension. 7 3.1. Offer/Answer for the INVITE method with 100rel extension. 7
3.1.1. INVITE Request with SDP............................. 7 3.1.1. INVITE Request with SDP............................8
3.1.2. INVITE request without SDP.......................... 9 3.1.2. INVITE request without SDP.........................9
3.2. Offer/Answer Exchange in Early Dialog................... 10 3.2. Offer/Answer Exchange in Early Dialog..................10
3.3. Offer/Answer Exchange in an Established Dialog.......... 10 3.3. Offer/Answer Exchange in an Established Dialog.........11
4. Exceptional Case Handling.................................... 11 4. Exceptional Case Handling...................................11
4.1. Message Crossing Case Handling.......................... 11 4.1. Message Crossing Case Handling.........................12
4.2. Glare Case Handling..................................... 13 4.2. Glare Case Handling...................................14
5. Content of Offers and Answers................................ 14 5. Content of Offers and Answers...............................15
5.1. General Principle for Constructing Offers and Answers... 14 5.1. General Principle for Constructing Offers and Answers...16
5.2. Choice of Media Types and Formats to Include and Exclude 15 5.2. Choice of Media Types and Formats to Include and Exclude16
5.2.1. Sending an Initial INVITE with Offer............... 15 5.2.1. Sending an Initial INVITE with Offer..............16
5.2.2. Responding with an Offer when the Initial INVITE has 5.2.2. Responding with an Offer when the Initial INVITE has
no Offer.................................................. 15 no Offer................................................17
5.2.3. Answering an Initial INVITE with Offer............. 16 5.2.3. Answering an Initial INVITE with Offer............17
5.2.4. Answering when the Initial INVITE had no Offer..... 17 5.2.4. Answering when the Initial INVITE had no Offer.....18
5.2.5. Subsequent Offers and Answers...................... 17 5.2.5. Subsequent Offers and Answers.....................18
5.3. Hold and Resume of media................................ 18 5.3. Hold and Resume of media...............................19
5.4. Behavior on receiving SDP with c=0.0.0.0................ 19 5.4. Behavior on receiving SDP with c=0.0.0.0...............20
6. Remaining Issues or Best Practices on Offer/Answer........... 19 6. Remaining Issues or Best Practices on Offer/Answer..........21
6.1. Rejecting PRACK Offer................................... 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.................................................. 21 Transaction................................................22
6.3. Offer in a Reliable Response............................ 22 6.3. Offer in a Reliable Response...........................24
6.4. Requesting Hold while already on Hold................... 23 6.4. Requesting Hold while already on Hold..................24
7. Add New Offer/Answer Usage in SIP............................ 23 7. Add New Offer/Answer Usage in SIP...........................25
7.1. Explicit Usage.......................................... 23 7.1. Explicit Usage........................................25
7.2. Rejection of an Offer................................... 23 7.2. Rejection of an Offer..................................25
7.3. Backward Compatibility.................................. 23 7.3. Backward Compatibility.................................25
7.4. Exceptional Case Handling............................... 23 7.4. Exceptional Case Handling..............................25
8. IANA Considerations.......................................... 24 8. IANA Considerations........................................25
9. Security Considerations...................................... 24 9. Security Considerations....................................25
10. Acknowledgement............................................. 24 10. Acknowledgement...........................................25
11. References.................................................. 24 11. References................................................26
11.1. Normative References................................... 24 11.1. Normative References..................................26
11.2. Informative References................................. 24 11.2. Informative References................................26
Author's Addresses.............................................. 25 Author's Addresses............................................26
Full Copyright Statement........................................ 25 Full Copyright Statement......................................27
Intellectual Property Statement................................. 25 Intellectual Property Statement................................27
Acknowledgment.................................................. 26 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
session. The rules to govern the offer/answer behaviors in SIP are sessions. The rules to govern the offer/answer behaviors in SIP are
described in the several RFCs. described in the several RFCs. (RFC 3261 [2], RFC 3262 [3], RFC
3264 [4], and RFC 3311 [5].)
The primary purpose of this document is to describe all forms 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 make normative changes. Rather, it This document is not intended to make normative changes. Rather, it
makes the remaining open issues clear and leaves them for further makes the remaining open issues clear and leaves them for further
study. study.
skipping to change at page 4, line 10 skipping to change at page 4, line 11
The offer/answer model defines a mechanism for update of sessions. The offer/answer model defines a mechanism for update of sessions.
In SIP, a dialog is used to associate an offer/answer exchange with In SIP, a dialog is used to associate an offer/answer exchange with
the session which it is to update. In other words, only the the session which it is to update. In other words, only the
offer/answer exchange in the SIP dialog can update the session offer/answer exchange in the SIP dialog can update the session
which is managed by that dialog. 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 [2], RFC 3262 [3] and RFC 3311 [5]. In these RFCs, only the 3261 [1], RFC 3262 [3], RFC 3264 [4], and RFC 3311 [5]. In these
six patterns shown in Table 1 are defined for exchanging an offer RFCs, only the six patterns shown in Table 1 are defined for
and an answer with SIP messages. exchanging an offer and an answer with SIP messages.
Note that an offer/answer exchange initiated by an INVITE request Note that an offer/answer exchange initiated by an INVITE request
must follow exactly one of the patterns 1, 2, 3, 4. When an initial must follow exactly one of the patterns 1, 2, 3, 4. When an initial
INVITE causes multiple dialogs due to forking, an offer/answer INVITE causes multiple dialogs due to forking, an offer/answer
exchange is carried out independently in each distinct dialog. When exchange is carried out independently in each distinct dialog. When
an INVITE request contains no offer, only pattern 2 or pattern 4 an INVITE request contains no offer, only pattern 2 or pattern 4
apply. 'The first reliable non-failure message' must have an offer apply. 'The first reliable non-failure message' must have an offer
if there is no offer in the INVITE request. This means that UA if there is no offer in the INVITE request. This means that UA
which receives the INVITE request without an offer must include an which receives the INVITE request without an offer must include an
offer in the first reliable response with 100rel extension. If no offer in the first reliable response with 100rel extension. If no
skipping to change at page 7, line 11 skipping to change at page 7, line 11
session description to describe capabilities apart from session description to describe capabilities apart from
offer/answer exchange. Examples of this are 200 OK responses for offer/answer exchange. Examples of this are 200 OK responses for
OPTIONS and 488 responses for INVITE. OPTIONS and 488 responses for INVITE.
3. Detailed Discussion of the Offer/Answer Model for SIP 3. Detailed Discussion of the Offer/Answer Model for SIP
3.1. Offer/Answer for the 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 [2]. 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 complicates With 100rel, pattern 3 and pattern 4 are added and this complicates
the rules. An INVITE request may cause multiple responses. Note the rules. An INVITE request may cause multiple responses. 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 provisional responses may be sent reliably. Note also that a
reliable provisional response is allowed without a session reliable provisional response is allowed without a session
description if the UAS does not wish to send the answer yet. An description if the UAS does not wish to send the answer yet. An
unreliable provisional response may include a session description unreliable provisional response may include a session description
skipping to change at page 7, line 39 skipping to change at page 7, line 39
answer until the actual one 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 single offer/answer exchange. In parallel offer/answer
exchanges (caused by forking) a UA may obviously receive a exchanges (caused by forking) a UA may obviously receive a
different "preview" of an answer in each dialog. UAs are different "preview" of an answer in each dialog. UAs are
expected to deal with this. expected to deal with this.
Although RFC 3261 says a UA should accept media once an INVITE with Although RFC 3261 says a UA should accept media once an INVITE with
an offer has been sent, in many cases, an answer (or, at least a an offer has been sent, in many cases, an answer (or, at least a
preview of it) is required in order for media to be accepted. preview of it) is required in order for media to be accepted. Two
examples of why this might be required are:
o To avoid receiving media from undesired sources, some User
Agents assume symmetric RTP will be used, ignore all incoming
media packets until an address/port has been received from the
other end, and then use that address/port to filter incoming
media packets.
o In some networks, an intermediate node must authorize a media
stream before it can flow and requires a confirming answer to
the offer before doing so.
Therefore, a UAS should send an SDP answer reliably (if possible) Therefore, a UAS should send an SDP answer reliably (if possible)
before it starts sending media. And, if neither the UAC nor the UAS before it starts sending media. And, if neither the UAC nor the UAS
support 100rel, the UAS should send a preview of the answer before support 100rel, the UAS should send a preview of the answer before
it starts sending 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, When a UAC includes an SDP body in the INVITE request as an offer,
it expects the answer to be received with one of the reliable it expects the answer to be received with one of the reliable
responses. Other than that, no offer/answer exchanges can occur in responses. Other than that, no offer/answer exchanges can occur in
skipping to change at page 11, line 16 skipping to change at page 11, line 48
the UAS to interact with the user at the peer, while UPDATE needs the UAS to interact with the user at the peer, while UPDATE needs
to be answered automatically by the UAS. It is noted that re-INVITE 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 [4], the following restrictions are defined with regard In RFC 3264 [4], 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 "At any time, either agent MAY generate a new offer that updates
which it has not yet answered or rejected. It MUST NOT generate the session. However, it MUST NOT generate a new offer if it
a new offer if it has generated a prior offer for which it has has received an offer which it has not yet answered or rejected.
not yet received an answer or a rejection." It MUST NOT generate a new offer if it has generated a prior
offer for which it has not yet received an answer or a
rejection."
Assuming that the above rules are guaranteed, there seem 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: the 'message crossing' case, and the 'glare' case. One of usage: the 'message crossing' case, and the 'glare' case. One of
the reasons why the usage of SIP methods to exchange offer/answer the reasons why the usage of SIP methods to exchange offer/answer
needs to be carefully restricted in the RFCs is to ensure that the needs to be carefully restricted in the RFCs is to ensure that the
UA can detect and handle appropriately the 'exceptional' cases to UA can detect and handle appropriately the 'exceptional' cases to
avoid incompatible behavior. avoid incompatible behavior.
4.1. Message Crossing Case Handling 4.1. Message Crossing Case Handling
When message packets crossed in the transport network, an offer may When message packets cross in the transport network, an offer 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 exchange, as shown in Figure 3. In such a case, UA A must detect
detect the session description of the offer2 is not the answer to that the session description SDP-2 is not the answer to offer1.
offer1.
A B A B
|offer1 | |SDP-1 (offer1)|
|----------------->| M1 |----------------->|
| answer1| |SDP-2 (answer1)|
|<------\ /-------| M2 |<------\ /-------|
| \/ | | \/ |
| /\ offer2| |SDP-3 /\(offer2)|
|<------/ \-------| M3 |<------/ \-------|
Figure 3 Message Crossing Case Figure 3 Message Crossing Case
When offer2 is in an UPDATE request or a re-INVITE request, a Because of the restrictions on placement of offers and answers
session description cannot be the expected answer. Then UA A must (summarized in Table 1) there are a limited number of valid
reject the message including offer2 with a 491 response with Retry- exchanges of messages that may lead to this message crossing case.
After header field. These are enumerated in Table 3. (This table only shows messages
containing offers or answers. There could be other messages,
without session descriptions, which are not shown.)
When offer2 is in a PRACK request, that is, when the PRACK request There is a variant, shown in Figure 4, which is dependent on an
is acknowledging a reliable provisional response with an answer to INVITE (Mx) that contains no offer. This case should be extremely
an offer in an INVITE request containing a session description, UA rare - it is easily avoided by delaying Mx until answer1 is
A knows it is an offer. To avoid rejecting the PRACK or PRACK offer, received. It adds another possibility to Table 3.
UA A is recommended to wait for answer1 before sending a PRACK
response with the answer to the offer2. Note that if UA A does not
send a new offer until the reliable provisional response with an
answer to the offer in the INVITE request is acknowledged with a
PRACK request, this case never happens. Fortunately, under the
current rules, UA A can not send a new offer until the reliable
response.
When offer2 is in a reliable provisional response or a successful A B
final response (as shown in Figure 4), UA A knows it is not the | |
answer to the offer1. For a reliable response to an initial INVITE |SDP-1 offer1(UPD) |
request, this case never happens. For a reliable response to a re- M1 |==============================>|
INVITE request, UA A can infer that offer2 is not the answer1. In |re-INV (no offer) |
this case, since UA A can not reject offer2 in a reliable response, Mx |------------------------------>| --+
it is recommended that it wait for answer1 before sending a PRACK |SDP-2 answer1 (2xx-UPD)| |
request with the answer to offer2. Note that this case only occurs M2 |<===========\ /===============| | first reliable
when UA A, while waiting for an answer, sends an INVITE request | \/ offer2| | response
without session description. |SDP-3 /\ (1xx-rel/2xx)| |
M3 |<===========/ \===============| <-+
|SDP-4 answer2 (PRACK/ACK)|
My |------------------------------>| Wait until answer1
| |
Table 3 summarizes the discussions above. Figure 4 Reliable response as a message with offer2 in message
crossing case
offer2 | How to know it's not answer1 | Actions to take | M1 | M3 | M2 |
|--------+----------+---------|
| INVITE | 1xx-rel | UPDATE |
|--------+----------+---------|
| PRACK | 200-PRA | UPDATE |
|--------+----------+---------|
| UPDATE | 200-UPD | UPDATE |
| | |---------|
| | | INVITE | (no INV in progress)
| | |---------|
| | | 2xx-INV | (INV in progress)
| | |---------|
| | | 1xx-rel | (from Figure 4)
|-----------------------------|
Table 3. Offer / Answer Crossing Message Sequences
Table 3 shows that there are only two ambiguous cases when an
answer is expected and an arriving message M2 containing SDP could
be either the expected answer or an offer. These are a reliable 1xx
response to an INVITE, or an UPDATE.
When message M2 is an UPDATE request or a (re)INVITE request, then
message M1 must also have been an UPDATE or INVITE. There may have
been message crossing, or not. If not then it is a glare case.
Either way, the remedy is for UA A to reject message M2 with a 491
response with Retry-After header field.
When M2 is a reliable provisional response or a successful final
response, and M1 was an UPDATE, then SDP-2 cannot be the expected
answer1. In this case, since UA A can not reject offer2 in reliable
response M2, it is recommended that it wait for answer1 before
sending a PRACK request with the answer to offer2. Note that this
case only occurs when UA A, while waiting for an answer, sends an
INVITE request without session description.
When M2 is a PRACK request Table 3 shows that it cannot be an offer
out of order, so UA A may infer SDP-2 is an answer.
Table 4 summarizes the discussions above.
SDP-2 | 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 | This case never happens | - 1xx-rel| If M1 was UPDATE then SDP-2 | Delay ACK/PRACK
| under the current rules. | 2xx-INV| is not answer1 | until answer1 is received
-------+------------------------------+-------------------------- -------+------------------------------+--------------------------
1xx-rel| Only one INVITE transaction | Delay ACK/PRACK PRACK | This case never happens | Not a message cross case
2xx | at a time. Then UA can know | until answer1 is received | under the current rules. | Treat SDP-2 as answer2
-------+------------------------------+-------------------------- -------+------------------------------+--------------------------
Table 4. Message Crossing Resolution
NOTE: 1xx-rel/2xx case is extremely rare case and easily avoidable.
See Figure 4.
Table 3. UA's action to an offer (offer2) overtaking the previous
answer (answer1)
A B
| |
|offer1(e.g. UPD) |
|==============================>|
|re-INV (no offer) |
|------------------------------>| --+
| answer1 (2xx-UPD)| |
|<===========\ /===============| | The first reliable response
| \/ offer2| |
| /\ (1xx-rel/2xx)| |
|<===========/ \===============| <-+
| answer2 (PRACK/ACK) |
|------------------------------>| Wait until answer1
| |
Figure 4 Reliable response as a message with offer2 in message
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,
as described in Figure 5, a UA may receive a new offer before it as described in Figure 5, a UA may receive a new offer before it
receives the answer to the offer it sent. This case is usually receives the answer to the offer it sent. This case is usually
called a 'glare' case. called a 'glare' case.
A B A B
|offer1 offer2| |offer1 offer2|
skipping to change at page 16, line 28 skipping to change at page 17, line 37
sent reliably, and changed with an UPDATE if the user desires sent reliably, and changed with an UPDATE if the user desires
a change. If PRACK and UPDATE are not supported then the a change. If PRACK and UPDATE are not supported then the
initial offer cannot be changed until the call is fully initial offer cannot be changed until the call is fully
established. In that case either the offer should be delayed established. In that case either the offer should be delayed
until the 200 is sent, or else the offer should include the until the 200 is sent, or else the offer should include the
minimum set of media the user is able to select. minimum set of media the user is able to select.
5.2.3. Answering an 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 When a UAS receives an initial INVITE with an offer, what media
lines the answer may contain is constrained by RFC 3264 [4]. The lines the answer may contain is constrained by RFC 3264.[4] The
answer must contain the same number of m-lines as the offer, and answer must contain the same number of m-lines as the offer, and
they must contain the same media types. Each media line may be they must contain the same media types. Each media line may be
accepted, by including a non-zero port number, or rejected by accepted, by including a non-zero port number, or rejected by
including a zero port number in the answer. The media lines that including a zero port number in the answer. The media lines that
are accepted should typically be those that would have been offered are accepted should typically be those that would have been offered
had the INVITE not contained an offer, excluding those not offered. had the INVITE not contained an offer, excluding those not offered.
The media formats the answer may contain are constrained by RFC The media formats the answer may contain are constrained by RFC
3264 [4]. For each accepted m-line in the answer, there must be at 3264 [4]. For each accepted m-line in the answer, there must be at
least one media format in common with the corresponding m-line of least one media format in common with the corresponding m-line of
 End of changes. 25 change blocks. 
125 lines changed or deleted 157 lines changed or added

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