Skip to main content

Extending the Session Initiation Protocol (SIP) Reason Header for Preemption Events
draft-ietf-sipping-reason-header-for-preemption-04

The information below is for an old version of the document that is already published as an RFC.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 4411.
Author James Polk
Last updated 2015-10-14 (Latest revision 2005-09-12)
RFC stream Internet Engineering Task Force (IETF)
Intended RFC status Proposed Standard
Formats
Additional resources Mailing list discussion
Stream WG state (None)
Document shepherd (None)
IESG IESG state Became RFC 4411 (Proposed Standard)
Action Holders
(None)
Consensus boilerplate Unknown
Telechat date (None)
Responsible AD Allison J. Mankin
Send notices to rohan@ekabal.com, dean.willis@softarmor.com
draft-ietf-sipping-reason-header-for-preemption-04
SIPPING Working Group                                     James M. Polk
Internet Draft                                            Cisco Systems
Expires: March 12th, 2006

              Extending the Session Initiation Protocol 
                 Reason Header for Preemption Events
         draft-ietf-sipping-reason-header-for-preemption-04.txt

                            Sept 12th, 2005 

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.

   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 March 12th, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract 

   This document proposes an IANA Registration extension to the Session
   Initiation Protocol (SIP) Reason Header to include in a BYE Method 
   Request as a result of a session preemption event, either at a user 
   agent (UA), or somewhere in the network involving a reservation-
   based protocol such as RSVP or NSIS.  This document does not attempt 
   to address routers failing in the packet path; but a deliberate 
   event of tearing down a flow between UAs, and informing the 
   terminated UA(s) with an indication of what occurred.

Polk                    Expires March 12th, 2006               [Page 1]
Internet Draft      SIP Reason Header for Preemption    Sept 12th, 2005

Table of Contents 
     
   1.   Introduction . . . . . . . . . . . . . . . . . . . . . . . .  2
        1.1 Conventions  . . . . . . . . . . . . . . . . . . . . . .  4
   2.   Access Preemption Events . . . . . . . . . . . . . . . . . .  4
        2.1  Effects of Preemption at the User Agent . . . . . . . .  5
        2.2  Reason Header Requirements for 
             Access Preemption Events  . . . . . . . . . . . . . . .  6
   3.   Network Preemption Events  . . . . . . . . . . . . . . . . .  6
        3.1  Reason Header Requirements for 
             Network Preemption Events . . . . . . . . . . . . . . .  9
   4.   Including a Hybrid Infrastructure  . . . . . . . . . . . . .  9
        4.1  Hybrid Infrastructure Requirements  . . . . . . . . . . 10
   5.   Preemption Reason Header Cause Codes and Semantics . . . . . 10
        5.1  Access Preemption Event Reason Code . . . . . . . . . . 11
        5.1.1 Access Preemption Event Call Flow  . . . . . . . . . . 11
        5.2  Network Preemption Event Reason Code  . . . . . . . . . 12
        5.2.1 Network Preemption Event Call Flow . . . . . . . . . . 12
        5.3  Generic Preemption Event Reason Code  . . . . . . . . . 13
        5.4  Non-IP Preemption Event Reason Code . . . . . . . . . . 14
        5.4.1 Non-IP Preemption Event Call Flow  . . . . . . . . . . 14
   6.   Security Considerations  . . . . . . . . . . . . . . . . . . 15
   7.   IANA Considerations  . . . . . . . . . . . . . . . . . . . . 15
   8.   Contributions  . . . . . . . . . . . . . . . . . . . . . . . 17
   9.   Acknowledgements   . . . . . . . . . . . . . . . . . . . . . 18
   10.  References . . . . . . . . . . . . . . . . . . . . . . . . . 18
        Author Information . . . . . . . . . . . . . . . . . . . . . 19
        Intellectual Property and Copyright Statements . . . . . . . 19

1.  Introduction

   With the introduction of the SIP Resource-Priority (R-P) header [4],
   there became the possibility of sessions being torn down for 
   (scarce) resource reasons; meaning there weren't enough resources 
   for a particular session to continue.  Certain domains will 
   implement this mechanism where resources may become constrained 
   either at the user agent (UA), or at congested router interfaces 
   where more important sessions are to be completed at the expense of 
   less important sessions.  Which sessions are more or less important 
   than others will not be discussed here.  What is proposed here is 
   extending SIP to synchronize SIP elements as to why a preemption 
   event occurred and which type of preemption event occurred, as 
   viewed by the element that performed the preemption of a session. 

   The SIP Reason Header is an application layer feedback mechanism to 
   synchronize SIP elements of events; the particular event explained 
   here deals with preemption of a session.  Q.850 [5] provides an 
   indication for preemption (cause=8) and for preemption "circuit 
   reserved for reuse" (cause=9).  Q.850 Cause=9 does not apply to IP 
   because IP has no concept of circuits. Some domains wish to 
   differentiate appropriate IP reasons for preemption of sessions and 

