SIPPING Working Group James M. Polk
Internet Draft Cisco Systems
Expires: January 17th, 2006
Extending the Session Initiation Protocol
Reason Header for Preemption Events
draft-ietf-sipping-reason-header-for-preemption-03.txt
July 17th, 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 January 17th, 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 using RSVP. 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 January 17th, 2006 [Page 1]
Internet Draft SIP Reason Header for Preemption July 17th, 2005
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1 Conventions . . . . . . . . . . . . . . . . . . . . . . 3
2. Access Preemption Events . . . . . . . . . . . . . . . . . . 4
2.1 Effects of Preemption at the User Agent . . . . . . . . 5
2.2 Reason Header Requirements for
Access Preemption Events . . . . . . . . . . . . . . . 5
3. Network Preemption Events . . . . . . . . . . . . . . . . . 6
3.1 Reason Header Requirements for
Network Preemption Events . . . . . . . . . . . . . . . 8
4. Including a Hybrid Infrastructure . . . . . . . . . . . . . 9
4.1 Hybrid Infrastructure Requirements . . . . . . . . . . 9
5. Preemption Reason Header Cause Codes and Semantics . . . . . 10
5.1 Access Preemption Event Reason Code . . . . . . . . . . 10
5.1.1 Access Preemption Event Call Flow . . . . . . . . . . 11
5.2 Network Preemption Events 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 . . . . . . . . . . 13
5.4.1 Non-IP Preemption Event Call Flow . . . . . . . . . . 14
6. Security Considerations . . . . . . . . . . . . . . . . . . 14
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 15
8. Contributions . . . . . . . . . . . . . . . . . . . . . . . 17
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 17
10. Normative References . . . . . . . . . . . . . . . . . . . . 17
Author Information . . . . . . . . . . . . . . . . . . . . . 18
Intellectual Property and Copyright Statements . . . . . . . 18
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 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 January 17th, 2006 [Page 2]
Internet Draft SIP Reason Header for Preemption July 17th, 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 of RSVP 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.
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].
Polk Expires January 17th, 2006 [Page 3]
Internet Draft SIP Reason Header for Preemption July 17th, 2005
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 | |
|<======================>| |
| | INVITE (R-P:2) |
| |<------------------------|
| BYE (Reason : ? ) | |
|<-----------------------| |
| | 200 OK |
| |------------------------>|
| 200 OK | |
|----------------------->| |
| | ACK |
| |<------------------------|
| | RTP |
| |<=======================>|
| | |
Polk Expires January 17th, 2006 [Page 4]
Internet Draft SIP Reason Header for Preemption July 17th, 2005
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.
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
Polk Expires January 17th, 2006 [Page 5]
Internet Draft SIP Reason Header for Preemption July 17th, 2005
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 elements 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.
Creating another Reason value describing that a network element
preempted the session is necessary in certain domains.
The following 2 diagrams (Figures 2 and 3) illustrate the network
preemption scenario:
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).
Polk Expires January 17th, 2006 [Page 6]
Internet Draft SIP Reason Header for Preemption July 17th, 2005
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 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
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 signaling between UA3 and UA4 is also not
included.
UA1 Rtr2 UA2
| | |
| INVITE (R-P:3) |
|------------------------------------------------->|
| 200 OK |
|<-------------------------------------------------|
| ACK |
|------------------------------------------------->|
Polk Expires January 17th, 2006 [Page 7]
Internet Draft SIP Reason Header for Preemption July 17th, 2005
| RTP |
|<================================================>|
| ******************************************** |
| * -UA3 sends INV to UA4 w/ RP:2; * |
| * -Reservation set-up occurs between UA3 * |
| * and UA4 * |
| * -Router 2 must preempt 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.
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.
Polk Expires January 17th, 2006 [Page 8]
Internet Draft SIP Reason Header for Preemption July 17th, 2005
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 ---------> |--------------------->|
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.
Polk Expires January 17th, 2006 [Page 9]
Internet Draft SIP Reason Header for Preemption July 17th, 2005
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 RSVP Preemption The session preemption has been
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"
Reason: preemption ;cause=2 ;text="RSVP Preemption"
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:
Polk Expires January 17th, 2006 [Page 10]
Internet Draft SIP Reason Header for Preemption July 17th, 2005
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 |
| |<-------------------|
| | 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.
Polk Expires January 17th, 2006 [Page 11]
Internet Draft SIP Reason Header for Preemption July 17th, 2005
5.2 Network Preemption Events Reason Code
The more elaborate description of the RSVP Preemption Event
cause=2 is as follows:
A router has preempted a reservation flow and generated a ResvErr
(downstream). The (downstream) UA receiving the ResvErr 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="RSVP Preemption"
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 (R-P:3) |
|---------------------------------------------------->|
| 200 OK |
|<----------------------------------------------------|
| ACK |
|---------------------------------------------------->|
| RTP |
|<===================================================>|
| |
| *********************************************** |
| * -UA3 sends INV to UA4 w/ RP:2; * |
| * -Reservation set-up occurs between UA3 * |
| * and UA4 * |
| * -Router 2 must preempt UA1-UA2 * |
| * ********************************************* |
| |
| | ResvErr |
| |------------------------>|
| | |
| |
| BYE (Reason : Preemption ;cause=2 ; |
| text="RSVP Preemption") |
|<----------------------------------------------------|
| 200 OK |
|---------------------------------------------------->|
Polk Expires January 17th, 2006 [Page 12]
Internet Draft SIP Reason Header for Preemption July 17th, 2005
| |
Figure 6. Network Preemption with "RSVP Preemption"
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
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
Polk Expires January 17th, 2006 [Page 13]
Internet Draft SIP Reason Header for Preemption July 17th, 2005
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 | . .
|<=====================================>| . .
| | . .
| 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
Polk Expires January 17th, 2006 [Page 14]
Internet Draft SIP Reason Header for Preemption July 17th, 2005
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
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, and is not mandatory):
Reason: preemption ;cause=1 ;text="UA Preemption"
Polk Expires January 17th, 2006 [Page 15]
Internet Draft SIP Reason Header for Preemption July 17th, 2005
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, and is not mandatory):
Reason: preemption ;cause=2 ;text="RSVP Preemption"
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
string, and is not mandatory):
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, and is not mandatory):
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.
Polk Expires January 17th, 2006 [Page 16]
Internet Draft SIP Reason Header for Preemption July 17th, 2005
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 RSVP Preemption RFC XXXX [this document]
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:
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
Polk Expires January 17th, 2006 [Page 17]
Internet Draft SIP Reason Header for Preemption July 17th, 2005
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
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
Polk Expires January 17th, 2006 [Page 18]
Internet Draft SIP Reason Header for Preemption July 17th, 2005
This document and the information contained herein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Polk Expires January 17, 2006 [Page 19]
