draft-ietf-sipping-sip-offeranswer-11.txt   draft-ietf-sipping-sip-offeranswer-12.txt 
Sipping P. Kyzivat Sipping P. Kyzivat
Internet-Draft Cisco Systems, Inc. Internet-Draft Cisco Systems, Inc.
Intended status: Informational T. Sawada Intended status: Informational T. Sawada
Expires: July 22, 2010 KDDI Corporation Expires: September 9, 2010 KDDI Corporation
January 18, 2010 March 8, 2010
SIP (Session Initiation Protocol) Usage of the Offer/Answer Model SIP (Session Initiation Protocol) Usage of the Offer/Answer Model
draft-ietf-sipping-sip-offeranswer-11 draft-ietf-sipping-sip-offeranswer-12
Abstract Abstract
The Session Initiation Protocol (SIP) utilizes the offer/answer model The Session Initiation Protocol (SIP) utilizes the offer/answer model
to establish and update multimedia sessions using the Session 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.
skipping to change at page 1, line 42 skipping to change at page 1, line 42
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on July 22, 2010. This Internet-Draft will expire on September 9, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 13, line 8 skipping to change at page 13, line 8
Figure 3 Message Crossing Case Figure 3 Message Crossing Case
Because of the restrictions on placement of offers and answers Because of the restrictions on placement of offers and answers
(summarized in Table 1) there are a limited number of valid exchanges (summarized in Table 1) there are a limited number of valid exchanges
of messages that may lead to this message crossing case. These are of messages that may lead to this message crossing case. These are
enumerated in Table 3. (This table only shows messages containing enumerated in Table 3. (This table only shows messages containing
offers or answers. There could be other messages, without session offers or answers. There could be other messages, without session
descriptions, which are not shown.) descriptions, which are not shown.)
There is a variant, shown in Figure 4, which is dependent on an There are variants, shown in Figures 4a and 4b, which are dependent
INVITE (Mx) that contains no offer. This case should be extremely on an INVITE (Mx) that contains no offer. These are also included in
rare - it is easily avoided by delaying Mx until answer1 is received. Table 3.
It adds another possibility to Table 3.
A B A B
| | | |
|SDP-1 offer1(UPD) | |SDP-1 offer1(UPD) |
M1 |==============================>| M1 |==============================>|
|re-INV (no offer) | |re-INV (no offer) |
Mx |------------------------------>| --+ Mx |------------------------------>| --+
|SDP-2 answer1 (2xx-UPD)| | |SDP-2 answer1 (2xx-UPD)| |
M2 |<===========\ /===============| | first reliable M2 |<===========\ /===============| | first reliable
| \/ offer2| | response | \/ offer2| | response
|SDP-3 /\ (1xx-rel/2xx)| | |SDP-3 /\ (1xx-rel/2xx)| |
M3 |<===========/ \===============| <-+ M3 |<===========/ \===============| <-+
|SDP-4 answer2 (PRACK/ACK)| |SDP-4 answer2 (PRACK/ACK)|
My |------------------------------>| Wait until answer1 My |------------------------------>|
| | | |
Figure 4 Reliable response as a message with offer2 in message Figure 4a Avoidable message crossing cases
crossing case
| 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 A B
| |
|re-INV (no offer) |
Mx |------------------------------>| --+
|SDP-1 offer1(UPD) | |
M1 |==============================>| |
|SDP-2 answer1 (2xx-UPD)| |
M2 |<===========\ /===============| | first reliable
| \/ offer2| | response
|SDP-3 /\ (1xx-rel/2xx)| |
M3 |<===========/ \===============| <-+
|SDP-4 answer2 (PRACK/ACK)|
My |------------------------------>|
| |
Table 3 shows that there are only two ambiguous cases when an answer Figure 4b Avoidable message crossing cases
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 | M1 | M3 | M2 | Action
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. | UPDATE | 2xx-UPD | UPDATE | (1)
Either way, the remedy is for UA A to reject message M2 with a 491 | | +---------|---------
response with Retry-After header field. | | | INVITE | (1)
| | +---------+---------
| | | 1xx-INV | (2)
| | +---------+---------
| | | 2xx-INV | (2)
+--------+----------+---------+---------
| PRACK | 2xx-PRA | UPDATE | (1)
+--------+----------+---------+---------
| 2xx-INV| ACK | UPDATE | (1)
| | +---------+---------
| | | INVITE | (1)
+--------+----------+---------+---------
| INVITE | 1xx-rel | ??? | (3)
| |----------+---------+---------
| | 2xx-INV | ??? | (3)
+--------+----------+---------+---------
| 1xx-rel| PRACK | ??? | (3)
+--------+----------+---------+---------
When M2 is a reliable provisional response or a successful final Table 3. Offer / Answer Crossing Message Sequences
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 (1) This is indistinguishable from true glare. UA A should respond
out of order, so UA A may infer SDP-2 is an answer. to M2 with a 491 response.
Table 4 summarizes the discussions above. (2) This can only occur in situations depicted in figures 4a and 4b.
It is easier for UA A to avoid these situations than to recover
from them. The situation in Figure 4a can be avoided by
refraining from sending a re-INVITE without offer when an
unanswered offer is outstanding. The situation in Figure 4b can
be avoided by refraining from sending any message containing an
offer while an INVITE without offer is outstanding.
SDP-2 | How to know it's not answer1 | Actions to take (3) There are no valid sequences that result in these cases.
-------+------------------------------+--------------------------
INVITE | Never be an answer | 491 response
UPDATE | Glare case for UA A | with Retry-After
-------+------------------------------+--------------------------
1xx-rel| If M1 was UPDATE then SDP-2 | Delay ACK/PRACK
2xx-INV| is not answer1 | until answer1 is received
-------+------------------------------+--------------------------
PRACK | This case never happens | Not a message cross case
| under the current rules. | Treat SDP-2 as answer2
-------+------------------------------+--------------------------
Table 4. Message Crossing Resolution Summarizing, a UA that has an outstanding unanswered offer should:
o refrain from sending a re-INVITE without an offer;
o reject (491) an INVITE or UPDATE containing an offer.
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 15, line 12 skipping to change at page 15, line 18
| \/ | | \/ |
| /\ | | /\ |
|<------/ \------>| |<------/ \------>|
Figure 5 Glare Case Figure 5 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), UA A has a dilemma: all
accepted with 200 or may be rejected with a 491 response. A 491 PRACKs are supposed to be accepted with 200 response, yet there is no
response is valid to satisfy the offer/answer model but it may delay way to indicate the problem with a 200 response. At best it could
the completion of the reliable response transfer mechanism or, in proceed on the assumption that its INVITE will be rejected with a
worst case, may result in the failure to complete the SIP transaction 491. To avoid this glare condition, UA A should not send an offer if
because there is no clear retry rule when a PRACK request is rejected it has already sent a reliable provisional response containing an
with a 491 response. To avoid this glare condition, UA A should not answer to a previous offer and has not received the corresponding
send an offer if it has already sent a reliable provisional response PRACK request.
containing an answer to a previous offer and has not received the
corresponding PRACK request.
To avoid a glare condition involving an offer in a response, when UA Glare can also occur when offer2 is in a 1xx or 2xx response. To
A has sent a (re)INVITE request without session description, it avoid this situation, when UA A has sent a (re)INVITE request without
should not send an offer until it has received an offer in a reliable session description, it should not send an offer until it has
response to the (re)INVITE, and sent an answer to that offer. received an offer in a 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 [RFC3264] and [RFC3312] give some guidance, questions remain While [RFC3264] and [RFC3312] 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 is
especially a problem when the common "hold" feature has been 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 User
Agent. The kinds of recommendations that can be made are limited by Agent. The kinds of recommendations that can be made are limited by
skipping to change at page 18, line 37 skipping to change at page 18, line 38
body is implementation dependent. If a UA needs to negotiate a body is implementation dependent. If a UA needs to negotiate a
'new' SDP session, it should use the INVITE/Replaces method. '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 payload
type number to a particular codec within that media stream type number to a particular codec within that media stream
(m-line) must not change for the duration of the session. (m-line) must not change for the duration of the session.
(Section 8.3.2 of [RFC3264].) (Section 8.3.2 of [RFC3264].)
NOTE: This may be impossible for a B2BUA to follow in some NOTE: This may be impossible for a B2BUA to follow in some
cases (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, it
all codecs supported by the UA are to be included, not just the ones should be constructed according to the General Principle for
that were negotiated by previous offer/answer exchanges. The same is Constructing Offers and Answers (Section 5.1 ): all codecs the UA is
true for media types - so if UA A initially offered audio and video currently willing and able to use should be included, not just the
to UA B, and they end up with only audio, and UA B sends an offerless ones that were negotiated by previous offer/answer exchanges. The
(re)INVITE to UA A, A's resulting offer should re- attempt video, by same is true for media types - so if UA A initially offered audio and
reusing the zeroed m-line used previously. video to UA B, and they end up with only audio, and UA B sends an
offerless (re)INVITE to UA A, A's resulting offer should most likely
re-attempt video, by reusing the zeroed m-line used previously.
NOTE: The behavior above is recommended, but it is not always NOTE: The behavior above is recommended, but it is not always
achievable - for example in some interworking scenarios. Or, the achievable - for example in some interworking scenarios. Or, the
offerer may simply not have enough resources to offer "everything" offerer may simply not have enough resources to offer "everything"
at that point. Even if the UAS is not able to offer any other SDP at that point. Even if the UAS is not able to offer any other SDP
that the one currently being used, it should not reject the re- that the one currently being used, it should not reject the re-
INVITE. Instead, it should generate an offer with the currently INVITE. Instead, it should generate an offer with the currently
used SDP with o- line unchanged. used SDP with o- line unchanged.
5.3. Hold and Resume of media 5.3. Hold and Resume of media
skipping to change at page 22, line 14 skipping to change at page 22, line 14
9.2. Informative References 9.2. Informative References
[RFC3959] Camarillo, G., "The Early Session Disposition Type for the [RFC3959] Camarillo, G., "The Early Session Disposition Type for the
Session Initiation Protocol (SIP)", RFC 3959, Session Initiation Protocol (SIP)", RFC 3959,
December 2004. December 2004.
[I-D.ietf-sipping-config-framework] [I-D.ietf-sipping-config-framework]
Channabasappa, S., "A Framework for Session Initiation Channabasappa, S., "A Framework for Session Initiation
Protocol User Agent Profile Delivery", Protocol User Agent Profile Delivery",
draft-ietf-sipping-config-framework-16 (work in progress), draft-ietf-sipping-config-framework-17 (work in progress),
September 2009. February 2010.
Authors' Addresses Authors' Addresses
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
 End of changes. 18 change blocks. 
81 lines changed or deleted 84 lines changed or added

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