GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc4032

Network Working Group G. Camarillo Request for Comments: 4032 Ericsson Updates: 3312 P. Kyzivat Category: Standards Track Cisco Systems

                                                            March 2005
          Update to the Session Initiation Protocol (SIP)
                      Preconditions Framework

Status of This Memo

 This document specifies an Internet standards track protocol for the
 Internet community, and requests discussion and suggestions for
 improvements.  Please refer to the current edition of the "Internet
 Official Protocol Standards" (STD 1) for the standardization state
 and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

 Copyright (C) The Internet Society (2005).

Abstract

 This document updates RFC 3312, which defines the framework for
 preconditions in SIP.  We provide guidelines for authors of new
 precondition types and describe how to use SIP preconditions in
 situations that involve session mobility.

Table of Contents

 1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
 2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  2
 3.  Defining New Precondition Types  . . . . . . . . . . . . . . .  3
     3.1.  Precondition Type Tag  . . . . . . . . . . . . . . . . .  3
     3.2.  Status Type  . . . . . . . . . . . . . . . . . . . . . .  3
     3.3.  Precondition Strength  . . . . . . . . . . . . . . . . .  3
     3.4.  Suspending and Resuming Session Establishment  . . . . .  3
 4.  Issues Related to Session Mobility . . . . . . . . . . . . . .  4
     4.1.  Update to RFC 3312 . . . . . . . . . . . . . . . . . . .  5
     4.2.  Desired Status . . . . . . . . . . . . . . . . . . . . .  7
 5.  Security Considerations  . . . . . . . . . . . . . . . . . . .  7
 6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  7
 7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  8
 8.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  8
     8.1.  Normative References . . . . . . . . . . . . . . . . . .  8

Camarillo & Kyzivat Standards Track [Page 1] RFC 4032 SIP Preconditions Framework March 2005

     8.2.  Informational References . . . . . . . . . . . . . . . .  8
 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . .  9
 Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 10

1. Introduction

 RFC 3312 [3] defines the framework for SIP [2] preconditions, which
 is a generic framework that allows SIP UAs (User Agents) to suspend
 the establishment of a session until a set of preconditions are met.
 Although only Quality of Service (QoS) preconditions have been
 defined so far, this framework supports different types of
 preconditions.  (QoS preconditions are defined by RFC 3312 as well).
 This document updates RFC 3312,  provides guidelines for authors of
 new precondition types and explains which topics they need to discuss
 when defining them.  In addition, it updates some of the procedures
 in RFC 3312 for using SIP preconditions in situations that involve
 session mobility as described below.
 RFC 3312 focuses on media sessions that do not move around.  That is,
 media is sent between the same end-points throughout the duration of
 the session.  Nevertheless, media sessions established by SIP are not
 always static.
 SIP offers mechanisms to provide session mobility, namely re-INVITEs
 and UPDATEs [5].  While existing implementations of RFC 3312 can
 probably handle session mobility, there is a need to explicitly point
 out the issues involved and make a slight update on some of the
 procedures defined there in.  With the updated procedures defined in
 this document, messages carrying precondition information become more
 explicit about the current status of the preconditions.
 Specifically, we now allow answers to downgrade current status values
 (this was disallowed by RFC 3312).  We consider moving an existing
 stream to a new location as equivalent to establishing a new stream.
 Therefore, answers moving streams to new locations set all the
 current status values in their answers to "No" and start a new
 precondition negotiation from scratch.

2. Terminology

 In this document, the key words "MUST", "MUST NOT", "REQUIRED",
 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT
 RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as
 described in BCP 14, RFC 2119 [1] and indicate requirement levels for
 compliant implementations.

Camarillo & Kyzivat Standards Track [Page 2] RFC 4032 SIP Preconditions Framework March 2005

3. Defining New Precondition Types

 Specifications defining new precondition types need to discuss the
 topics described in this section.  Having clear definitions of new
 precondition types is essential to ensure interoperability among
 different implementations.

3.1. Precondition Type Tag

 New precondition types MUST have an associated precondition type tag
 (e.g., "qos" is the tag for QoS preconditions).  Authors of new
 preconditions MUST register new precondition types and their tags
 with the IANA by following the instructions in Section 15 of RFC
 3312.

3.2. Status Type

 RFC 3312 defines two status types: end-to-end and segmented.
 Specifications defining new precondition types MUST indicate which
 status applies to the new precondition.  New preconditions can use
 only one status type or both.  For example, the QoS preconditions
 defined in RFC 3312 can use both.

3.3. Precondition Strength

 RFC 3312 defines optional and mandatory preconditions.
 Specifications defining new precondition types MUST describe whether
 or not optional preconditions are applicable, and in case they are,
 what is the expected behavior of a UA on reception of optional
 preconditions.