Polk                    Expires March 12th, 2006               [Page 2]
Internet Draft      SIP Reason Header for Preemption    Sept 12th, 2005

   topologically where the preemption event occurred.  No other means 
   exists today to give this feedback as to why a session was torn down
   for preemption grounds.

   In the event that a session is terminated for a specific reason that
   can (or should) be shared with SIP Servers and UAs sharing dialog, 
   the Reason Header [1] was created to be included in the BYE Request 
   This was not the only Method for this new Header; [1] also discusses
   the CANCEL Method usage. 

   This document will define two use-cases in which new preemption 
   Reason values are necessary:

      Access Preemption Event - this is when a UA receives a new SIP 
             session request message with a valid R-P value that is 
             higher than the one associated with the currently active 
             session at that UA.  The UA must discontinue the existing 
             session in order to accept the new one (based on local 
             policy of some domains).

      Network Preemption Event - this is when a network element - such 
             as a router - reaches capacity on a particular interface 
             and has the ability to statefully choose which session(s) 
             will remain active when a new session/reservation is 
             signaled for under the parameters outlined in SIP 
             Preconditions in [3] that would otherwise overload that 
             interface  (perhaps adversely affecting all sessions).  In
             this case, the router must terminate one or more 
             reservations of lower priority in order to allow this 
             higher priority reservation access to the requested amount
             of bandwidth  (based on local policy of some domains).

   This document will cover the semantics for these two cases, and 
   request IANA registration of the new protocol value "Preemption" for
   the Reason Header field with 4 cause values for the above preemption
   conditions.  Additionally, this document will create a new IANA 
   Registry for reason-text strings that are not currently defined 
   through existing SIP Response codes or Q.850 cause codes.  This new 
   Registry will be useful for future protocols used by the SIP Reason 
   header. 

   This document will emphasize an existing SIP RFC [3] as the starting
   point for network preemption events.  RFC 3312 set rules surrounding
   SIP interaction using a reservation protocol for QoS preconditions, 
   using RSVP as the example protocol.  That effort did not preclude 
   other preconditions or future protocol work from becoming a means of
   preconditions.  NSIS is a new reservation protocol effort that 
   specifies a preemption operation similar to RSVP's ResvErr message 
   involving the NSIS NOTIFY message in [8] with a Transient error code
   0x04000005 (Resources Pre-empted).  

Polk                    Expires March 12th, 2006               [Page 3]
Internet Draft      SIP Reason Header for Preemption    Sept 12th, 2005

   To be clear, it should be noted that SIP itself does not cause RSVP 
   or NSIS reservation signaling to start or end.  That operation is 
   part of a separate API within each UA.

1.1  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 [6].

2.  Access Preemption Events 

   As mentioned previously, Access Preemption Events (APE) occur at 
   the user agent.  It does not matter which UA in a unicast or 
   multicast session this happens to (the UAC or UAS of a session).  If
   local policy dictates in a particular domain, rules regarding the 
   functionality of a UA, there must be a means by which that UA (not 
   the user) informs the other UA(s) why a session was just torn down 
   prematurely.  The appropriate mechanism is to utilize the BYE 
   Method.  The user of the other far side UA will not understand why 
   that session "just went away" without there being a means of 
   informing the UA what occurred (if this event was purposeful). 
   Through this type of indication to the preempted UA, it can indicate
   to the user of that device appropriately. 

   The rules within a domain surrounding informing of UA can be 
   different than the rules of informing the user. Local policy should 
   determine if the user should be informed of the specific reason. 
   This indication in SIP will provide a means for the UA to react in a
   locally determined way if appropriate (play a certain tone or tone 
   sequence, point towards a special announcement uri, causes the UA's 
   visual display to do something, etc).

   The following diagram (Figure 1) illustrates the scenario here.  UA1
   invites UA2 to a session with the Resource Priority level of 3 
   (levels 1 and 2 are higher is this domain, and the namespace element
   is not necessary for this discussion).  

                                                             
   UA1                      UA2                       UA3    
    |                        |                         |     
    |      INVITE (R-P:3)    |                         |     
    |----------------------->|                         |     
    |         200 OK         |                         |     
    |<-----------------------|                         |     
    |          ACK           |                         |     
    |----------------------->|                         |     
    |          RTP           |                         |     
    |<======================>|                         |     
  

