SIPPING Working Group T. Sawada Internet Draft KDDI Corporation Expires: April 2006 P. Kyzivat Cisco Systems, Inc. October 13, 2005 Best Current Practice for SIP (Session Initiation Protocol) Usage of Offer/Answer Model draft-sawada-sipping-sip-offeranswer-00.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 April 13, 2006. Copyright Notice Copyright (C) The Internet Society (2005). All Rights Reserved. Sawada Expires April 13, 2006 [Page 1] Internet-Draft SIP Usage of Offer/Answer Model October 2005 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. 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.........................10 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.............................12 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.............................................13 Intellectual Property Statement................................13 Disclaimer of Validity.........................................14 Copyright Statement............................................14 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 Sawada Expires April 13, 2006 [Page 2] Internet-Draft SIP Usage of Offer/Answer Model October 2005 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 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. Sawada Expires April 13, 2006 [Page 3] Internet-Draft SIP Usage of Offer/Answer Model October 2005 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 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 in an early dialog. There are two ways to exchange 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 Sawada Expires April 13, 2006 [Page 4] Internet-Draft SIP Usage of Offer/Answer Model October 2005 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) 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 INVITE Response Table 2. Rejection against an Offer (*) Offer should not be sent with PRACK request unless it is sure to be accepted. 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. Each response may include a session description in its body but not all the session descriptions are an offer or an answer. All the session descriptions in the responses to the INVITE request must be the same but only one of them is an offer or an answer and the others are neither an offer nor an answer. Session description in an unreliable response that precedes a reliable response can be considered a "preview" of the session description that will be coming, Sawada Expires April 13, 2006 [Page 5] Internet-Draft SIP Usage of Offer/Answer Model October 2005 and hence may be treated like an offer or an answer until the actual one arrives. 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 | | After F6, UAC can send new offer in a |-------------------->| | PRACK or UPDATE request. | F8 2xx PRA | | UAS can send a new offer in an UPDATE |<--------------------| v 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) Sawada Expires April 13, 2006 [Page 6] Internet-Draft SIP Usage of Offer/Answer Model October 2005 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 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 Expires April 13, 2006 [Page 7] Internet-Draft SIP Usage of Offer/Answer Model October 2005 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 may send a new offer in a PRACK or | F8 2xx PRA | | an UPDATE 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 response. 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 is sure that the peer accepts a new offer in a PRACK request. For example, the procedure used in precondition extension Sawada Expires April 13, 2006 [Page 8] Internet-Draft SIP Usage of Offer/Answer Model October 2005 [6] is the case that a PRACK request should be used for updating the session status in the early dialog. 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. 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. Sawada Expires April 13, 2006 [Page 9] Internet-Draft SIP Usage of Offer/Answer Model October 2005 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 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, UA A knows it is an offer because there never be the case that it sends another reliable provisional response which may cause PRACK request with an offer while UA A is waiting for the answer with a PRACK request. 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 reliable provisional response if it has sent the reliable provisional response which is not yet acknowledged, this case never happens. 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, to avoid this case, UA A should not send an INVITE request without session description if it has sent the offer which has not yet received the answer to it. 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 it Sawada Expires April 13, 2006 [Page 10] Internet-Draft SIP Usage of Offer/Answer Model October 2005 sends as described in Figure 4. This case is called 'glare' case in general. Case2 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 which it has 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. Sawada Expires April 13, 2006 [Page 11] Internet-Draft SIP Usage of Offer/Answer Model October 2005 4.2. Rejection against an Offer New method should define how to reject an offer where possible. 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. Sawada Expires April 13, 2006 [Page 12] Internet-Draft SIP Usage of Offer/Answer Model October 2005 [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 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 Sawada Expires April 13, 2006 [Page 13] Internet-Draft SIP Usage of Offer/Answer Model October 2005 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 (2005). 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 Expires April 13, 2006 [Page 14]