[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]
Versions: 00
Internet Engineering Task Force MMUSIC WG
Internet Draft J.Rosenberg,H.Schulzrinne,S.Donovan
draft-ietf-mmusic-sdp-qos-00.txt Bell Laboratories,Columbia U.,MCI Worldcom
June 19, 1999
Expires: December 1999
Establishing QoS and Security Preconditions for SDP Sessions
STATUS OF THIS MEMO
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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.
Abstract
1 Introduction
This document discusses how network QoS and security establishment
can be made a precondition to sessions described by SDP [1]. These
J.Rosenberg,H.Schulzrinne,S.Donovan [Page 1]
Internet Draft SDP QoS June 19, 1999
preconditions require that the participant reserve network resources
(or establish a secure media channel) before continuing with the
session. We do not define new QoS reservation or security mechanisms;
these pre-conditions simply require a participant to use existing
resource reservation and security mechanisms before beginning the
session.
In the case of SIP [2], this effectively means that the "phone won't
ring" until the preconditions are met. These preconditions are
described by new SDP parameters, defined in this document. The
parameters can mandate end-to-end QoS reservations based on RSVP [3]
or any other end-to-end reservation mechanism (such as YESSIR [4]),
and security based on IPSEC [5]. The preconditions can be defined
independently for each media stream.
To achieve the result of "not having the phone ring" until resources
have been reserved, some have proposed adding QoS functions to
application level signaling devices [6]. We do not take this
approach. Rather, we feel that the QoS architecture of the Internet
separates QoS signaling from application level signaling. Application
layer devices (such as web proxies and SIP servers) are not well
suited for participation in network admission control or QoS
management, as this is fundamentally a network layer issue,
independent of any particular application. In addition, since
application devices like SIP servers are almost never on the "bearer
path" (i.e., the network path the RTP [7] takes), and since the RTP
path and signaling paths can be completely different (even traversing
different autonomous systems), these application servers are
generally not capable of managing QoS for the media. Keeping QoS out
of application signaling also means that there can be a single
infrastructure for QoS across all applications. This eliminates
duplication of functionality, reducing management and equipment
costs. It also means that new applications, with their own unique QoS
requirements, can be easily supported.
This loose coupling works very well for a wide range of applications.
For example, in an interactive game, one can establish the game using
an application signaling protocol, and then later on use RSVP to
reserve network resources. The separation is also effective for
applications which have no explicit signaling . However, certain
applications may require tighter coupling. In the case of Internet
telephony, the following is an important requirement:
When A calls B, B's phone should not ring unless resouces
have been reserved from A to B, and B to A.
This could be achieved without coupling if A knew B's address, port,
J.Rosenberg,H.Schulzrinne,S.Donovan [Page 2]
Internet Draft SDP QoS June 19, 1999
and codecs before the telephony signaling took place. However, since
telephony signaling is used largely to obtain this information in the
first place, the coupling cannot be avoided.
A similar model exists for security. Rather than inventing new
security mechanisms for each new application, common security tools
(such as IPSEC) can be used across all applications. As with QoS, a
means in application level protocols is needed to indicate that a
security association is needed for the application to execute.
To solve both of these problems, we propose an extension to SDP which
allows indication of pre-conditions for sessions. These preconditions
indicate that participation in the session should not proceed until
the preconditions are met. The preconditions we define are (1)
success of end-to-end resource reservation, and (2) success of end-
to-end security establishment. We chose to implement these extensions
in SDP, rather than SIP [2] or SAP [8], since they are fundamentally
a media session issue. SIP is session agnostic; information about
codecs, ports, and RTP [7] are outside the scope of SIP. Since it is
the media sessions that the reservations and security refer to, SDP
is the appropriate venue for the extensions. Furthermore, placement
of the extensions in SDP rather than SIP or SAP allows specification
of preconditions for individual media streams. For example, a
multimedia lecture might require reservation for the audio, but not
the video (which is less important).
Our extensions are completely backwards compatible. If a recipient
does not understand them, normal SIP or SAP processing will occur, at
no penalty of call setup latency.
Others have proposed defining new SIP headers (such as pre-RING) to
convey to the remote party that QoS establishment is required,
followed by a re-INVITE (with ringing) to actually initiate the
session (thus there is a double INVITE to actually initiate the
session) [9]. Other mechanisms exist as well. A separate draft
addresses the differences in these approaches.
2 Overview
The general idea behind the extension is simple. We define two new
SDP attributes, qos and security. The qos attribute indicates whether
end-to-end resource reservation is optional or mandatory, and in
which direction (send, recv, or sendrecv). When the attribute
indicates mandatory, this means that the participant who has received
the SDP MUST NOT proceed with participation in the session until
resource reservation has completed in the direction indicated. In
this case, "not proceeding" means that the participant behaves as if
they had not received the SDP at all. If the attribute indicates that
J.Rosenberg,H.Schulzrinne,S.Donovan [Page 3]
Internet Draft SDP QoS June 19, 1999
QoS for the stream is optional, then the participant SHOULD proceed
normally with the session, but SHOULD reserve network resources in
the direction indicated, if they are capable. Absence of the qos
attribute means the participant MAY reserve resources for this
stream, and SHOULD proceed normally with the session. This behavior
is the normal behavior for SDP.
Resource reservation takes place using whatever protocols each
participant must use based on support by their ISP. If the ISP's of
the various participants are using differing resource reservation
protocols, translation is necessary, but this is done within the
network, without knowledge of the participants.
When the end-to-end reservation fails for a stream whose qos is
mandatory, the behavior is dependent on the specific protocol which
delivered the SDP. The sections which follow define these semantics
for SIP and SAP.
The direction attribute indicates which direction reservations should
be reserved in. If send, it means reservations should be made in the
direction of media flow from the session originator to participants.
In recv, it means reservations should be made in the direction of
media flow from participants to the session originator. In the case
of sendrecv, it means both.
In the case of security, the same attributes are defined -
optional/mandatory, and send/recv/sendrecv. Their meaning is
identical to the one above, except that a security association should
be established in the given direction. The details of the security
association are not signaled by SDP; these depend on the Security
Policy Database of the participant.
3 Syntax
The formatting of the qos attribute is described by the following
BNF:
qos-attribute = ``a=qos:'' strength-tag SP direction-tag
strength-tag = (``mandatory'' |''optional'')
direction-tag = (``send'' | ``recv'' | ``sendrecv'')
and the security attribute:
security-attribute = ``a=secure:'' SP strength-tag SP direction-tag
J.Rosenberg,H.Schulzrinne,S.Donovan [Page 4]
Internet Draft SDP QoS June 19, 1999
The following example shows an SDP description carried in a SIP
INVITE message from A to B:
v=0
o=mhandley 2890844526 2890842807 IN IP4 126.16.64.4
s=SDP Seminar
i=A Seminar on the session description protocol
u=http://www.cs.ucl.ac.uk/staff/M.Handley/sdp.03.ps
e=mjh@isi.edu (Mark Handley)
c=IN IP4 224.2.17.12/127
t=2873397496 2873404696
m=audio 49170 RTP/AVP 0
a=qos:mandatory recv
m=video 51372 RTP/AVP 31
a=secure:mandatory sendrecv
m=application 32416 udp wb
a=orient:portrait
a=qos:optional sendrecv
a=secure:optional sendrecv
This SDP indicates that B should not continue its involvement in the
session until resources for the audio are reserved from B to A, and a
bi-directional security association is established for the video. B
can join the sessions once these preconditions are met, but should
reserve resources and establish a bidirection security association
for the whiteboard.
4 Usage with SIP
4.1 Overview
In the case of SIP, the caller prepares an SDP message body for the
INVITE describing their desired QoS and security preconditions, and
the desired directions. For SIP, send means the direction of media
from originator (whichever entity created the SDP) to recipient
(whichever entity received the SDP in a SIP message), and recv is
from recipient to originator. In an INVITE, the UAC is the
originator, and the UAS is the recipient. The roles are reversed in
the response.
If the recipient of the INVITE (UAS) is capable and willing to
perform the coupling (by coupling, we mean making the security and
QoS establishment a precondition to session participation), it MUST
return either a 180 or 183 (hereby referred to as 180/3) response
containing SDP, along with the qos attribute, for each coupled
stream. This SDP MUST be a subset of the preconditions indicated in
the INVITE. Unlike normal SIP processing, the UAS MUST NOT alert the
J.Rosenberg,H.Schulzrinne,S.Donovan [Page 5]
Internet Draft SDP QoS June 19, 1999
called user at this point (unless the SDP in the 180/3 indicated no
mandatory coupled streams).
Table 1 illustrates the allowed values for the coupling tag in the
180/3. Each row represents a value of the coupling in the INVITE, and
each column the value in the 180/3. An entry of N/A means that this
combination is not allowed. A value of A->B (B->A) implies that the
coupling is for resources reserved (or security established) from A
to B (B to A). A value of A<->B means that the coupling is for
resource reservation or security establishment in both directions.
The value in the response is the one used by both parties.
B: 180 or 183
_______________________________________________
A: INV send recv sendrecv none
_______________________________________________
send N/A A->B N/A --
recv B->A N/A N/A --
sendrecv A->B B<-A A<->B --
none -- -- -- --
Table 1: Allowed values of coupling
Table 2 illustrates the allowed values for the strength tag in the
request and response. A "Y" means the combination is allowed, and a
"N" means it is not. The value in the response is the one used by
both parties.
B: 180 or 183
__________________________________________
A: INV mandatory optional none
__________________________________________
mandatory Y Y Y
optional N Y Y
none N N Y
Table 2: Allowed values of strength parameter
The 180/3 is received by the UAC. The UAC should treat a 180/3
without SDP, or with SDP and without any qos parameters in any
stream, as an indication that the callee is unable or unwilling to
couple. As such, it should proceed with normal call setup procedures.
If the 180/3 contained SDP with mandatory qos parameters, the UAC
J.Rosenberg,H.Schulzrinne,S.Donovan [Page 6]
Internet Draft SDP QoS June 19, 1999
SHOULD NOT generate local ringback (in the case of 180), or play
media from the remote party (in the case of 183) until the mandatory
preconditions are met.
Once preconditions are met, the UAS alerts the user, and the UAC
either provides ringback (in the case that a 180 was received) or
plays media from the remote party (in the case of 183), and the SIP
transaction completes normally.
Note that this extension requires usage of reliable provisional
responses [10]. This is because the 180/3 contains SDP with
information required for the caller to initiate reservations from it
towards the callee.
4.2 Details for RSVP
Assuming the callee has inserted the qos tag in the 180/3 and sent
it, it should immediately start generating PATH messages for each
stream it marked as send or sendrecv in the 180/3 (both mandatory and
optional). When the RESV message for the stream arrives at the
callee, the callee makes note of it. When RESV messages have arrived
for all mandatory streams which the callee marked as send, and if the
callee didn't mark any mandatory streams as sendrecv or recv, it
alerts the user.
When the caller receives the SDP in the 180/3, it immediately begins
sending PATH messages for all streams marked as recv or sendrecv in
the 180/3.
The caller will begin to receive PATH messages from the callee for
streams marked in the 180/3 as send or sendrecv. The caller SHOULD
begin sending RESV messages for these streams. Reservation
confirmations MUST be requested.
The callee will begin to receive these PATH messages from the caller.
It should send RESV messages for these streams. Reservation
confirmations MUST be requested.
The caller should either generate local ringback (in the case of 180)
or media from streams it receives (in the case of 183) when the
following conditions are met:
o For all streams marked as mandatory recv in the 180/3, a RESV
was received
o For all streams marked as mandatory send in the 180/3, a
reservation confirmation was received
J.Rosenberg,H.Schulzrinne,S.Donovan [Page 7]
Internet Draft SDP QoS June 19, 1999
o For all streams marked as mandatory sendrecv, a RESV and
reservation confirmation were received
The callee should begin to generate local ringback once all the
following conditions are met:
o For all streams marked as mandatory recv in the 180/3, a
reservation confirmation was received
o For all streams marked as mandatory send in the 180/3, a RESV
was received
o For all streams marked as mandatory sendrecv, a RESV and a
reservation confirmation were received
These rules basically ensure that ringing occurs only after all
required reservations have been made. In the case of bidirectional
reservations, the call setup requires 3.5 RTT (as compared to 1.5
without any preconditions).
4.2.1 Examples
The basic message flow for a case where the caller marks a single
audio stream as sendrecv, and the callee marks the 180/3 as sendrecv,
is shown in Figure 1.
A B
----------INV----------------->
<------180 w/SDP---------------
<.....PATH..B2A................
..........RESV.B2A............>
..........PATH.A2B............>
<,,,,,,,,RESVCONF B2A,,,,,,,,,,
LOCAL RB <........RESV...A2B............
,,,,,,,,,,,,RESVCONF A2B,,,,,,> RINGING
<--------------- 200 OK--------
--------------ACK ------------>
J.Rosenberg,H.Schulzrinne,S.Donovan [Page 8]
Internet Draft SDP QoS June 19, 1999
In the next example, there is a bidirectional audio stream from A to
B. However, the caller (A) adds the qos attribute, but indicates only
recv coupling. This means audio flows in both directions, but the SIP
and RSVP are tied together only for reservations from B to A. The
call flow is:
A B
----------INV----------------->
<------180 w/SP----------------
<.....PATH..B2A................
..........RESV.B2A............> RINGING
..........PATH.A2B............>
LOCAL RB <,,,,,,,,RESVCONF B2A,,,,,,,,,,
<--------------- 200 OK--------
<........RESV...A2B............
,,,,,,,,,,,,RESVCONF A2B,,,,,,>
--------------ACK ------------>
Note that in this example, the ringing at B occurs after the B to A
reservation has completed. There is still an A to B reservation, but
it takes place on slower time scales, and is not coupled to the SIP
messaging. Similarly, A alerts the user with local ringback when the
B to A confirmation has been received, but before the A to B
reservation has been received.
In the next example, the caller has a single bidirectional audio
stream which it marks with sendrecv coupling. However, the called
party (B) doesn't understand this attribute. So, its 180/3 contains
no SDP. The caller realizes that the callee doesn't understand the
coupling, and proceeds with normal setup. As such, it provides local
ringback immediately. The call flow is thus:
A B
----------INV-----------------> RINGING
J.Rosenberg,H.Schulzrinne,S.Donovan [Page 9]
Internet Draft SDP QoS June 19, 1999
LOCAL RB <------180 w/o SDP-------------
<--------------- 200 OK--------
--------------ACK ------------>
5 Usage with SAP
5.1 QoS Preconditions with RSVP
In the case of send coupling, a session participant should not play
out audio for a stream until resources have been reserved for it.
Session senders SHOULD send PATH messages, and participants should
send RESV messages for those streams. A participant should not play
out audio until reservation confirmations are received. Thus, if a
participant receives audio from a new source, it does not play that
audio out until it has seen a PATH message, sent a reservation for
it, and gotten a confirmation.
In the case of receive coupling, a session participant should not
actually send audio until it has gotten at least one reservation for
that audio stream. A participant should therefore send PATH messages
before sending media. In most cases, since reservations are shared, a
sender will only see a single RESV message anyway.
In the case of sendrecv coupling, a participant follows both
procedures above.
5.2 Security Preconditions with IPSEC
Since SAP is primarily used for announcing multicast sessions, and
IPSEC does not currently support multicast, a SAP session originator
MUST NOT mark any streams with security preconditions.
6 SIP Extensions
There are two behaviors a UA might take when some of the mandatory
pre-conditions fail. In the first case, the UA proceeds with the call
anyway. In the second case, the UA attempts to terminate the call.
Different applications will require differing behaviors. To support
either, we define a new SIP header, called Failure-Conditions. This
header contains a list of tokens, each of which indicates a normally
non-fatal condition which MUST cause a failure for this request. As
with other SIP headers containing lists of tokens, the header may
appear multiple times in a message. The header is both a request
header and response header. When used in a request, it indicates the
server SHOULD return a 500 class response to the request, should any
J.Rosenberg,H.Schulzrinne,S.Donovan [Page 10]
Internet Draft SDP QoS June 19, 1999
of the indicated conditions occur. When used in a response, it
indicate that the client SHOULD send a BYE for this call, should any
of the indicated conditions occur.
The syntax for this header is:
Failure-Conditions = ``Failure-Conditions'' ``:'' 1#fconditions
fconditions = (``qos'' | ``security'' | token)
When the value qos is present in a request, the UAS should respond
with a 500 class message if any mandatory reservation fails. When the
value qos is present in a response, the UAC should send a BYE for
this call should any mandatory reservations fail. When the value
security is present in a request, the UAS should respond with a 500
class response if any mandatory security channel cannot be
established. Similarly, if the the security value is present in a
response, the UAC should send a BYE for this call should any
mandatory security channels fail to be established.
When a condition is not listed, the request should not fail (or a BYE
should not be sent), if the condition was a mandatory condition, and
it failed.
The SIP extension SHOULD be used in conjunction with a Require
header. This extension is named org.ietf.sip.fail.
There may be other extensions and mechanisms for SIP that support the
SDP mechanisms described here.
7 Open Issues
There are many open issues:
o The SIP rules assume unicast. What about multicast?
o The SIP rules are only for the case of original INVITE. What
about re-INVITEs? What about original INVITE's with no SDP at
all, or SDP with no m lines?
o How is changing of the qos and security attributes in re-
INVITEs handled?
o Are the SIP rules too complex? Should we eliminate the various
send, recv, and sendrecv flavors, and make it "all or
nothing"?
J.Rosenberg,H.Schulzrinne,S.Donovan [Page 11]
Internet Draft SDP QoS June 19, 1999
o The mechanism works assuming that an end system application
actually sees both reservations and reservation confirmations.
Is this true? Do the APIs for RSVP allow an application to
know when these have occurred?
o What about usage of SDP with RTSP? Megaco?
o More details on ipsec are needed.
o How long should each party wait for reservations to succeed
before giving up and aborting the call?
8 Acknowledgements
The authors wish to thank Jonathan Lennox for his valuable comments
on this proposal.
9 Authors Addresses
Jonathan Rosenberg
Lucent Technologies, Bell Laboratories
101 Crawfords Corner Rd.
Holmdel, NJ 07733
Rm. 4C-526
email: jdrosen@bell-labs.com
Henning Schulzrinne
Columbia University
M/S 0401
1214 Amsterdam Ave.
New York, NY 10027-7003
email: schulzrinne@cs.columbia.edu
Steve Donovan
MCI Worldcom
1493/678
901 International Parkway
Richardson, Texas 75081
email: steven.r.donovan@mci.com
10 Bibliography
[1] M. Handley and V. Jacobson, "SDP: session description protocol,"
Request for Comments (Proposed Standard) 2327, Internet Engineering
J.Rosenberg,H.Schulzrinne,S.Donovan [Page 12]
Internet Draft SDP QoS June 19, 1999
Task Force, Apr. 1998.
[2] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP:
session initiation protocol," Request for Comments (Proposed
Standard) 2543, Internet Engineering Task Force, Mar. 1999.
[3] R. Braden, Ed., L. Zhang, S. Berson, S. Herzog, and S. Jamin,
"Resource ReSerVation protocol (RSVP) -- version 1 functional
specification," Request for Comments (Proposed Standard) 2205,
Internet Engineering Task Force, Sept. 1997.
[4] P. P. Pan and H. Schulzrinne, "YESSIR: A simple reservation
mechanism for the Internet," (Cambridge, England), July 1998. also
IBM Research Technical Report TC20967.
[5] S. Kent and R. Atkinson, "Security architecture for the internet
protocol," Request for Comments (Proposed Standard) 2401, Internet
Engineering Task Force, Nov. 1998.
[6] P. Sijben and M. Buckley, "Establishing and controlling end-to-
end qos in tiphon systems," (tiphon temporary document), ETSI Tiphon,
May 1999. 13TD109.
[7] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP: a
transport protocol for real-time applications," Request for Comments
(Proposed Standard) 1889, Internet Engineering Task Force, Jan. 1996.
[8] M. Handley, C. Perkins, and E. Whelan, "Session announcement
protocol," Internet Draft, Internet Engineering Task Force, June
1999. Work in progress.
[9] P. Goyal, A. Greenberg, C. Kalmanek, B. Marshall, P. Mishra, D.
Nortz, and K. K. Ramakrishnan, "Integration of call signaling and
resource management for ip telephony," vol. 13, May/June 1999.
[10] J. Rosenberg and H. Schulzrinne, "Reliability of provisional
responses in SIP," Internet Draft, Internet Engineering Task Force,
May 1999. Work in progress.
J.Rosenberg,H.Schulzrinne,S.Donovan [Page 13]
Html markup produced by rfcmarkup 1.129d, available from
https://tools.ietf.org/tools/rfcmarkup/