Polk                    Expires March 12th, 2006               [Page 4]
Internet Draft      SIP Reason Header for Preemption    Sept 12th, 2005

    |                        |      INVITE (R-P:2)     |     
    |                        |<------------------------|     
    |    BYE (Reason : ? )   |                         |     
    |<-----------------------|                         |     
    |                        |         200 OK          |     
    |                        |------------------------>|     
    |         200 OK         |                         |     
    |----------------------->|                         |     
    |                        |          ACK            |     
    |                        |<------------------------|     
    |                        |          RTP            |     
    |                        |<=======================>|     
    |                        |                         |     
                                                             
       Figure 1. Access Preemption with obscure Reason       
                                                             
   After the session between UA1 and UA2 is established, UA3 invites 
   UA2 to a new session with an R-P of 2 (a higher priority than the 
   current session between UA1 and UA2).  Local policy within this 
   domain dictates that UA2 must preempt all existing calls of lower 
   priority in order to accept a higher priority call.

   What Reason value could be inserted above to mean "preemption" at a 
   UA?  There are several choices: 410 "Gone", 480 "Temporarily 
   Unavailable", 486 "Busy Here", and 503 "Service Unavailable".  The 
   use of any here is questionable because the session is already 
   established.  It is further complicated if there needs to be a 
   difference in the Reason value for an Access versus a Network 
   Preemption Event (which is a requirement here).  The limits of Q.850
   [5] have been stated previously in this document.  

   It should be possible to configure UAs receiving a preemption 
   indication to indicate to the user no particular type of preemption 
   occurred.  There are some domains that might prefer their users to 
   remain unaware of the specifics of network behavior.  This should 
   not ever prevent a known preemption indication from being sent in a 
   BYE from a UA.

2.1  Effects of Preemption at the User Agent

   If 2 UAs are in a session, and one UA must preempt that session to 
   accept another session, a BYE Method message is the appropriate 
   mechanism to perform this task.  However, taking this a step 
   further, if a UA is the common point of a 3-way (or more) adhoc 
   conference participants and must preempt all sessions in that 
   conference due to a higher priority session request received (that 
   this UA must accept), then a BYE message must be sent to all UAs in 
   that adhoc conference.

Polk                    Expires March 12th, 2006               [Page 5]
Internet Draft      SIP Reason Header for Preemption    Sept 12th, 2005

2.2  Reason Header Requirements for Access Preemption Events

   The following is a list of requirements for adding an appropriate 
   Reason value for an Access Preemption Event (APE) as described above
   and shown in Figure 1:

      APE_REQ#1 - create a means by which one UA can inform another UA 
                  (within the same active session) that the active 
                  session between the two devices is being purposely 
                  preempted at one UA for a higher priority session 
                  request from another UA.

      APE_REQ#2 - create a means by which all relevant SIP elements can
                  be informed of this Access Preemption Event to a 
                  specific session.

   For example: perhaps SIP Servers that have incorporated a Record-
   Route header into that session set-up need to be informed of this 
   occurrence.

      APE_REQ#3 - create a means of informing all participants in a 
                  adhoc conference that the primary UA (the mixer) has 
                  preempted the conference by accepting a higher 
                  priority session request.

      APE_REQ#4 - create a separate indication for the access 
                  preemption event than one used for a Network 
                  Preemption Event (described in the next section) in 
                  the session BYE message.

      APE_REQ#5 - create a means to generate a specific indication of a 
                  preemption event at the user agent to inform all 
                  relevant SIP entities, yet have the ability to 
                  generalize this indication (based on local policy) to 
                  the receiving UA such that this UA cannot display 
                  more information than the domain wants the user to 
                  see.

3.  Network Preemption Events

   Network Preemption Events (NPE) are those instances in which a 
   intermediate router between SIP user agents preempts one or more 
   sessions at one of its interfaces to place a higher priority 
   session through that interface. Within RSVP, there exists a means to
   execute this functionality in [7]: ResvErr messages - which travel 
   downstream towards appropriate receivers.  The ResvErr message has 
   the ability to carry within it a code why a reservation is being 
   torn down.  The ResvErr does not travel upstream to the other UA.  
   This document here proposes a SIP message be generated to 
   synchronize all relevant SIP elements to this preemption event, 
   including the upstream UA.  Creating another Reason value describing