3.4. Suspending and Resuming Session Establishment

 Section 6 of RFC 3312 describes the behavior of UAs from the moment
 session establishment is suspended, due to a set of preconditions,
 until it is resumed when these preconditions are met.  In general,
 the called user is not alerted until the preconditions are met.
 In addition to not alerting the user, each precondition type MUST
 define any extra actions UAs should perform or refrain from
 performing when session establishment is suspended.  The behavior of
 media streams during session suspension is therefore part of the
 definition of a particular precondition type.  Some precondition

Camarillo & Kyzivat Standards Track [Page 3] RFC 4032 SIP Preconditions Framework March 2005

 types may allow media streams to send and receive packets during
 session suspension; others may not.  Consequently, the following
 paragraph from RFC 3312 only applies to QoS preconditions:
    While session establishment is suspended, user agents SHOULD not
    send any data over any media stream.  In the case of RTP, neither
    RTP nor RTCP packets are sent.
 To clarify the previous paragraph, the control messages used to
 establish connections in connection-oriented transport protocols
 (e.g., TCP SYNs) are not affected by the previous rule.  So, user
 agents follow standard rules (e.g., the SDP 'setup' attribute [7]) to
 decide when to establish the connection, regardless of QoS
 preconditions.
 New precondition types MUST also describe the behaviour of UAs on
 reception of a re-INVITE or an UPDATE with preconditions for an
 ongoing session.

4. Issues Related to Session Mobility

 Section 5 of RFC 3312 describes how to use SIP [2] preconditions with
 the offer/answer model [4].  RFC 3312 gives a set of rules that allow
 a user agent to communicate changes in the current status of the
 preconditions to the remote user agent.
 The idea is that a given user agent knows about the current status of
 some part of the preconditions (e.g., send direction of the QoS
 precondition) through local information (e.g., an RSVP RESV is
 received indicating that resource reservation was successful).  The
 UAC (User Agent Client) informs the UAS (User Agent Server) about
 changes in the current status by sending an offer to the UAS.  The
 UAS, in turn, could (if needed) send an offer to the UAC informing it
 about the status of the part of the preconditions the UAS has local
 information about.
    Note, however, that UASs do not usually send updates about the
    current status to the UAC because UASs are the ones resuming
    session establishment when all the preconditions are met.
    Therefore, rather than performing an offer/answer exchange to
    inform the UAC that all the preconditions are met, they simply
    send a 180 (Ringing) response indicating that session
    establishment has been resumed.

Camarillo & Kyzivat Standards Track [Page 4] RFC 4032 SIP Preconditions Framework March 2005

 While RFC 3312 allows updating current status information using the
 methods described above, it does not allow downgrading current status
 values in answers, as shown in the third row of Table 3 of RFC 3312.
 Figure 1 shows how performing such a downgrade in an answer would
 sometimes be needed.
                          3pcc
               A       Controller        B        C
               |            |            |        |
               |<-dialog 1->|<-dialog 2->|        |
               |            |            |        |
               | *********************** |        |
               |*         MEDIA         *|        |
               | *********************** |        |
               |            |            |        |
               |            |            |        |
               |<-dialog 1->|<------dialog 3----->|
               |            |            |        |
               | ******************************** |
               |*             MEDIA              *|
               | ******************************** |
               |            |            |        |
               |            |            |        |
               Figure 1: Session mobility using 3pcc
 The 3pcc (Third Party Call Control) [6] controller in Figure 1 has
 established a session between A and B using dialog 1 towards A and
 dialog 2 towards B.  At that point, the controller wants A to have a
 session with C instead of B.  To transfer A to C (configuration shown
 at the bottom of Figure 1), the controller sends an empty (no offer)
 re-INVITE to A.  Since A does not know that the session will be
 moved, its offer in the 200 OK states that the current status of the
 media stream in the send direction is "Yes".  After contacting C
 establishing dialog 3, the controller sends back an answer to A.
 This answer contains a new destination for the media (C) and should
 have downgraded the current status of the media stream to "No", since
 there is no reservation of resources between A and C.

4.1. Update to RFC 3312

 Below is a set of new rules that update RFC 3312 to address the
 issues above.

