Internet DRAFT - draft-gunn-sip-req-for-rph-in-responses
draft-gunn-sip-req-for-rph-in-responses
SIP WG Janet Gunn
Internet-Draft CSC
Martin Dolly
Expires: May 12, 2008 AT&T Labs
Tim Dwight
Verizon
November 9, 2007
Requirements for SIP Resource Priority Header in SIP Responses
draft-gunn-sip-req-for-rph-in-responses-00
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 May 9th, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
The Session Initiation Protocol (SIP) Resource Priority Header
(RPH), in its current form, is ignored in SIP responses. This was
a design choice during RFC 4412's development. This is now
considered a bad design choice in certain scenarios. The Internet
Draft "Allowing SIP Resource Priority Header in SIP Responses"
(draft-polk-sip-rph-in-responses-00) describes a modification to
RFC4412 to permit RPH in responses. This document describes one of
the requirements associated with systems using RPH, that could be
satisfied by the modification of RFC 4412 to permit RPH on
responses, and is not easily met by other methods. This ID provides
Gunn Expires May 9th, 2008 [Page 1]
Internet-Draft Requirements for SIP RPH in Responses November 2007
additional motivation for SIP RPH in Responses.
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 [RFC2119].
1. Introduction
The Session Initiation Protocol (SIP) Resource Priority Header
(RPH) [RFC4412], in its current form, is ignored by SIP entities if
in SIP responses. It was a design choice during RFC 4412's
development that only stateful SIP elements would grant SIP
messages preferential treatment. Limiting servers which process the
RPH to only being transaction stateful is now considered a bad
design choice in certain scenarios, such as those entities within
trusted networks. This document describes in greater detail a
requirement, within a trusted network, which cannot be met by
RFC 4412 in its current form, without RPH on responses. The
requirement can be met if RPH on responses is permitted.
As stated in RFC 3487 [RFC3487] and RFC 4412, one of the motivation
for RPH is to support the migration of the Government Emergency
Telecommunications Service (GETS) and Wireless Priority Service
(WPS) from the service providers' Circuit Switched Networks to the
same service providers' Packet Switched Networks, using IP and SIP.
The ets and wps name spaces, each with 5 priority values, are
intended to support this.
We have simplified the description of the GETS/WPS service and call
flow, in order to focus on the facet that is most directly related
to the need for RPH in responses.
In the GETS/WPS paradigm, each authorized user (a "Service User")
is assigned a priority (out of 5) when GETS/WPS is invoked, for
times in which congestion may be experienced, reducing the
probability of successful communications. GETS/WPS treatment
is especially important for resources in the access networks where
bottlenecks are most likely.
The user does NOT submit the priority level when requesting
GETS/WPS service- in fact, in many cases, the Service User does
not know his/her priority level, and nor does the User Equipment
(UE) at which s/he is subscribed. This paradigm introduces some
requirements that are not met by RFC 4412 without RPH in responses.
Note that this is different from the MLPP paradigm associated with
the dsn and dsrn namespaces. In the MLPP paradigm, the user
requests a specific priority level. The authentication/
authorization process then determines whether the user is entitled
to the requested priority level.
Gunn Expires May 9th, 2008 [Page 2]
Internet-Draft Requirements for SIP RPH in Responses November 2007
2. Problem Statement
The high level call flow (whether in the circuit switched network
or the IP network) for a GETS/WPS call is that the user initiates
a call requesting the GETS/WPS service (but not specifying the
priority level). (In the current system this is indicated in the
"dialed digits". In SIP this will be reflected in the URI.) The
specialized GETS/WPS server (referred to as the GETS Application
Server, or GETS AS) then determines whether the user and/or
equipment are authenticated and authorized to use GETS/WPS. If so,
it extracts the user's priority level from a data base. The GETS
AS also extracts or generates the URI for the called party.
In the SIP domain, the wps namespace (with the user's priority
value), in conjunction with the ets namespace, in the RPH is used to
convey the priority value extracted from the data base. The rest
of this requirement statement will focus on the wps namespace with
the user's priority value.
(In the circuit switched domain, using SS7, the Calling Party
Category (CPC) setting is used to indicate a request for priority
service, and the Precedence Parameter is used to indicate the
priority level extracted from the database- without implying any
preemption.)
The network then proceeds to allocate/reserve resources in both the
originating and terminating access networks, whether IP or circuit
switched. In the IP network it would typically use preconditions,
as described in RFC 3312 [RFC3312]. At a PSTN gateway, the
indication that it is a GETS/WPS call, and the priority level,
would be translated into the appropriate ISUP parameters, and the
legacy GETS/WPS mechanisms would be used to ensure a high
probability of completion in the ISUP network. In either case,
the user's priority level is needed in allocating resources
in both the originating and terminating access networks.
The INVITE that is sent toward the called party's UA will contain
the RPH with the calling user's priority level. The same
information needs to be sent toward the calling party, so it can
be used in the originating access network.
Typically, the messages sent back toward the calling party (once
the priority value has been extracted from the data base, but
before the bearer path is established) would be responses (e.g.,
183) rather than requests.
2.1 Sample Call Flow
Figure 1 shows the call flow for basic session establishment using
preconditions (as described in RFC 3312).
Gunn Expires May 9th, 2008 [Page 3]
Internet-Draft Requirements for SIP RPH in Responses November 2007
A B
| |
|-------------(1) INVITE SDP1--------------->|
| |
|<------(2) 183 Session Progress SDP2--------|
| *** *** |
|--*R*-----------(3) PRACK-------------*R*-->|
| *E* *E* |
|<-*S*-------(4) 200 OK (PRACK)--------*S*---|
| *E* *E* |
| *R* *R* |
| *V* *V* |
| *A* *A* |
| *T* *T* |
| *I* *I* |
| *O* *O* |
| *N* *N* |
| *** *** |
| *** |
| *** |
|-------------(5) UPDATE SDP3--------------->|
| |
|<--------(6) 200 OK (UPDATE) SDP4-----------|
| |
|<-------------(7) 180 Ringing---------------|
| |
|-----------------(8) PRACK----------------->|
| |
|<------------(9) 200 OK (PRACK)-------------|
| |
| |
| |
|<-----------(10) 200 OK (INVITE)------------|
| |
|------------------(11) ACK----------------->|
| |
| |
Figure 1: Basic session establishment using preconditions
Figure 2 shows the addition of the GETS AS, to authenticate and
authorize the GETS/WPS request, and to extract the user's priority
level from the database. Note that the GETS AS is B2BUA that remains
in the call/session path in order to monitor call/session progress
and initiate subsequent call processing. It also shows the addition
of the RPH with the wps namespace in subsequent requests. In this
case, A knows that GETS/WPS service has been requested, but does no
know the user's priority level. Based on the information included
in the initial INVITE, the GETS Application server authenticates the
user, and looks up the user's priority level in the co-located
Gunn Expires May 9th, 2008 [Page 4]
Internet-Draft Requirements for SIP RPH in Responses November 2007
A GETS AS B
| | |
|-----------(1) INVITE SDP1----->| |
| Look up in data base for |
| priority level (=3) |
| | |
| |----(2) INVITE SDP1 RPH wps.3-->|
| | |
| |<-(3) 183 Session Progress SDP2-|
|<-(4) 183 Session Progress SDP2-| |
| *** | |
|--*R*---------(5) PRACK-------->| *** |
| *E* |---(6) PRACK RPH wps.3----*R*-->|
| *S* | *E* |
| *E* |<--(7) 200 OK (PRACK)-----*S*---|
|<-*R*-----(8) 200 OK (PRACK)----| *E* |
| *V* | *R* |
| *A* | *V* |
| *T* | *A* |
| *I* | *T* |
| *O* | *I* |
| *N* | *O* |
| *** | *N* |
| *** | *** |
| *** | *** |
|--(9) UPDATE SDP3-------------->| |
| |-(10) UPDATE SDP3 RPH wps.3--->|
| | |
| |<---(11) 200 OK (UPDATE) SDP4---|
|<--(12) 200 OK (UPDATE) SDP4----| |
| | |
| |<---------(13) 180 Ringing------|
|<-------(14) 180 Ringing--------| |
| | |
|--------------(15) PRACK------->| |
| |------(16) PRACK RPH wps.3----->|
| | |
| |<--(17) 200 OK (PRACK)----------|
|<--------(18) 200 OK (PRACK)----| |
| | |
| | |
| | |
| |<--(19) 200 OK (INVITE)---------|
|<-----(20) 200 OK (INVITE)------| |
| | |
|---------------(21) ACK-------->| |
| |-------(22) ACK RPH wps.3------>|
| | |
Figure 2: Modified session establishment using preconditions,
with addition of GETS AS
Gunn Expires May 9th, 2008 [Page 5]
Internet-Draft Requirements for SIP RPH in Responses November 2007
database. In this case it determines that the user priority
corresponds to wps priority level 3.
The GETS AS therefore inserts an RPH with "wps.3" in the INVITE (2)
it sends on to B. When B receives the INVITE with the RPH, it uses
the "wps priority level 3" information, in addition to the
information in SDP1, in making the reservation at the B end.
B then sends 183 Session Progress back to A, by way of the GETS AS.
In order to properly set up the reservation at the "A" end, A also
needs to know that it should use "wps priority level 3" in setting
up the reservation. If The RPH can be included in the 183 (4)
response sent from the GETS AS to A, then A will have the
information it needs. If the RPH cannot be included in the
response, it is not clear how A will get the "wps priority level 3"
information. This call flow illustrates the requirement that cannot
be met by RPH without RPH in responses. There are of course, a
number of other possible call flows, but the problem of conveying
"wps.3" to A remains.
3. Potential Solution Approaches
Connected Identity, or other approaches using "UPDATE" have been
suggested as a solution to conveying the user's priority level back
to A.
The UPDATE method described in RFC 3311 [RFC3311] is used to modify
a session after the initial dialog has been established, but before
the initial INVITE has been accepted (e.g., before the call is
answered). In principle this could be used to convey the user's
priority level. However the UPDATE can not be sent until after the
dialog is established. In the example given, the dialog is
established by the 183 which contains the SDP. So, by the time you
could send an UPDATE, it is already too late, the reservation
process has begun.
Another theoretical possibility would be to modify the SDP
contained in the 183. However, it is undesirable to modify a
separate protocol (SDP) to satisfy a SIP requirement.
Another would be to somehow modify the 183 to indicate that the UA
should "wait for an UPDATE" before beginning the reservation/
allocation process. However, it is counterproductive, and not
acceptable for this service, to introduce additional delay, and
introduce additional error/failure conditions (what happens if the
promised UPDATE doesn't arrive?) when the network is congested.
The use of distinct logical ports has been suggested as a way to
identify the priority of a response. While this may address some
of the other proposed uses of RPH in Responses, it does not
address this requirement, because the response use the same logical
port as the request that triggered it. That will only work when
Gunn Expires May 9th, 2008 [Page 6]
Internet-Draft Requirements for SIP RPH in Responses November 2007
the UA sending the request already knows the priority level.
4. Acknowledgements
Thanks to Keith Drage, Dean Willis, Brian Rosen, Jeroen van Bemmel,
Henry Sinnreich, Joel Halpern, and John Elwell for useful
discussion on the list. Thanks to James Polk for assistance in
understanding the issues and presenting the requirement.
Thanks to John Rosenburg for background discussions about the
importance of resolving this issue.
5. IANA Considerations
IANA considerations are discussed in [RPHresp].
6. Security Considerations
The Security considerations that apply to RFC 4412 [RFC4412] and
those discussed in [RPHresp] apply here.
There are legitimate security concerns about using RPH in responses
to update the user's priority value. There is no way to challenge
responses. In an open network, it is not easy to prevent "Joe End
User" from arbitrarily adding an RPH with wps.0 (the highest
priority level) to his responses.
First of all, the requirement described here does not apply to the
open Internet network. This requirement only applies to closely
managed networks, for which the Service Provider has contracted to
provide GETS service. Solutions, never the less, must also work in
unmanaged networks
Secondly, while there may be other reasons for wanting RPH in
responses, the requirement describe here only applies to the UA
that is going to be reserving resources, and only when the RPH is
in a response coming from a pre-identified device (e.g., the GETS
AS), probably via a secure connection. This UA can (and should)
be configured to ignore the priority level conveyed in the RPH in
other responses (coming from other sources, or not via a secure
connection) in terms of updating the user's priority level.
Other UAs, which do not reserve resources, can, and probably should,
be configured to ignore the priority level in the RPH in a response
coming from any source, over a secure or insecure connection.
Due to the potential for fraud, SIP devices are advised to ignore
RPH in responses unless they are certain that the response came
from a trusted source from which, based on local policy, they are
authorized to receive such information. The definition of trusted
device is a matter of network policy.
Gunn Expires May 9th, 2008 [Page 7]
Internet-Draft Requirements for SIP RPH in Responses November 2007
7. References
7.1 Informative References
[RFC3487] H. Schulzrinne, "Requirements for Resource Priority
Mechanisms for the Session Initiation Protocol (SIP)",
RFC 3487, February 2003.
[RFC3312] G. Camarillo, W. Marshall, J. Rosenberg, "Integration of
Resource Management and Session Initiation Protocol (SIP)",
RFC 3312, October 2002
[RFC3311] J. Rosenberg, "The Session Initiation Protocol (SIP) UPDATE
Method," RFC 3311, September 2002.
[RPHresp] J. Polk,"Allowing SIP Resource Priority Header in SIP
Responses", draft-polk-sip-rph-in-responses-00 (work in
Progress) , June 2007
7.2 Normative References
[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997
[RFC4412] Schulzrinne, H., Polk, J., "Communications Resource
Priority for the Session Initiation Protocol (SIP)", RFC
4411, Feb 2006
Author's Addresses
Janet Gunn
CSC
15000 Conference Center Drive
Chantilly, VA 20151
USA
Phone: +1-703-818-4725
Fax: +1-703-818-5947
Email: jgunn6@csc.com
Tim Dwight
Verizon
2400 North Glenville Drive
Richardson, TX 75082
USA
Phone: +1-972-729-5199
Fax : +1-972-729-5392
Email: timothy.dwight@verizon.com
Gunn Expires May 9th, 2008 [Page 8]
Internet-Draft Requirements for SIP RPH in Responses November 2007
Martin Dolly
AT&T Labs
Middletown Township, New Jersey 07748
USA
Phone: +1-732-420-4574
Email: mdolly@att.com
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE
ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed
to pertain to the implementation or use of the technology described
in this document or the extent to which any license under such
rights might or might not be available; nor does it represent that
it has made any independent effort to identify any such rights.
Information on the procedures with respect to rights in RFC
documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use
of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository
at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Gunn Expires May 9th, 2008 [Page 9]
Internet-Draft Requirements for SIP RPH in Responses November 2007
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Gunn Expires May 9th, 2008 [Page 10]