Polk                    Expires March 12th, 2006               [Page 6]
Internet Draft      SIP Reason Header for Preemption    Sept 12th, 2005

   that a network element preempted the session is necessary in certain
   domains. 

   Two diagrams (Figures 2 and 3) illustrate a network preemption
   scenario with RSVP.  NSIS, not shown in examples here, can be 
   imagined here from [8] with a NOTIFY error message indicating a 
   reservation has been preempted with the Transient ERROR_SPEC 
   0x04000005.  SIP behavior will be identical using either reservation
   protocol.  

   UA1 invites UA2 to a session with the Resource Priority level of 3 
   (levels 1 and 2 are higher is this domain) and is accepted.  This 
   SIP signaling translated the Resource Priority value to an 
   appropriate RSVP priority level for that flow.  The link between 
   Router 1 and Router 2 became saturated with this session reservation
   between UA1 and UA2 (in this example).  

          UA1                                  UA2           
             \                                /              
              \                              /               
               +--------+          +--------+                
               |        |          |        |                
               | RTR1   |          |  RTR2  |                
               |       Int7-------Int5      |                
               |        |          |        |                
               +--------+          +--------+                
              /                              \               
             /                                \              
          UA3                                  UA4           
                                                             
             Figure 2. Network Diagram Scenario A            

   After the session between UA1 and UA2 is established, UA3 invites 
   UA4 to a new session with an Resource Priority level of 2 (a higher 
   priority than the current reservation between UA1 and UA2).  Again, 
   the priority value within the Resource-Priority header of this 
   INVITE is translated into an appropriate RSVP priority (that is also
   higher in relative priority to the UA1_UA2 session/RSVP flow).  When
   this second (higher priority session) is signaled, one Path message 
   goes from UA3 to UA4, resulting in the RESV message going from UA4 
   back to UA3.  Because this link between the two routers is at 
   capacity (at Int7 in Figure 5), Router 1 will (in this example) make
   the decision, or will communicate with another network entity that 
   will make the decision to preempt lower priority BW to ensure this 
   higher priority session reservation is completed.  A ResvErr message
   is sent to UA2.  The result is that UA2 will know that there has 
   been a preemption event in a router (because the ResvErr message has
   a error code within it stating "preemption"), UA1 at this point will
   not know anything of this preemption.  If there are any SIP Proxies 
   in between UAs 1 & 2 (perhaps that inserted a Record-Route Header), 
   each will need to be informed also as to why this reservation was 

Polk                    Expires March 12th, 2006               [Page 7]
Internet Draft      SIP Reason Header for Preemption    Sept 12th, 2005

   torn down. 

   Figure 3 shows the call flow with Router 2 from Figure 2 included at
   the RSVP layer sending the ResvErr message.  A complete call flow 
   including all UAs and Routers is not shown here for diagram 
   complexity reasons.  The complete signaling between UA3 and UA4 is 
   also not included.

   UA1                      Rtr2                      UA2    
    |                        |                         |     
    |         INVITE with QoS Preconditions (R-P:3)    |     
    |------------------------------------------------->|     
    |    ********************************************  |     
    |    *  - QoS Preconditions established UA1-UA2 *  |     
    |    *  - SIP signaling continues...            *  |     
    |    ********************************************  |     
    |         200 OK                                   |     
    |<-------------------------------------------------|     
    |          ACK                                     |     
    |------------------------------------------------->|     
    |          RTP                                     |     
    |<================================================>|     
    |    ********************************************  |     
    |    *  -UA3 sends INV with QoS Preconditions   *  |     
    |    *     to UA4 w/ RP:2;                      *  |     
    |    *  -Reservation set-up occurs between UA3  *  |     
    |    *     and UA4                              *  |     
    |    *  -Router 2 in Figure 2 must preempt      *  |     
    |    *     reservation between UA1 & UA2        *  |     
    |    * ******************************************  |     
    |                                                  |     
    |                        |     ResvErr             |     
    |                        |------------------------>|     
    |                        |                         |     
    |                                                  |     
    |                          BYE (Reason : ? )       |     
    |<-------------------------------------------------|     
    |                              200 OK              |     
    |------------------------------------------------->|     
    |                                                  |     
                                                             
       Figure 3. Network Preemption with obscure Reason      

   What Reason value could be inserted above to mean "preemption at a 
   router interface"?  There are several choices: 410 "Gone", 480 
   "Temporarily Unavailable", 486 "Busy Here", and 503 "Service 
   Unavailable".  The use of any here is questionable because the 
   session is already established.  It is further complicated if there 
   needs to be a difference in the Reason value for an Access versus a 
   Network Preemption Event.  The limits of Q.850 [5] have already been
   stated previously showing there is nothing in that spec to indicate 
   a problem in an IP network.  

Polk                    Expires March 12th, 2006               [Page 8]
Internet Draft      SIP Reason Header for Preemption    Sept 12th, 2005

   To generically state that all preemptions are equal is possible, but
   will not provide adequate information.  Therefore, another Reason 
   Header value is necessary to differentiate the APE from the NPE.

3.1  Reason Header Requirements for Network Preemption Events

   The following are the requirements for the appropriate SIP signaling
   in reaction to a Network Preemption Event (NPE):

      NPE_REQ#1 - create a means of informing the far end UA that a 
                  Network Preemption Event has occurred in an 
                  intermediate router.

      NPE_REQ#2 - create a means by which all relevant SIP elements can
                  be informed of a Network Preemption Event to a 
                  specific session.

   For example: perhaps SIP Servers that have incorporated a Record-
   Route header into that session set-up.

      NPE_REQ#3 - create a means of informing all participants in a 
                  adhoc conference that the primary UA (the mixer) has 
                  been preempted by a Network Preemption Event.

      NPE_REQ#4 - create a separate description of the Network 
                  Preemption Event relative to an Access Preemption 
                  Event in SIP.

