[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 draft-ietf-sipping-sip-offeranswer

    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]
    

Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/