| |
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 of these here is questionable because
the session is already established. It is further complicated if
there needs to be a difference between the Reason value for an Access
Preemption Event 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 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 have incorporated a Record-Route
header into that session set up.
NPE_REQ#3 - create a means of informing all participants in an ad
hoc 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 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 if 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.
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 for the above preemption types are as follows:
Reason: preemption ;cause=1 ;text="UA Preemption"
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 use cases and extended
definitions for the above four cause codes with message flow
diagrams.
5.1. Access Preemption Event Reason Code
A 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
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 in 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 of
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
A 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,
and 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 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
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 * |
| * - 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 included 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
A 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 with a more precise reason than 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
A 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
Figure 7 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 that
integrity protection be applied when using this header to prevent
unwanted changes to the field and snooping of the messages. The
accepted choices for providing 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 4411
* 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. 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. Currently, there 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 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 strings. These text strings are non-binding and
merely the default for human understanding, but they are deemed
important enough to have their own Registry.