4.  Including a Hybrid Infrastructure

   If it is the case that User 1 is in a non-IP portion of 
   infrastructure (using a TDM phone) in a session with a UA through a 
   SIP gateway, and the TDM portion had the ability to preempt the 
   session and indicate to the SIP gateway when it did such a 
   preemption, the SIP GW would need to be able to convey this 
   preemption event into the SIP portion of this session just as if 
   user 1 were a UA in the session.  Below is a diagram of this:

    **************************                             
    *       TDM network      *                             
    *                    +---------+                       
    *   User 1           |         |                       
    *     O   ==========>| SIP GW1 |================> UA2  
    *    /|\  ^          |         |                   |   
    *    / \  |          +---------+                   |   
    *         |              *                         |   
    **********|***************  |                      |   
              |                 |   Preemption         |   
         Preemption  ---------> |--------------------->|   

Polk                    Expires March 12th, 2006               [Page 9]
Internet Draft      SIP Reason Header for Preemption    Sept 12th, 2005

            Event                   Indication

              Figure 4. TDM/IP Preemption Event

4.1 Hybrid Infrastructure Requirements

   The following are the requirements unique to the topology involving 
   both IP infrastructure and TDM (or non-IP) infrastructure.

         HYB_REQ#1 - create a means of informing the far end UA in a 
                     dialog through a SIP gateway with a Non-IP phone 
                     that the TDM portion of the session indicated to 
                     the SIP gateway that a preemption event terminated
                     the session.

         HYB_REQ#2 - create a means of identifying this preemption 
                     event uniquely with respect to an access 
                     preemption and network preemption event.
 

5.  Preemption Reason Header Cause Codes and Semantics

   This document defines the following new protocol value for the 
   protocol field of the Reason header field in RFC 3326 [1]:

      Preemption: The cause parameter contains a preemption cause code

   We define the following preemption cause codes:

   Value    Default Text        Description
     1      UA Preemption       The session has been preempted by a UA

     2      Reserved Resources  The session preemption has been 
            Preempted           initiated within the network via a 
                                purposeful RSVP preemption occurrence, 
                                and not a link error 

     3      Generic Preemption  This is a limited use preemption 
                                indication to be used on the final leg 
                                to the preempted UA to generalize the 
                                event 

     4      Non-IP Preemption   The session preemption has occurred in 
                                a non-IP portion of the infrastructure 
                                and this is the Reason cause code given 
                                by the SIP Gateway

   Example syntax is as follows for each of the above preemption types:

      Reason: preemption ;cause=1 ;text="UA Preemption"

Polk                    Expires March 12th, 2006              [Page 10]
Internet Draft      SIP Reason Header for Preemption    Sept 12th, 2005

      Reason: preemption ;cause=2 ;text="Reserved Resources Preempted"
      Reason: preemption ;cause=3 ;text="Generic Preemption"
      Reason: preemption ;cause=4 ;text="Non-IP Preemption"

   Sections 5.1, 5.2, 5.3 and 5.4 provide uses cases and extended 
   definitions for the above four cause codes with message flow 
   diagrams.

5.1 Access Preemption Event Reason Code

   The more elaborate description of the Access Preemption Event 
   cause=1 is as follows:

      A user agent in a session has purposely preempted a session and 
      is informing the far end user agent, or user agents (if part of a
      conference), and SIP Proxies (if stateful of the session's 
      transactions)

   An example usage of this header value would be:

      Reason: preemption ;cause=1 ;text="UA Preemption"

5.1.1 Access Preemption Event Call Flow

   The following diagram (Figure 5) replicates the call flow from 
   Figure 1 - but with an appropriate Reason value indication that was 
   proposed in section 4.1 above:

   UA1                                 UA2                  UA3 
    |                                   |                    |  
    |         INVITE (R-P:3)            |                    |  
    |---------------------------------->|                    |  
    |           200 OK                  |                    |  
    |<----------------------------------|                    |  
    |            ACK                    |                    |  
    |---------------------------------->|                    |  
    |            RTP                    |                    |  
    |<=================================>|                    |  
    |                                   |    INVITE (R-P:2)  |  
    |                                   |<-------------------|  
    |    BYE (Reason: Preemption ;      |                    |  
    |    cause=1 ;text="UA Preemption") |                    |  
    |<----------------------------------|                    |  
    |                                   |        200 OK      |  
    |                                   |------------------->|  
    |         200 OK                    |                    |  
    |---------------------------------->|                    |  
    |                                   |        ACK         |  
    |                                   |<-------------------|  