Camarillo & Kyzivat Standards Track [Page 5] RFC 4032 SIP Preconditions Framework March 2005

 The rule below applies to offerers moving a media stream to a new
 address:
 When a stream is being moved to a new transport address, the offerer
 MUST set all current status values about which it does not have local
 information about to "No".
 Note that for streams using segmented status (as opposed to end-to-
 end status), the fact that the address for the media stream at the
 local segment changes may or may not affect the status of
 preconditions at the remote segment.  However, moving an existing
 stream to a new location, from the preconditions point of view, is
 like establishing a new stream.  Therefore, it is appropriate to set
 all the current status values to "No" and start a new precondition
 negotiation from scratch.
 The updated table and rules below apply to an answerer that is moving
 a media stream.  The offerer was not aware of the move when it
 generated the offer.
 Table 3 of RFC 3312 needs to be updated to allow answerers to
 downgrade current status values.  The following table shows the
 result.
 Transac status table  Local status table  New values transac./local
 ____________________________________________________________________
          no                    no                    no/no
         yes                   yes                   yes/yes
         yes                    no            depends on local info
          no                   yes            depends on local info
 An answerer MUST downgrade the current status values received in the
 offer if it has local information about them or if the media stream
 is being moved to a new transport address.
 Note that for streams using segmented status, the address change at
 the answerer may or may not affect the status of the preconditions at
 the offerer's segment.  However, as stated above, moving an existing
 stream to a new location, from the preconditions point of view, is
 like establishing a new stream.  Therefore, it is appropriate to set
 all the current status values to "No" and start a new precondition
 negotiation from scratch.
 The new table below applies to an offerer that receives an answer
 that updates or downgrades its local status tables.

Camarillo & Kyzivat Standards Track [Page 6] RFC 4032 SIP Preconditions Framework March 2005

 Offerers should update their local status tables when they receive an
 answer as shown in the following table.
 Transac. status table  Local status table  New value Local Status
 _________________________________________________________________
          no                    no                    no
         yes                   yes                   yes
         yes                    no                   yes
          no                   yes                    no

4.2. Desired Status

 The desired status that a UA wants for a media stream after the
 stream is moved to a new transport address may be different than the
 desired status negotiated for the stream originally.  A UA, for
 instance, may require mandatory QoS over a low bandwidth link but be
 satisfied with optional QoS when the stream is moved to a high
 bandwidth link.
 If the new desired status is higher than the previous one (e.g.,
 optional to mandatory), the UA, following RFC 3312 procedures, may
 upgrade its desired status in an offer or in an answer.  If the new
 desired status is lower that the previous one (i.e., mandatory to
 optional), the UA, following RFC 3312 procedures as well, may
 downgrade its desired status only in an offer (i.e., not in an
 answer.)

5. Security Considerations

 An attacker adding preconditions to a session description or
 modifying existing preconditions could prevent establishment of
 sessions.  An attacker removing preconditions from a session
 description could force sessions to be established without meeting
 mandatory preconditions.
 Thus, it is strongly RECOMMENDED that integrity protection be applied
 to the SDP session descriptions.  S/MIME is the natural choice to
 provide such end-to-end integrity protection, as described in RFC
 3261 [2].

6. IANA Considerations

 The IANA registration requirements for the preconditions framework
 are defined in RFC 3312.  Any new preconditions are governed by the
 IANA Considerations there.

Camarillo & Kyzivat Standards Track [Page 7] RFC 4032 SIP Preconditions Framework March 2005

7. Acknowledgement

 Dave Oran and Allison Mankin provided useful comments on this
 document.

8. References

8.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]  Camarillo, G., Marshall, W., and J. Rosenberg, "Integration of
      Resource Management and Session Initiation Protocol (SIP)", RFC
      3312, October 2002.

8.2. Informational References

 [4]  Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
      Session Description Protocol (SDP)", RFC 3264, June 2002.
 [5]  Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE
      Method", RFC 3311, October 2002.
 [6]  Rosenberg, J., Peterson, J., Schulzrinne, H., and G. Camarillo,
      "Best Current Practices for Third Party Call Control (3pcc) in
      the Session Initiation Protocol (SIP)", BCP 85, RFC 3725, April
      2004.
 [7]  Yon, D. and Camarillo, G., "TCP-Based Media Transport in the
      Session Description Protocol (SDP)", Work In Progress, November
      2004.

Camarillo & Kyzivat Standards Track [Page 8] RFC 4032 SIP Preconditions Framework March 2005

Authors' Addresses

 Gonzalo Camarillo
 Ericsson
 Hirsalantie 11
 Jorvas  02420
 Finland
 EMail: Gonzalo.Camarillo@ericsson.com
 Paul Kyzivat
 Cisco Systems
 1414 Massachusetts Avenue, BXB500 C2-2
 Boxborough, MA  01719
 USA
 EMail: pkyzivat@cisco.com

Camarillo & Kyzivat Standards Track [Page 9] RFC 4032 SIP Preconditions Framework March 2005

Full 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.
 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.

Intellectual Property

 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.

Acknowledgement

 Funding for the RFC Editor function is currently provided by the
 Internet Society.

Camarillo & Kyzivat Standards Track [Page 10]

/data/webs/external/dokuwiki/data/pages/rfc/rfc4032.txt · Last modified: 2005/03/03 22:54 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki