SIPPING Working Group T. Sawada
Internet Draft KDDI Corporation
Expires: December 2006 P. Kyzivat
Cisco Systems, Inc.
June 11, 2006
SIP (Session Initiation Protocol) Usage of Offer/Answer Model
draft-sawada-sipping-sip-offeranswer-01.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that
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
becomes aware will be disclosed, in accordance with Section 6 of
BCP 79.
This document may only be posted in an Internet-Draft.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on November 11, 2006.
Abstract
SIP utilizes offer/answer model to establish and update multimedia
sessions. The descriptions on how to use offer/answer in SIP are
dispersed in the multiple RFCs. This document summarizes all the
current usage of offer/answer model in SIP communication.
Sawada & Kyzivat Expires December 11, 2006 [Page 1]
Internet-Draft SIP Usage of Offer/Answer Model June 2006
Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [1].
Table of Contents
1. Summary of SIP usage of Offer/Answer Model...................2
1.1. Offer/Answer Exchange Pairs in SIP Messages.............3
1.2. Rejection against an Offer..............................4
2. Detailed Discussion on Offer/Answer Model for SIP............5
2.1. Offer/Answer for INVITE method with 100rel extension....5
2.1.1. INVITE Request with SDP............................6
2.1.2. INVITE request without SDP.........................7
2.2. Offer/Answer Exchange in Early Dialog...................8
2.3. Offer/Answer Exchange in Established Dialog.............9
3. Exceptional Case Handling....................................9
3.1. Message Crossing Case Handling..........................9
3.2. Glare Case Handling....................................10
4. Add New Offer/Answer Usage in SIP...........................11
4.1. Explicit Usage.........................................11
4.2. Rejection against an Offer.............................11
4.3. Backward Compatibility.................................12
4.4. Exceptional Case Handling..............................12
5. Security Considerations.....................................12
6. References..................................................12
6.1. Normative References...................................12
Author's Addresses.............................................12
Intellectual Property Statement................................13
Disclaimer of Validity.........................................13
Copyright Statement............................................13
Acknowledgment.................................................14
1. Summary of SIP usage of Offer/Answer Model
Offer/answer model itself is independent from the higher layer
application protocols which utilize it. SIP is one of the
applications using offer/answer model. In RFC 3264 [4], which defines
offer/answer model, which SIP message should convey an offer or an
answer is not defined. This should be defined in the SIP core and
extensions RFCs.
In theory, any SIP message can include session description in its
body. But not all the session description in a SIP message is an
offer or an answer. Only the session description that conforms to the
rules described in the standard track RFCs can be interpreted as an
Sawada & Kyzivat Expires December 11, 2006 [Page 2]
Internet-Draft SIP Usage of Offer/Answer Model June 2006
offer or an answer. The rules how to handle offer/answer model are
currently defined in several RFCs. Unless defined in an RFC
explicitly as an offer or an answer, except ones in non-reliable
provisional response to INVITE request, a session description should
not be included in SIP messages to avoid confusions.
Offer/answer model defines the update of sessions. In SIP, dialog is
used to match the offer/answer exchange to the session which is to be
updated with it. In other words, only the offer/answer exchange in
the SIP dialog can update the session which is managed with it.
1.1. Offer/Answer Exchange Pairs in SIP Messages
Currently, the rules on offer/answer model are defined in RFC 3261,
RFC 3262 and RFC 3311. In these RFCs, only the six patterns shown in
Table 1 are defined for exchanging an offer and an answer with SIP
messages.
Note that an offer/answer exchange initiated by an INVITE request
must follow exactly one of the patterns 1, 2, 3, 4. Only one of them,
one for each dialog if multiple dialogs are created, must occur in an
INVITE 3-way handshake process. Pattern 2 and pattern 4 can occur
only when INVITE request does not include an offer. 'The first
reliable non-failure message' must have an offer if there is no offer
in the INVITE request. This means that UA which receives the INVITE
request without an offer must include an offer in the first reliable
response with 100rel extension. If no reliable provisional response
has been sent, UAS must include an offer when sending 2xx response.
In pattern 3, the first reliable provisional response may or may not
have an answer. When a reliable provisional response contains a
session description, and is the first to do so, then that session
description is the answer to the offer in the INVITE request.
In pattern 5, PRACK request can contain an offer only if the non-
reliable response which it acknowledges contains an answer in the
previous offer/answer exchange.
Offer Answer RFC Ini Est Early
-------------------------------------------------------------------
1. INVITE Req. 2xx INVITE Resp. RFC 3261 O O X
2. 2xx INVITE Resp. ACK Req. RFC 3261 O O X
3. INVITE Req. 1xx-rel INVITE Resp. RFC 3262 O O X
4. 1xx-rel INVITE Resp. PRACK Req. RFC 3262 O O X
5. PRACK Req. 200 PRACK Resp. RFC 3262 X O O
6. UPDATE Req. 2xx UPDATE Resp. RFC 3311 X O O
Table 1. Summary of SIP Usage of Offer/Answer Model
Sawada & Kyzivat Expires December 11, 2006 [Page 3]
Internet-Draft SIP Usage of Offer/Answer Model June 2006
In Table 1, '1xx-rel' corresponds to the reliable provisional
response which applies 100rel option defined in RFC 3262 [3].
'Ini' column shows the ability to exchange the offer/answer to
initiate the session. 'O' indicates that the pattern can be used in
the initial offer/answer exchange, while 'X' indicates that it can
not. Only the initial INVITE request can be used to exchange the
offer/answer to establish multimedia session.
'Est' column shows the ability to update the established session.
'Early' column shows the ability to be used to modify the established
session in an early dialog. There are two ways to exchange subsequent
offer/answer in an early dialog.
1.2. Rejection against an Offer
How to reject an offer when it can not be accepted is not so clear
and some method can not allow explicit rejection against an offer.
Corresponding to the patterns in Table 1, how to reject an offer is
shown in Table 2.
When a UA receives an INVITE request with an offer which it can not
accept, it should respond with a 488 response preferably with Warning
header field indicating the reason of the rejection unless other
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
accept, it should respond with a 488 response preferably with Warning
header field indicating the reason of the rejection unless other
response code is more appropriate to reject it. (Pattern 6)
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
correct session description followed by an UPDATE request possibly to
rearrange the session parameters if both ends support UPDATE method.
A UA may simply give up continuing the dialog and send error response
to INVITE request. (Pattern 5)
When a UA receives a response with an offer which it can not accept,
a UA does not have the way to reject it explicitly. Therefore, an UA
should respond to the offer with the correct session description and
rearrange the session parameters by initiating a new offer/answer
exchange. (Pattern 2 and Pattern 4)
Sawada & Kyzivat Expires December 11, 2006 [Page 4]
Internet-Draft SIP Usage of Offer/Answer Model June 2006
Offer Rejection
-----------------------------------------------------
1. INVITE Req. 488 INVITE Response
2. 2xx INVITE Resp. Answer in ACK Req. followed by new offer
3. INVITE Req. 488 INVITE Response (same as Pattern 1.)
4. 1xx-rel INVITE Resp. Answer in PRACK Req. followed by new offer
5. PRACK Req. (*) 200 PRACK Resp. followed by new offer
6. UPDATE Req. 488 UPDATE Response
Table 2. Rejection against an Offer
(*) UA should only use PRACK to send an offer when it has strong
reasons to assume the receiver will accept.
1.3. Session Description which is not Offer nor Answer
As it is stated, not all the session description in a SIP message is
an offer or an answer. For example, SIP can use the session
description to describe the capabilities apart from offer/answer
exchange. Examples of these messages are 200 OK responses for OPTIONS
and 488 responses for INVITE.
2. Detailed Discussion on Offer/Answer Model for SIP
2.1. Offer/Answer for INVITE method with 100rel extension
INVITE method is the basic procedure for offer/answer exchange in SIP.
Without 100rel option, the rules are simple as described in RFC 3261
[2]. If an INVITE request includes a session description, pattern 1
is applied and if an INVITE request does not include a session
description, pattern 2 is applied.
With 100rel, pattern 3 and pattern 4 are added and this makes the
rules complicated. An INVITE request may cause multiple responses.
Note that even if both UAs support 100rel extension, not all the
provisional responses are sent reliably. Note also that a reliable
provisional response is allowed not to include a session description
even when UAS does not send the answer yet. Unreliable provisional
response may include a session description in its body until an UAC
receives the answer, but its session description is not an offer nor
an answer. All the session descriptions in the unreliable responses
to the INVITE request must be identical to the answer which is
included in the reliable response. Session description in an
unreliable response that precedes a reliable response can be
considered a "preview" of the session description that will be coming,
and hence may be treated like an offer or an answer until the actual
one arrives.
Sawada & Kyzivat Expires December 11, 2006 [Page 5]
Internet-Draft SIP Usage of Offer/Answer Model June 2006
2.1.1. INVITE Request with SDP
When UAC includes an SDP in the INVITE request as an offer, it
expects the answer to be received with one of the reliable responses.
Other than that, no offer/answer exchanges can occur in the INVITE 3-
way handshake process.
UAC UAS
| F1 INVITE (SDP) | <- The offer in offer/answer model
|-------------------->|
| F2 1xx (SDP) | <- The SDP is not an official answer but
|<--------------------| UAC act as if it receives the answer.
| | ^
| F3 1xx-rel (no SDP) | |<- a 1xx-rel may be sent without answer
|<--------------------| | SDP.
| F4 PRACK (no SDP) | |
|-------------------->| | UAC must not send a new offer.
| F5 2xx PRA (no SDP) | |
|<--------------------| v
| |
| F6 1xx-rel (SDP) | <- The answer in offer/ answer model
|<--------------------| -
| F7 PRACK | | UAC can send a new offer in a PRACK
|-------------------->| | request to acknowledge F6.
| F8 2xx PRA | | After F6 UAC and UAS can send a new offer
|<--------------------| v in an UPDATE request.
| |
| F9 1xx-rel | <- SDP should not be included in the
|<--------------------| subsequent 1xx-rel once offer/answer
| F10 PRACK | has been completed.
|-------------------->|
| F11 2xx PRA |
|<--------------------|
| |
| F12 2xx INV | <- SDP should not be included in the final
|<--------------------| response once offer/answer has been
| F13 ACK | completed.
|-------------------->|
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
in the non-reliable response (F3) must be the same as the answer in
F6 but is not the answer. Receiving F3, UAC should act as if it
receives the answer. However, offer/answer exchange is not completed
yet and UAC must not send a new offer until it receives the same SDP
in the first reliable response, which is the real answer. After
Sawada & Kyzivat Expires December 11, 2006 [Page 6]
Internet-Draft SIP Usage of Offer/Answer Model June 2006
sending the SDP in F6, UAS must prepare to receive new offer from UAC
with an UPDATE request or a PRACK request.
UAS should not include an SDP in the responses F9 and F12. However,
UAC should prepare to receive an SDP in F9 and/or F12, and just
ignore them for the case that the peer does not conform to the
recommended implementation.
2.1.2. INVITE request without SDP
When UAC does not include an SDP in the INVITE request, it expects
the offer to be received with the first reliable response. UAC will
send the answer in the request to acknowledge the response, i.e.
PRACK request for the reliable response. Other than that, no
offer/answer exchanges can occur in the INVITE 3-way handshake
process.
For example, in Figure 2, only the SDP in F3 is the answer. The SDP
in the non-reliable response (F2) must be the same as the offer in F3
but is not the offer. Receiving F2, UAC can act as if it receives the
offer. However, the official offer is not received until it receives
the first reliable response. The first reliable response (F3) must
include an SDP as an offer.
UAS should not include an SDP in the responses F6 and F9. However,
UAC should prepare to receive an SDP in F6 and/or F9, and just ignore
them for the case that the peer does not conform to the recommended
implementation.
Sawada & Kyzivat Expires December 11, 2006 [Page 7]
Internet-Draft SIP Usage of Offer/Answer Model June 2006
UAC UAS
| F1 INVITE (no SDP) |
|-------------------->|
| F2 1xx (SDP) | <- SDP may be included but it is not the
|<--------------------| offer. UAC may act as if it receives
| | the offer.
| F3 1xx-rel (SDP) | <- The first 1xx-rel must contain an SDP
|<--------------------| as the offer.
| F4 PRACK (SDP) | <- An PRACK request to the first 1xx-rel
|-------------------->| must contain an SDP as the answer.
| F5 2xx PRA (no SDP) | -
|<--------------------| |
| | |
| F6 1xx-rel (no SDP) | <- The subsequent 1xx-rel should not
|<--------------------| | contain an SDP.
| F7 PRACK | |
|-------------------->| | UAC can send a new offer in an UPDATE
| F8 2xx PRA | | request after F4.
|<--------------------| v
| |
| F9 2xx INV (no SDP) | <- The final response should not
|<--------------------| contain an SDP.
| F10 ACK |
|-------------------->|
Figure 2 Example of Offer/Answer with 100rel Extension (2)
2.2. Offer/Answer Exchange in Early Dialog
When both UAs support 100rel extension, they can update the session
in the early dialog once the first offer/answer exchange has been
completed.
From UA sending an INVITE request:
UA can send an UPDATE request with a new offer if both ends support
UPDATE method. Whether UPDATE method is supported must be declared in
Allow header in some prior messages in the dialog.
UA can send a PRACK request with a new offer when acknowledging the
reliable provisional response with the answer to the offer in the
INVITE request. Compared to UPDATE method, using PRACK can save
messages to be exchanged between the UAs. However, as a PRACK request
should not be rejected, UA is recommended to send a PRACK request
only when it has strong reasons to assume the receiver will accept it.
For example, the procedure used in precondition extension[6] is the
case that a PRACK request should be used for updating the session
status in the early dialog.
Sawada & Kyzivat Expires December 11, 2006 [Page 8]
Internet-Draft SIP Usage of Offer/Answer Model June 2006
From UA receiving an INVITE request:
UA can send an UPDATE request with a new offer if both ends support
UPDATE method. UAS can not send new offer in the reliable provisional
response. So UPDATE method is the only method for UAS to update the
early session.
2.3. Offer/Answer Exchange in Established Dialog
Re-INVITE method and UPDATE method can be used in the established
dialog to update the session.
UPDATE method is simpler and can save at least one message compared
with INVITE method. But both ends must support UPDATE method to use
UPDATE.
INVITE method needs at least three messages to complete but no
extensions are needed. Additionally, INVITE method allows the peer to
take time to decide whether it accept session update 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 be answered
automatically by the UAS. It is noted that re-INVITE should be
answered immediately unless such a user interaction is needed.
Otherwise, some 3pcc flows would break.
3. Exceptional Case Handling
In RFC 3264 [4], the following restrictions are defined with regard
to sending a new 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
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 seems to be two
possible 'exceptional' cases to be considered in SIP offer/answer
usage, which are 'message crossing' case and 'glare' case. One of the
reasons why the usage of a SIP method to exchange offer/answer needs
to be carefully restricted in the RFCs is to make sure that UA can
detect and handle appropriately the 'exceptional' cases to avoid the
confusion.
3.1. Message Crossing Case Handling
When message packets are crossed in the transport network, an offer
may reach before the answer for the previous offer/answer exchange as
Sawada & Kyzivat Expires December 11, 2006 [Page 9]
Internet-Draft SIP Usage of Offer/Answer Model June 2006
described in Figure 3. In such a case, UA A must detect the session
description of the offer2 is not the answer to the offer1.
A B
|offer1 |
|----------------->|
| answer1|
|<------\ /-------|
| \/ |
| /\ offer2|
|<------/ \-------|
Figure 3 Message Crossing Case
When offer2 is in an UPDATE request or a re-INVITE request, a session
description can never be the answer. Then UA A must reject the
message including offer2 with a 500 response with Retry-After header
field.
When offer2 is in a PRACK request, that is, when PRACK request to
acknowledge the reliable provisional response with an answer to the
offer in the INVITE request contains a session description, UA A
knows it is an offer. As a PRACK request should not be rejected, UA A
is recommended to wait for the answer1 until 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. Therefore, to make implementations simple, a
UA acting as a UAS for INVITE transaction is recommended not to send
a UPDATE request with an offer until the reliable response with an
answer to the offer in the INVITE request is acknowledged with PRACK
request.
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
reliable response to an initial INVITE request, this case never
happens. For a reliable response to a re-INVITE request, UA A can
detect the offer2 is not the answer1. In this case, UA A can not
reject offer2 in a reliable response, it is recommended to wait for
the answer1 until sending a PRACK request with the answer to the
offer2. Note that if UA A does not send an INVITE request without
session description if it has sent the offer which has not yet
received the answer to it, this case never happens.
3.2. Glare Case Handling
When both ends in a dialog send an offer at nearly the same time, UA
may receive a new offer before it receives the answer to the offer
Sawada & Kyzivat Expires December 11, 2006 [Page 10]
Internet-Draft SIP Usage of Offer/Answer Model June 2006
itsends as described in Figure 4. This case is called 'glare' case in
general.
A B
|offer1 offer2|
|-------\ /-------|
| \/ |
| /\ |
|<------/ \------>|
Figure 4 Glare Case
When offer2 is in an UPDATE request or (re-)INVITE request, it must
be rejected with a 491 response.
When offer2 is in a PRACK request, it may be accepted with 200 or may
be rejected with a 491 response. A 491 response may be adequate for
offer/answer model but it may delay the completion of the reliable
response transfer mechanism or, in worst case, may result in the
failure to complete SIP transaction because there is no clear retry
rule when a PRACK request is rejected with a 491 response. To avoid
this glare condition, UA is recommended not to send an offer, which
currently must be in an UPDATE request, if it has generated the
reliable provisional response with the answer to the offer in the
INVITE request which is not acknowledged with a PRACK request.
To avoid glare condition for offer2 in the response, UA A is
recommended not to send a new offer if it has generated (re)INVITE
request without session description which it has not received the
reliable response with the offer.
4. Add New Offer/Answer Usage in SIP
It is not recommended to add new SIP methods for the offer/answer
exchange beyond the ways described in this document. However, it may
be requested to have new offer/answer exchange methods as SIP
extensions evolve. In this clause, what should be taken into
considerations is noted in this section.
4.1. Explicit Usage
New method should define the usage explicitly without any ambiguity.
4.2. Rejection against an Offer
New method should define how to reject an offer where possible.
Sawada & Kyzivat Expires December 11, 2006 [Page 11]
Internet-Draft SIP Usage of Offer/Answer Model June 2006
4.3. Backward Compatibility
New method must keep backward compatibility.
4.4. Exceptional Case Handling
New method should take care of how to handle exceptional cases,
message crossing case and glare case.
5. Security Considerations
There are not any security issues beyond the referenced RFCs.
6. References
6.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002.
[3] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional
Responses in the Session Initiation Protocol (SIP)", RFC 3262,
June 2002.
[4] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
SDP", RFC 3264, June 2002.
[5] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE
Method", RFC 3311, September 2002.
[6] Camarillo, G., Marshall, W., and J. Rosenberg, "Integration of
Resource Management and Session Initiation Protocol (SIP)", RFC
3312, October 2002.
Author's Addresses
Takuya Sawada
KDDI Corporation
3-10-10, Iidabashi, Chiyoda-ku, Tokyo, Japan
Email: tu-sawada@kddi.com
Sawada & Kyzivat Expires December 11, 2006 [Page 12]
Internet-Draft SIP Usage of Offer/Answer Model June 2006
Paul H. Kyzivat
Cisco Systems, Inc.
1414 Massachusetts Avenue
Boxborough, MA 01719
USA
Email: pkyzivat@cisco.com
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
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
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2006).
Sawada & Kyzivat Expires December 11, 2006 [Page 13]
Internet-Draft SIP Usage of Offer/Answer Model June 2006
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Sawada & Kyzivat Expires December 11, 2006 [Page 14]