Polk                    Expires March 12th, 2006              [Page 11]
Internet Draft      SIP Reason Header for Preemption    Sept 12th, 2005

    |                                   |        RTP         |  
    |                                   |<==================>|  
    |                                   |                    |  
                                                             
     Figure 5. Access Preemption with Reason: UA Preemption 

   UA1 invites UA2 to a session with the Resource Priority level of 3 
   (levels 1 and 2 are higher is this domain).  After the session 
   between UA1 and UA2 is established, UA3 invites UA2 to a new session
   with an R-P of 2 (a higher priority than the current session to 
   UA1).  Local policy within this domain dictates that UA2 must 
   preempt all existing calls of lower priority in order to accept a 
   higher priority call. 

   UA2 sends a BYE Request message with a Reason header with a value: 
   UA Preemption.  This will inform the far end UA (UA1), and all 
   relevant SIP elements (for example: SIP Proxies).  The cause code is
   unique to what is proposed in the RSVP Preemption Event for 
   differentiation purposes.

5.2 Network Preemption Events Reason Code

   The more elaborate description of the Reserved Resources Preempted 
   Event cause=2 is as follows:

      A router has preempted a reservation flow and generated a 
      reservation error message, a ResvErr traveling downstream in 
      RSVP, a NOTIFY in NSIS.  The UA receiving the preemption error 
      message generates a BYE request towards the far side UA with a 
      Reason Header with this value indicating that somewhere in 
      between two or more UAs, a router has administratively preempted 
      this session.

   An example usage of this header value would be:

     Reason: Preemption :cause=2 ;text="Reserved Resources Preempted"

5.2.1 Network Preemption Event Call Flow

   The following diagram (Figure 6) replicates the call flow from 
   Figure 5 - but with an appropriate Reason value indication that was 
   proposed in section 4.2 above. 

                                                             
   UA1                         Rtr2                      UA2    
    |                           |                         |     
    |         INVITE with QoS Preconditions (R-P:3)       |     
    |---------------------------------------------------->|     
    |    ********************************************     |     
    |    *  - QoS Preconditions established UA1-UA2 *     |     

Polk                    Expires March 12th, 2006              [Page 12]
Internet Draft      SIP Reason Header for Preemption    Sept 12th, 2005

    |    *  - SIP signaling continues...              *   |     
    |    ********************************************     |     
    |         200 OK                                      |     
    |<----------------------------------------------------|     
    |          ACK                                        |     
    |---------------------------------------------------->|     
    |          RTP                                        |     
    |<===================================================>|     
    |    ********************************************     |     
    |    *  -UA3 sends INV with QoS Preconditions   *     |     
    |    *     to UA4 w/ RP:2;                      *     |     
    |    *  -Reservation set-up occurs between UA3  *     |     
    |    *     and UA4                              *     |     
    |    *  -Router 2 in Figure 2 must preempt      *     |     
    |    *     reservation between UA1 & UA2        *     |     
    |    * *********************************************  |     
    |                                                     |     
    |                           |     ResvErr             |     
    |                           |------------------------>|     
    |                           |                         |     
    |                                                     |     
    |           BYE (Reason : Preemption ;cause=2 ;       |     
    |                text="Reserved Resources Preempted") |     
    |<----------------------------------------------------|     
    |                         200 OK                      |     
    |---------------------------------------------------->|     
    |                                                     |     
                                                                
   Figure 6. Network Preemption with "Reserved Resources Preempted"

   Above is the call flow with Router 2 from Figure 2 included at the 
   RSVP layer sending the Resv messages.  A complete call flow 
   including all UAs and Routers is not here for diagram complexity 
   reasons.  The signaling between UA3 and UA4 is also not included.

   Upon receipt of the ResvErr message with the preemption error code, 
   UA2 can now appropriately inform UA1 why this event occurred.  This 
   BYE message will also inform all relevant SIP elements, 
   synchronizing them.  The cause value is unique to that proposed in 
   section 4.1 for Access Preemption Events for differentiation 
   purposes.

5.3 Generic Preemption Event Reason Code

   The more elaborate description of the Generic Preemption Event 
   cause=3 is as follows:

      This cause code is for infrastructures that do not wish to 
      provide the preempted UA a more precise reason that just 
      "preemption".  It is possible that UAs will have code that will 
      indicate the type of preemption event that is contained in the 

Polk                    Expires March 12th, 2006              [Page 13]
Internet Draft      SIP Reason Header for Preemption    Sept 12th, 2005

      Reason header, and certain domains have expressed this as not 
      being optimal, and wanted to generalize the indication.  This 
      MUST NOT be the initial indication within these domains, as 
      valuable traffic analysis and other NM applications will be 
      generalized as well.  If this cause value is to be implemented, 
      it SHOULD only be done at the final SIP Proxy in such a way that 
      the cause value indicating which type of preemption event 
      actually occurred is changed to this generalized preemption 
      indication to be received by the preempted UA.

   An example usage of this header value would be:

      Reason: preemption ;cause=3 ;text="Generic Preemption"

