One document matched: draft-polk-mmusic-qos-mechanism-identification-00.txt
MMUSIC Working Group James Polk
Internet-Draft Subha Dhesikan
Expires: April 17th, 2006 Cisco Systems
Gonzalo Camarillo
Ericcson
Oct 17th, 2005
An Identification of QoS Mechanism
for Preconditions
draft-polk-mmusic-qos-mechanism-identification-00.txt
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 April 17th, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
The Session Initiation Protocol (SIP) defines a means for delaying
application layer session set-up signaling from progressing until a
quality of service (QoS) guarantee is established between user
agents. This is specified in RFC 3312. The examples within that
document show the use of the Resource Reservation Protocol (RSVP)
for this service. Now that more than one quality of service
mechanism exists, a means of negotiation is necessary for
interoperability between these user agents. This document will
update RFC 3312 by providing a means of identifying which QoS
mechanism is desired during session establishment.
Polk, et al Expires April 17th, 2005 [Page 1]
Internet-Draft Preconditions QoS Mechanism Oct 2005
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1 Conventions used in this document . . . . . . . . . . . . 3
2. E2E Signaling as shown in 3312 . . . . . . . . . . . . . . . 3
2.1 Problems Exist with Current Mechanisms . . . . . . . . . 5
3. Requirements for QoS indication . . . . . . . . . . . . . . . 6
4. Extending SIP and SDP to Solve this Interoperability Problem 6
4.1 Option-Tags . . . . . . . . . . . . . . . . . . . . . . . . 6
4.2 New Attribute Line . . . . . . . . . . . . . . . . . . . . 7
4.3 Error Responses . . . . . . . . . . . . . . . . . . . . . . 8
5. Message Flows for Various qos-selection Scenarios . . . . . . 8
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
7. Security Considerations . . . . . . . . . . . . . . . . . . . 15
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
9.1 Normative References . . . . . . . . . . . . . . . . . . 15
9.2 Informative References . . . . . . . . . . . . . . . . . 15
Author's Address . . . . . . . . . . . . . . . . . . . . . . 16
Intellectual Property and Copyright Statements . . . . . . . 16
1. Introduction
The Session Initiation Protocol (SIP) defines a means for delaying
session set-up signaling from completing until a quality of service
(QoS) guarantee is established between user agents. This is
specified in RFC 3312 [RFC3312]. Preconditions can be used for many
reasons, including providing a level of service between user agents
prior to the called user agent (UA) phone from ringing. A
limitation within that document is that the QoS mechanism to be used
between user agents to accomplish this level of service is not
discussed; but that a prior agreement between UAs is necessary to
ensure each utilizes the same mechanism to achieve interoperability.
At the time of that document, there was one reservation protocol in
use: Resource Reservation Protocol (RSVP) initially defined in
[RFC2205]. The examples within RFC 3312 were written with RSVP in
mind, but the RFC did not mandate RSVP in any way to achieve
preconditions.
Now that another reservation protocol has been developed, an
indication of which QoS protocol intended to be used is necessary,
specifically with end-to-end QoS Preconditions. This new
reservation protocol is NSIS (Next Steps in Signaling), defined in
at least 3 documents: [ID-GIMPS], [RFC4080] and [ID-NSLP].
This document will update RFC 3312 by extending SIP signaling to
indicate a qos-mechanism is required as part of the precondition for
a session, and SDP [RFC2327] by providing an indication of which QoS
mechanism is desired during session establishment. Additionally, if
Polk, et al Expires April 17th, 2005 [Page 2]
Internet-Draft Preconditions QoS Mechanism Oct 2005
more than one qos-mechanism is offered by the offerer, the list of
qos-mechanisms is given in preferential order.
IANA registrations will be in this document for the SIP and SDP
indications.
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 [RFC2119].
2. E2E Signaling as shown in 3312
Preconditions can be on an end-to-end basis or on a segmented basis.
In the case of a segmented basis, the UAS will not ever see which
QoS mechanism or protocol the UAC chose to use, and the UAC will not
ever see which QoS mechanism or protocol the UAS chose to use.
Thus, two different mechanisms can be used and no interoperability
issues will exist. However, for end-to-end signaling of
Preconditions, the QoS mechanism will have to be understood by the
other UA, even if one direction uses one QoS mechanism and the
reverse direction uses another mechanism. In this case, and in the
more traditional case of only one mechanism being used for QoS
Preconditions, there must be a means for indicating which is
supported by the endsystems.
Looking at the existing end-to-end signaling model from [RFC3312],
the following basic message flow is shown:
Alice Bob
| |
|-------------(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* |
| *** *** |
| *** |
Polk, et al Expires April 17th, 2005 [Page 3]
Internet-Draft Preconditions QoS Mechanism Oct 2005
| *** |
|-------------(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 e2e session establishment using preconditions
Only the first 6 messages are pertinent to this discussion, as we
are focusing on QoS interoperability and how this can be achieved by
SIP. From the flow, Message [M1] is an INVITE from Alice containing
SDP which requests preconditions, but does not clarify which form,
just that it is "qos" preconditions, that is be e2e, and that it is
mandatory before Bob is alerted to the call set-up.
Message [M1] could look like this:
INVITE sip:bob@biloxi.example.com SIP/2.0
Via: SIP/2.0/TCP pc33.atlanta.example.com:5060
;branch=z9hG4bK74bf9
Max-Forwards: 70
To: Bob <sip:bob@biloxi.example.com>
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
Allow: INVITE, CANCEL, ACK, BYE, PRACK, UPDATE, OPTIONS
Call-ID: 3848276298220188511
CSeq: 31862 INVITE
Requires: 100rel, preconditions
Contact: <sip:alice@atlanta.example.com>
Content-Type: application/sdp
Content-Length: ...
v=0
o=alice 2890844526 2890844526 IN IP4 atlanta.example.com
c=IN IP4 10.1.3.33
t=0 0
m=audio 20000 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=curr:qos e2e none
a=des:qos mandatory e2e sendrecv
The last two lines of the SDP above indicate preconditions are
Polk, et al Expires April 17th, 2005 [Page 4]
Internet-Draft Preconditions QoS Mechanism Oct 2005
desired, and that they are mandatory according to Alice's UA on an
end-to-end basis. Notice in this SIP message, there is no
indication of which type of QoS protocol is expected. [RFC3312]
states each UA will need to have decided upon that in a way outside
that specification. We will show soon how that can be a problem.
Bob's UA receives this INVITE message and if his UA agrees with all
that is in the offer, it might create a 183 (Session Progressing)
message like this [M2] below:
SIP/2.0 183 Session Progress
Via: SIP/2.0/TCP swc50.atlanta.example.com:5060
;branch=z9hG4bK74bf9 ;received=10.1.3.33
To: Bob <sip:bob@biloxi.com>;tag=8321234356
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
Allow: INVITE, CANCEL, ACK, BYE, PRACK, UPDATE, OPTIONS
Call-ID: 3848276298220188511
CSeq: 31862 INVITE
RSeq: 813520
Contact: <sip:bob@biloxi.example.com>
Content-Type: application/sdp
Content-Length: ...
v=0
o=bob 2890844527 2890844527 IN IP4 biloxi.example.com
c=IN IP4 192.168.10.1
t=0 0
m=audio 30000 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=curr:qos e2e none
a=des:qos mandatory e2e sendrecv
a=conf:qos e2e recv
The next section will briefly discuss what problems can arise at
this stage in the message flow if the two endpoints do not
understand each other's preferences and capabilities.
2.1 Problems Exist with Current Mechanisms
If Bob supports RSVP, his UA will initiate RSVP Path message towards
Alice. If Alice only supported NSIS then her UA may not receive or
understand the RSVP Path message and therefore her UA will not know
what response to provide. Instead her UA may initiate the NSIS
Query message or the NSIS receive message which Bob's UA will not
understand. So, the UA's not receiving a response for the message
sent will fail the session after some time interval. This causes a
large post-dial delay that can be avoided by the mechanisms
described in this draft.
Polk, et al Expires April 17th, 2005 [Page 5]
Internet-Draft Preconditions QoS Mechanism Oct 2005
Alice Router1 Router2 Bob
| | | PATH |
| | PATH |<---------+
| PATH |<---------+ |
|<---------+ | |
| | | |
| QUERY | | |
+--------->| QUERY | |
| +--------->| QUERY |
Figure 2: Basic QoS Mechanism Interoperability Problem
This problem occurs even if one or both UA supported multiple QoS
mechanisms because the current mechanisms do not allow the UA to
select a common QoS mechanism to use between them. For example let
us have Bob support RSVP and NSIS whereas Alice only supports NSIS.
If Bob initiated RSVP, the session will fail as mentioned above.
With the mechanisms described in this draft, such problems can be
avoided and Alice and Bob can negotiate to use RSVP as Alice only
supported RSVP.
3. Requirements for QoS Indication
Here are the requirements to solve the above scenarios:
Req#1 - An offerer MUST be able to indicate which qos mechanism it
supports to ensure the answerer knows which is intended.
Req#2 - An answerer MUST be able to respond with an indication it
does not support any qos mechanisms.
Req#3 - A means of listing however many qos mechanisms the offerer
supports MUST be possible.
Req#4 - A means of listing a preferential order of qos mechanisms
the offerer supports MUST be possible.
Req#5 - The answerer SHOULD choose the preferred qos mechanism of
the answerer.
Req#6 - The offerer MAY choose to list a subset of the qos-
mechanisms it supports.
4. Extending SIP and SDP to Solve this Interoperability Problem
4.1 Option-Tags
Option-tags in SIP are an indication of an extension to SIP
[RFC3261]. Option-tags appear in the Requires, Supported and
Unsupported headers indicating to the receiving UA that another UA
Polk, et al Expires April 17th, 2005 [Page 6]
Internet-Draft Preconditions QoS Mechanism Oct 2005
either requires its usage, supports the extension or does not
support the extension. The following new option-tag is defined in
this document:
qos-selection This Option-Tag indicates there will be a specific
qos mechanism(s) listed for qos preconditions within
this transaction. The list of one or more
mechanisms will be in an SDP attribute line.
This an example of the Requires with this option-tag:
Requires: qos-selection
As [RFC3261] states, this can be its own Requires header line, or it
can be combined with other option-tags separated by a comma, ','.
For example, this could be an example of an appropriate Requires
header involving qos preconditions:
Requires: rel100, preconditions, qos-selection
This option-tag has the following rules:
- "qos-selection" MUST be used in a Requires header in a Request
message if the preconditions are mandatory.
- "qos-selection" SHOULD be used in a Supported header in a Request
message if the preconditions are optional, and MAY be in a
Requires header.
- "qos-selection" MUST be in a Unsupported header in a Response
message if the recipient of the original Request (having it in a
Requires header) does not understand the extension.
4.2 New Attribute Line
Within SDP [RFC2327], attribute lines located above all M lines are
session attributes associated with all the media of that session
unless overridden an attribute of the same name in the media
description. This new attribute media level attribute within SDP.
We define the following media level SDP attribute:
qos-mechanism = "a=qos-mechanism:" SP qos-mechanism-type
SP direction-tag
qos-mechanism-type = "rsvp" | "nsis" | token
direction-tag = ("none" | "send" | "recv" | "sendrecv")
If an endsystem offers both RSVP and NSIS, and wants qos in both
directions, the new attribute line would look as follows:
a=qos-mechanism: rsvp nsis sendrecv
Polk, et al Expires April 17th, 2005 [Page 7]
Internet-Draft Preconditions QoS Mechanism Oct 2005
Although the above line looks similar to the M line listing a series
of codecs supported in an offer, we define here an intended order of
preference by the offerer in which the first qos mechanism listed is
preferred by the offerer, and if that qos mechanism is supported by
the answerer, it SHOULD be chosen by the answerer.
For example, if there is a qos-mechanism line such as this:
a=qos-mechanism: rsvp nsis foo bar sendrecv
and the answerer supports rsvp, rsvp SHOULD be what is chosen for
that session, even if the answerer would normally prefer any one of
the other qos-mechanisms listed if they were the offerer. If the
answerer in this example does not support rsvp, the next preferred
qos-mechanism is nsis, with the same rule of 'SHOULD chose this
mechanism if supported by the answerer'.
If an offer has a Requires header indicating "qos-selection", the
offerer MUST include this new "qos-mechanism" attribute line where
appropriate in SDP, including at least one qos value it supports.
If, based on local policy, prefers one qos-mechanism over another,
it is RECOMMENDED the offerer understand the preferential order
capability this document defines, and list whichever one it prefers
first.
Examples of usage are in section 5 of this document, including what
occurs when there is a lack of support for the mechanisms in an
offer, and when there are interoperability problems.
4.3 Error Responses
A SIP element that is properly processing a SIP Request with a
Requires header with a value of qos-selection and the entity does
not support that extension, the entity MUST respond with a 420 (Bad
Extension) and list this option tag in an Unsupported Header in the
420.
If the SIP entity does support the extension qos-selection, yet does
not support any qos mechanism(s) listed in the offer (SDP), the
proper response is a 488 (Not Acceptable Here) with an SDP
indicating which qos mechanisms the UAS does support.
5. Message Flows for Various qos-selection Scenarios
Here are some simple message flows that indicate the solution given
in this document. All examples lack some necessary to normal
operation, but unneeded headers and lines within each message for
this discussion, for brevity.
Polk, et al Expires April 17th, 2005 [Page 8]
Internet-Draft Preconditions QoS Mechanism Oct 2005
5.1 Offer Many - Accept One Example
Alice INVITEs with multiple qos-mechanisms and Bob accepts one of
Them.
Alice Bob
| INVITE (qos-selection) |
|------------------------->|
| |
| 183 Session Progress |
|<-------------------------|
| |
| PRACK |
|------------------------->|
| 200 OK |
|<-------------------------|
Figure 4.
INVITE Bob@ SIP/2.0
To: Bob <bob@>
From: Alice <alice@>
Requires: preconditions, qos-selection
m=audio
a=qos-mechanism: rsvp nsis sendrecv
a=curr:qos e2e none
a=des:qos mandatory e2e sendrecv
SIP/2.0 183 Session Progress
To: Bob <bob@>
From: Alice <alice@>
Supported: preconditions, qos-selection
m=audio
a=qos-mechanism: rsvp sendrecv
a=curr:qos e2e none
a=des:qos mandatory e2e sendrecv
Alice's INVITE includes a list of qos-mechanisms that her UA wishes
to use. They are arranged by preference. If Bob supports any one of
the listed mechanisms then Bob accepts the INVITE by sending a 183
(Session Progress) message. It is recommended that Bob select the
earliest mechanism in the list that his UA supports.
5.2 Offer One - Accept None Example
Bob does not support the qos-mechanism listed by Alice in her
INVITE.
Polk, et al Expires April 17th, 2005 [Page 9]
Internet-Draft Preconditions QoS Mechanism Oct 2005
Alice sends an INVITE message with a qos-mechanism Bob does not
support. Bob's response is a 488 (Not Acceptable Here) with an
attribute line indicating which qos-mechanism(s) he does support.
Alice Bob
| INVITE (qos-selection) |
|------------------------->|
| |
| 488 Not Acceptable Here |
|<-------------------------|
| |
| ACK |
|------------------------->|
| |
Figure 5.
INVITE Bob@ SIP/2.0
To: Bob <bob@>
From: Alice <alice@>
Requires: preconditions, qos-selection
m=audio
a=qos-mechanism: rsvp sendrecv
a=curr:qos e2e none
a=des:qos mandatory e2e sendrecv
SIP/2.0 488 Not Acceptable Here
To: Bob <bob@>
From: Alice <alice@>
Supported: preconditions, qos-selection
m=audio
a=qos-mechanism: nsis sendrecv
a=curr:qos e2e none
a=des:qos mandatory e2e sendrecv
Bob sends a 488 (Not Acceptable Here) message as the qos-mechanism
listed by Alice (rsvp) is not supported by Bob. Alice, if her UA
supports this precondition mechanism, MAY send a new INVITE with
preconditions using NSIS and have a reasonable expectation that
Bob's UA will not reject that session request.
5.3 Offer Many - Accept One in Each Direction Example
Alice INVITEs Bob and Bob chooses a different qos-mechanism for each
direction from Alice's list
Alice sends Bob an INVITE containing more than one qos-mechanism.
Polk, et al Expires April 17th, 2005 [Page 10]
Internet-Draft Preconditions QoS Mechanism Oct 2005
Alice Bob
| INVITE (qos-selection) |
|------------------------->|
| |
| 183 Session Progress |
|<-------------------------|
| |
| PRACK |
|------------------------->|
| 200 OK |
|<-------------------------|
Figure 6.
INVITE Bob@ SIP/2.0
To: Bob <bob@>
From: Alice <alice@>
Requires: preconditions, qos-selection
m=audio
a=curr:qos e2e none
a= qos-mechanism: rsvp nsis foo sendrecv
a=des:qos mandatory e2e sendrecv
SIP/2.0 183 Session Progress
To: Bob <bob@>
From: Alice <alice@>
Supported: preconditions, qos-selection
m=audio
a=curr:qos e2e none
a=qos-mechanism: nsis send
a=qos-mechanism: rsvp recv
a=des:qos mandatory e2e sendrecv
Bob chooses rsvp (Bob's first preference) for recv direction but
prefers to do nsis for streams that his UA originates. Hence, Bob
selects a different mechanism for each direction. However, as both
mechanisms selected by Bob were originally in Alice's list, Bob
accepts the session and issues a 183 (Session Progress) message.
5.4 Offer Many - Prefer Unlisted Combination Example
Alice INVITEs Bob and Bob chooses a qos-mechanism for one direction
that is not on Alice's list.
Alice sends Bob an INVITE with more than one qos-mechanism in this
offer.
Polk, et al Expires April 17th, 2005 [Page 11]
Internet-Draft Preconditions QoS Mechanism Oct 2005
Alice Bob
| INVITE (qos-selection) |
|------------------------->|
| |
| 488 Not Acceptable Here |
|<-------------------------|
| |
| ACK |
|------------------------->|
| |
Figure 7.
INVITE Bob@ SIP/2.0
To: Bob <bob@>
From: Alice <alice@>
Requires: preconditions, qos-selection
m=audio
a=qos-mechanism: rsvp nsis sendrecv
a=curr:qos e2e none
a=des:qos mandatory e2e sendrecv
SIP/2.0 488 Not Acceptable Here
To: Bob <bob@>
From: Alice <alice@>
Supported: preconditions, qos-selection
m=audio
a=qos-mechanism: rsvp recv
a=qos-mechanism: foo send
a=curr:qos e2e none
a=des:qos mandatory e2e sendrecv
Bob sends a 488 (Not Acceptable Here) message as his UA supports
qos-mechanism "foo" for the stream that his UA originates. Alice, if
her UA supports this "foo" precondition mechanism, MAY send a new
INVITE with preconditions using rsvp for send direction and foo for
recv direction and have a reasonable expectation that Bob's UA will
not reject that session request.
5.5 Offer Any - Preconditions Unknown Example
Bob does not support the qos-selection extension within SIP.
Alice Bob
| INVITE (qos-selection) |
|------------------------->|
Polk, et al Expires April 17th, 2005 [Page 12]
Internet-Draft Preconditions QoS Mechanism Oct 2005
| |
| 420 Bad Extension |
|<-------------------------|
| |
| ACK |
|------------------------->|
| |
Figure 8.
INVITE Bob@ SIP/2.0
To: Bob <bob@>
From: Alice <alice@>
Requires: preconditions, qos-selection
m=audio
a=qos-mechanism: rsvp nsis sendrecv
a=curr:qos e2e none
a=des:qos mandatory e2e sendrecv
SIP/2.0 420 Bad Extension
To: Bob <bob@>
From: Alice <alice@>
Unsupported: qos-selection
Since Bob does not support qos-selection option, he responds to
Alice's INVITE with a 420 Bad Extension.
5.6 Offer Many with Optional Strength - Accept One Example
Use of qos-selection as a required option tag with optional strength
tag precondition
Alice Bob
| INVITE (qos-selection) |
|------------------------->|
| |
| 183 Session Progressing |
|<-------------------------|
| |
| ACK |
|------------------------->|
| |
Figure 8.
INVITE Bob@ SIP/2.0
To: Bob <bob@>
From: Alice <alice@>
Polk, et al Expires April 17th, 2005 [Page 13]
Internet-Draft Preconditions QoS Mechanism Oct 2005
Requires: preconditions, qos-selection
m=audio
a=qos-mechanism: rsvp nsis sendrecv
a=curr:qos e2e none
a=des:qos optional e2e sendrecv
SIP/2.0 183 Session Progressing
To: Bob <bob@>
From: Alice <alice@>
Supported: preconditions, qos-selection
m=audio
a=qos-mechanism: rsvp sendrecv
a=curr:qos e2e none
a=des:qos optional e2e sendrecv
Since [RFC 3312] states that UAs SHOULD try to reserve resources, it
is acceptable to use the Requires option tag with qos-selection.
Qos-selection will be made and reservation will be attempted using
the selected qos-mechanism but the session will progress even if the
UAs are not able to secure reservation.
6. IANA Considerations
This document IANA registers the following SIP Option-Tag to be
added to the sip-parameters:
qos-selection
as follows:
Name Description Reference
----------- ------------------------------------------ ---------
qos-selection This Option-Tag indicates there will be a [This doc]
specific qos mechanism(s) listed for qos
preconditions within this transaction. The
list of one or more mechanisms will be in
an SDP attribute line.
Section 4.1 of this document defines its usage.
This document IANA registers the following SDP attribute field type
to be added to the sdp-parameters:
qos-mechanism
as follows:
Polk, et al Expires April 17th, 2005 [Page 14]
Internet-Draft Preconditions QoS Mechanism Oct 2005
Type SDP Name Reference
---- ------------------ ---------
att-field (media level only)
qos-mechanism [This document]
Section 4.2 of this document defines its usage.
7. Security Considerations
This document provides a means for greater granularity of an
existing SIP mechanism. SIP Preconditions as defined without this
document may be hidden in a S/MIME encrypted message body preventing
revelation. This document defines a set of option-tags that may
reveal the use of preconditions where it would otherwise not have
been revealed. Caution should be taken with this in might.
8. Acknowledgements
To Dave Oran for his help in forming this effort.
9. References
9.1 Normative References
[RFC3261] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J.
Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, May 2002.
[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997
[RFC3312] G. Camarillo, Ed., W. Marshall, Ed., J. Rosenberg,
"Integration of Resource Management and Session Initiation
Protocol (SIP)", RFC 3312 Preconditions, October 2002
[RFC2205] R. Braden, Ed., L. Zhang, S. Berson, S. Herzog, S. Jamin,
"Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification", RFC 2205, September 1997
[RFC2327] M. Handley, V. Jacobson, "SDP: Session Description
Protocol", RFC 2327, April 1998
9.2 Informative References
[RFC4080] R. Hancock, G. Karagiannis, J. Loughney, S. Van den Bosch,
"Next Steps in Signaling (NSIS): Framework", RFC 4080, June
2005
Polk, et al Expires April 17th, 2005 [Page 15]
Internet-Draft Preconditions QoS Mechanism Oct 2005
[ID-GIMPS] H. Schulzrinne, R. Hancock, "GIMPS: General Internet
Messaging Protocol for Signaling", draft-ietf-nsis-ntlp-07,
"work in progress", July 2005
[ID-NSLP] J. Manner, G. Karagiannis, A. McDonald, S. Van den Bosch,
"NSLP for Quality-of-Service signaling", draft-ietf-nsis-
qos-nslp-07.txt, "work in progress", July 2005
Author's Address
James M. Polk
3913 Treemont Circle
Colleyville, Texas 76034
USA
Phone: +1-817-271-3552
Email: jmpolk@cisco.com
Subha Dhesikan
Cisco Systems
170 W. Tasman Drive
San Jose, CA 95134
USA
Email: sdhesika@cisco.com
Gonzalo Camarillo
Ericsson
Hirsalantie 11
Jorvas 02420
Finland
EMail: Gonzalo.Camarillo@ericsson.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
Polk, et al Expires April 17th, 2005 [Page 16]
Internet-Draft Preconditions QoS Mechanism Oct 2005
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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Polk & Expires April 17th, 2006 [Page 17]
| PAFTECH AB 2003-2026 | 2026-04-23 13:10:35 |