5.4 Non-IP Preemption Event Reason Code

   The more elaborate description of the Non-IP Preemption Event 
   cause=4 is as follows:

      A session exists in a hybrid IP/Non-IP infrastructure and the 
      preemption event occurs in the Non-IP portion, and was indicated 
      by that portion that this call termination was due to preemption.
      This is the indication that would be generated by a SIP Gateway 
      towards the SIP UA that is being preempted, traversing whichever 
      SIP Proxies are involved in session signaling (a question of 
      server state).   

   An example usage of this header value would be:

      Reason: preemption ;cause=4 ;text="Non-IP Preemption"

5.4.1 Non-IP Preemption Event Call Flow

   The following is a simple call flow diagram of the Non-IP 
   preemption event.

                                                        ............
   UA1                                   SIP GW1        .  User3   . 
    |                                       |           .          . 
    |         INVITE (R-P:1)                |           .          . 
    |-------------------------------------->|           .  Non-IP  . 
    |           200 OK                      |           .          . 
    |<--------------------------------------|           .  Network . 
    |            ACK                        |           .          . 
    |-------------------------------------->|           .          . 
    |            RTP                        |           .          . 
    |<=====================================>|           .          . 

Polk                    Expires March 12th, 2006              [Page 14]
Internet Draft      SIP Reason Header for Preemption    Sept 12th, 2005

    |                                       |           .          . 
    |    BYE (Reason: Preemption ;          |<==Preemption Indication 
    |    cause=4 ;text="Non-IP Preemption") |           .          . 
    |<--------------------------------------|           .          . 
    |                                       |           ............
                                                                   
               Figure 7. Non-IP Preemption Flow                     

   In this case, UA1 signals User3 to a session.  Once established, 
   there is a preemption event in the Non-IP portion of the 
   session/call, and the TDM portion has the ability to inform the SIP 
   GW of this type of event.  This Non-IP signal can be translated into
   SIP signaling (into the BYE session termination message).  Within 
   this BYE there should be a Reason header indicating such an event 
   to synchronize all SIP elements.

6.  Security Considerations

   Eavesdropping on this header field should not prevent proper 
   operation of the SIP protocol, although some domains utilizing this 
   mechanism for notifying and synchronizing SIP elements will likely 
   want the integrity to be assured.  It is therefore RECOMMENDED to 
   apply integrity protection when using this header to prevent 
   unwanted changes to the field and snooping of the messages. The 
   accepted choices to provide integrity protection in SIP are TLS and 
   S/MIME.

7.  IANA Considerations

   This document adds to one existing IANA Registry and creates one new
   Registry.  The existing IANA Registry for the SIP Reason Header is 
   as follows:

   Protocol Value   Protocol Cause            Reference
   --------------   --------------            ---------
   SIP              Status code               RFC 3261
   Q.850            Cause value in decimal    ITU-T Q.850

   This document adds to that Registry with the following entry 
   (including the '*' comment):

   Protocol Value   Protocol Cause            Reference
   --------------   --------------            ---------
   Preemption       Cause value in decimal*   RFC XXXX  [this document]

   * see the separate "Preemption" Registry for default reason-text 
     strings

   The cause values created by the Preemption Protocol namespace in 
   this document are defined in section 7.1 below.  Each cause value 

Polk                    Expires March 12th, 2006              [Page 15]
Internet Draft      SIP Reason Header for Preemption    Sept 12th, 2005

   has a Reason-text string as a general description of what the cause
   value is for.  This is shown for the existing Reason header in 
   section 2 of RFC 3326.  Before this document, the Reason-text was 
   taken from the SIP Response code string from all SIP Response codes,
   or the default description from Q.850 cause codes.  There currently 
   is no place to register new reason-text strings other than from 
   those two sources.  Because this document defines a new Reason 
   header protocol namespace, a new IANA Registry is created in section
   7.2 below just for this and future Reason header protocol namespaces
   (other than SIP Response codes or Q.850 cause values) to register 
   their respective general descriptive text string.  These text 
   strings are non-binding, and merely the default for human 
   understanding, but deemed important enough to have their own 
   Registry.

7.1 "Preemption" Namespace Registry

   RFC [XXXX} (this document) creates the new SIP "Reason Header" [1] 
   protocol namespace: "Preemption", with 4 defined cause codes:  

      In instances where this namespace is used to indicate preemption 
      at a UA, the following syntax shall be used (the reason-text is a
      default string, it is not mandatory, and may be different):

         Reason: preemption ;cause=1 ;text="UA Preemption"

         Section 5.1 of this document describes in detail the semantics
         of this cause code.

         The default text above is part of a new IANA Registry for 
         default text strings for any new protocol namespace cause 
         code.  See section 7.2 below for the details.

      In instances where this namespace is used to indicate preemption 
      based on receipt of an RSVP ResvErr message at a SIP UA, the 
      following syntax shall be used (the reason-text is a default 
      string, it is not mandatory, and may be different):

      Reason: preemption ;cause=2 ;text="Reserved Resources Preempted"

         Section 5.2 of this document describes in detail the semantics
         of this cause code.

         The default text above is part of a new IANA Registry for 
         default text strings for any new protocol namespace cause 
         code.  See section 7.2 below for the details.

      In instances where this namespace is used to indicate a 
      generalized preemption event to the destination UA from a Proxy 
      that modifies the Reason value only during this last SIP hop 
      shall use the following syntax (the reason-text is a default 

Polk                    Expires March 12th, 2006              [Page 16]
Internet Draft      SIP Reason Header for Preemption    Sept 12th, 2005

      string, it is not mandatory, and may be different):

         Reason: preemption ;cause=3 ;text="Generic Preemption"

         Section 5.3 of this document describes in detail the semantics
         of this cause code.

         The default text above is part of a new IANA Registry for 
         default text strings for any new protocol namespace cause 
         code.  See section 7.2 below for the details.

      In instances where this namespace is used to indicate preemption 
      from a Non-IP portion of a call leg, a SIP Gateway shall use the 
      following syntax to inform the SIP infrastructure of this event 
      with (the reason-text is a default string, it is not mandatory, 
      and may be different):

         Reason: preemption ;cause=4 ;text=" Non-IP Preemption"

         Section 5.4 of this document describes in detail the semantics
         of this cause code.

         The default text above is part of a new IANA Registry for 
         default text strings for any new protocol namespace cause 
         code.  See section 7.2 below for the details.

   Additional definitions of the preemption namespace and its cause 
   codes MUST be defined in Standards Track documents.

7.2 Default Reason-Text IANA Registry for the SIP Reason Header

   Below is the creation of a new IANA Registry for SIP Reason Header 
   reason-text strings, associated with their respective protocol type 
   and Reason-param cause values.  Per RFC 3326, the Reason-text string
   is a quoted default string with only human understandability meant. 
   These strings can be changed by local policy.

                Reason-
   Protocol     param      Reason-Text         Reference
   --------     -------    ------------        ---------
   Preemption   Cause=1    UA Preemption       RFC XXXX [this document]
   Preemption   Cause=2    Reserved Resources  RFC XXXX [this document]
                             Preempted     
   Preemption   Cause=3    Generic Preemption  RFC XXXX [this document]
   Preemption   Cause=4    Non-IP Preemption   RFC XXXX [this document]

8.  Contributions

   The following individuals contributed to this effort:

Polk                    Expires March 12th, 2006              [Page 17]
Internet Draft      SIP Reason Header for Preemption    Sept 12th, 2005

      Subhasri Dhesikan
      Gonzalo Camarillo
      Dave Oran

   The author thanks these individuals greatly for their aid in this 
   effort.

9.  Acknowledgements

   To Haluk Keskiner for providing a valued sanity check. To Dean 
   Willis, Rohan Mahy and Allison Mankin for their belief in and 
   backing of this effort.  To Adam Roach and Arun Kumar for helpful 
   comments to this document.

   Thanks to Mike Pierce for helpful comments and catching a flaw in 
   this spec late in the process (before it was too late).

10. Normative References

 [1] H. Schulzrinne, D. Oran, G. Camarillo, "The Reason Header Field 
     for the Session Initiation Protocol (SIP)", RFC 3326 Reason 
     Header, December 2002

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

 [4] H. Schulzrinne, J. Polk, "Communications Resource-Priority Header 
     in SIP", Internet Draft, work in progress, May 2005

 [5] ITU-T Recommendation Q.850 (1993)

 [6] Bradner, S., "Key words for use in RFCs to indicate requirement
     levels," BCP 14, RFC 2119, March 1997.

 [7] R. Braden, Ed., L. Zhang, S. Berson, S. Herzog, S. Jamin, 
     "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional 
     Specification", RFC 2205, September 1997

10.1 Informative Reference

 [8] J. Manner, G. Karagiannis, A. McDonald, S. Van den Bosch, " NSLP 
     for Quality-of-Service signalling", draft-ietf-nsis-qos-nslp, Sept
     2005, "work in progress" 

Polk                    Expires March 12th, 2006              [Page 18]
Internet Draft      SIP Reason Header for Preemption    Sept 12th, 2005

   Author Information

   James M. Polk
   Cisco Systems
   2200 East President George Bush Turnpike
   Richardson, Texas 75082 USA

   jmpolk@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 (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.

Polk                    Expires March 12th, 2006              [Page 19]
Internet Draft      SIP Reason Header for Preemption    Sept 12th, 2005

Acknowledgment

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

Polk                    Expires March 12th, 2006              [Page 20]