One document matched: draft-beser-mmusic-capabilities-00.txt
B. Beser
Internet Draft 3Com
Document: draft-beser-mmusic-capabilities-00.txt March 2000
Category: Informational
Codec Capabilities Attribute for SDP
Status of this Memo
This document is an Internet-Draft and is NOT offered in accordance
with Section 10 of RFC2026 [1], and the author does not provide the
IETF with any rights other than to publish as an Internet-Draft
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.
1. Abstract
The need for assured communication arisen protocols like RSVP [2]
and SBM [3] which are linked to access technologies to guarantee the
delay and drop probabilities of a given IP flow.
One of the side-effects of the assurance is that when the bandwidth
of the IP flow goes outside the contracted region then the IP flow
will be disturbed and the communication will be effected.
This document discusses the effects of assured communication to SDP
protocol, identifies the weaknesses and proposes a new attribute to
rectify these weaknesses.
2. 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 RFC-2119 [4].
Internet Draft draft-beser-mmusic-capabilities-00.txt March 2000
4. Introduction
The introduction of commercial services (e.g. VoIP) brought along
with the quality concept. Although the quality has many dimensions
one of the basic aspects of quality is the packet delay and drop
probabilities.
Resource Reservation Protocol (RSVP) answers these basic QoS
requirements by making a contract with the client. Using RSVP
protocol the client defines its IP flow using a set of filters and
defines its IP flow by using a set of measures.
When the Router accepts the contract it is assumed that as far as
the client is within the contracted parameters it will get the
requested QoS.
The Session Description Protocol [5] which is designed for the
advertisement of conference sessions and communicate the relevant
conference setup information to recipients. SDP by definition does
not contain elements that would enable the end-points for media
encoding negotiations.
In this document a new attribute Codec Capabilities is defined such
that end-points will know codec choices at the same time having
definite codec(s) agreed for communication.
5. The Current SDP Codec Communication
Several drafts are written to identify and solve problems involving
QoS setup in IP telephony [6, 7, 8]. In all of the drafts that are
cited it is assumed that the both ends of communication will have a
solid understanding of which codec the other side will use.
For example consider the call flow of Figure 1 which is taken from
[6] which uses SIP messaging [9].
A B
----------INV-(1)------------>
<------180 w/SDP-(2)-----------
<.....PATH..B2A................
..........RESV.B2A............>
..........PATH.A2B............>
<,,,,,,,,RESVCONF B2A,,,,,,,,,,
LOCAL RB <........RESV...A2B............
,,,,,,,,,,,,RESVCONF A2B,,,,,,> RINGING
<--------------- 200 OK-(3)----
--------------ACK ------------>
Internet Draft draft-beser-mmusic-capabilities-00.txt March 2000
For the case of simplicity lets assume that both A and B has two
codec's G.726 for voice communications and G.711 for fax and modem.
In this case the SIP messages INVITE, 183 and 200 OK will contain
the following SDP's.
INVITE (1) SDP:
v=0
o=MotherShip 2987933615 2987933615 IN IP4 1.2.3.4
s=TakeMeHome
c=IN IP4 224.2.17.12/127
t=907165245 0
m=audio 49170 RTP/AVP 0 96
a=rtpmap:0 PCMU/8000
a=rtpmap:96 G726-32/8000
a=qos:mandatory sendrecv
183 (2) SDP:
v=0
o=MotherShip 2987933615 2987933615 IN IP4 1.2.3.4
s=WannaGoHome
c=IN IP4 224.2.17.12/127
t=907165245 0
m=audio 49170 RTP/AVP 0 96
a=rtpmap:0 PCMU/8000
a=rtpmap:96 G726-32/8000
a=qos:mandatory sendrecv
200OK (3) SDP:
v=0
o=MotherShip 2987933615 2987933615 IN IP4 1.2.3.4
s=WannaGoHome
c=IN IP4 224.2.17.12/127
t=907165245 0
m=audio 49170 RTP/AVP 0 96
a=rtpmap:0 PCMU/8000
a=rtpmap:96 G726-32/8000
a=qos:mandatory sendrecv
At the end of the messaging both of the ends have information
regarding both ends, meaning G.711 and G.726 codecs.
The problem is that if both ends does not have any kind of pre-
agreement than although both ends will use 8Kb/s bandwidth they has
to reserve 64Kb/s since they cannot control when will the other end
switch to the high bandwidth codec. Which would mean that there will
be an over-reservation of 56Kb/s.
Internet Draft draft-beser-mmusic-capabilities-00.txt March 2000
6. Codec Capabilities
The _m=_ Media Announcements has double interpretations: first it
contains the capabilities of the receiver, and second it contains
the expected Codec(s) at the same time.
The proposed attribute codec Capabilities takes the double meaning
from Media Announcements. Codec Capabilities shows to the other end
the originators capabilities and preferences.
7. Definition
The Codec Capabilities attribute is defined as:
a= cap: <media> <port> <transport> <Codec Capabilities List>
The definitions of <media> <port> and <transport> are the same as
Media Announcement and they are used for identifying the correct
media announcement for the cases that there are more than one media
announcement.
The <Codec Capabilities> is an preference list containing:
<Codec Capabilities List>
= <Payload Type>["/"<Direction>["/"<Group>]]
The leftmost item in the list is the most desired codec to be used
with the order of decreasing reference moving right in the list.
The <Payload Type> contains the payload types that the originator is
willing to send and/or receive.
The <Direction> field is optional and if exists it MUST contain one
of the following:
r: if the client is willing to receive (default).
s: if the client is willing to send.
a: if the client is willing to send and/or receive.
b: if the client is willing to both send and receive.
The nonexistence of <Direction> field means the client is willing to
receive.
The difference between "a" and "b" is the fact that if "a" is used
it is possible for a media exchange in one direction and with a
different selection in the other direction. If "b" is to be used the
media exchange can only take place if both directions use the same
codec type.
The <Group> field is optional and if exists it is used for tying
multiple media streams together. If there is no grouping for the
payload type than either 0 SHOULD be used or the field MUST be
omitted.
Internet Draft draft-beser-mmusic-capabilities-00.txt March 2000
8. Examples
8.1. IP Telephony
If the previous example is to be re-written:
INVITE SDP:
v=0
o=MotherShip 2987933615 2987933615 IN IP4 1.2.3.4
s=WannaGoHome
c=IN IP4 224.2.17.12/127
t=907165245 0
m=audio 49170 RTP/AVP 0
a=cap: audio 49170 RTP/AVP 0/a/0 96/a/0
a=rtpmap:0 PCMU/8000
a=rtpmap:96 G726-32/8000
a=qos:mandatory sendrecv
183 SDP:
v=0
o=MotherShip 2987933615 2987933615 IN IP4 1.2.3.4
s=WannaGoHome
c=IN IP4 224.2.17.12/127
t=907165245 0
m=audio 49170 RTP/AVP 0
a=cap: audio 49170 RTP/AVP 0/a/0 96/a/0
a=rtpmap:0 PCMU/8000
a=rtpmap:96 G726-32/8000
a=qos:mandatory sendrecv
200OK SDP:
v=0
o=MotherShip 2987933615 2987933615 IN IP4 1.2.3.4
s=WannaGoHome
c=IN IP4 224.2.17.12/127
t=907165245 0
m=audio 49170 RTP/AVP 0
a=cap: audio 49170 RTP/AVP 0/a/0 96/a/0
a=rtpmap:0 PCMU/8000
a=rtpmap:96 G726-32/8000
a=qos:mandatory sendrecv
8.2. UAS with Limited Processing Power
If the UAS has limited processing power and cannot handle both
sending and receiving of low bandwidth codecs simultaneously then
the SDP will be:
INVITE SDP:
v=0
o=MotherShip 2987933615 2987933615 IN IP4 1.2.3.4
s=WannaGoHome
Internet Draft draft-beser-mmusic-capabilities-00.txt March 2000
c=IN IP4 224.2.17.12/127
t=907165245 0
m=audio 49170 RTP/AVP 0
a=cap: audio 49170 RTP/AVP 0/b/0 96/s/1 0/r/1 0/s/2 96/r/2
a=rtpmap:0 PCMU/8000
a=rtpmap:96 G726-32/8000
a=qos:mandatory sendrecv
8.3. Sending Capabilities without Tying the Originator Codec
In all of the examples above the originator set the Codec it wants
to receive without knowing the other ends capabilities. The only way
to achieve this is to have symmetric codec definition for bth send
and receive dircetions such that the receiving end chooses the codec
for both directions. The SDP exchange will be:
INVITE SDP:
v=0
o=MotherShip 2987933615 2987933615 IN IP4 1.2.3.4
s=WannaGoHome
c=IN IP4 224.2.17.12/127
t=907165245 0
m=audio 49170 RTP/AVP 0 96
a=cap: audio 49170 RTP/AVP 0/b/0 96/b/0
a=rtpmap:0 PCMU/8000
a=rtpmap:96 G726-32/8000
a=qos:mandatory sendrecv
183 SDP:
v=0
o=MotherShip 2987933615 2987933615 IN IP4 1.2.3.4
s=WannaGoHome
c=IN IP4 224.2.17.12/127
t=907165245 0
m=audio 49170 RTP/AVP 0
a=cap: audio 49170 RTP/AVP 0/a/0 96/a/0
a=rtpmap:0 PCMU/8000
a=rtpmap:96 G726-32/8000
a=qos:mandatory sendrecv
At the end of 183 exchange both ends has the codec(s) that will be
used both directions for media exchange, and originator has the
knowledge that the terminating end can support any codec
combination, and the preferred codec is G.726.
8.4. Codec change
The codec change by the consent of other end can be achieved by
changing the first payload type defined in the Codec Capablities
List. If the above example the originator decides that both ends
should change to a lower bandwidth codec G726 then the SDP exchange
will be:
Internet Draft draft-beser-mmusic-capabilities-00.txt March 2000
INVITE SDP:
v=0
o=MotherShip 2987933615 2987933615 IN IP4 1.2.3.4
s=WannaGoHome
c=IN IP4 224.2.17.12/127
t=907165245 0
m=audio 49170 RTP/AVP 0
a=cap: audio 49170 RTP/AVP 96/b/0 0/b/0
a=rtpmap:0 PCMU/8000
a=rtpmap:96 G726-32/8000
a=qos:mandatory sendrecv
183 SDP:
v=0
o=MotherShip 2987933615 2987933615 IN IP4 1.2.3.4
s=WannaGoHome
c=IN IP4 224.2.17.12/127
t=907165245 0
m=audio 49170 RTP/AVP 96
a=cap: audio 49170 RTP/AVP 0/a/0 96/a/0
a=rtpmap:0 PCMU/8000
a=rtpmap:96 G726-32/8000
a=qos:mandatory sendrecv
Notice that the terminating end still shows its preference for the
higher bandwidth lower processing power codec keeping the preference
list the same.
8.5. Rejection of Codec Change
If in the above example the other end is to reject the request
because it does not have processing power than it would reply with
SDP:
183 SDP:
v=0
o=MotherShip 2987933615 2987933615 IN IP4 1.2.3.4
s=WannaGoHome
c=IN IP4 224.2.17.12/127
t=907165245 0
m=audio 49170 RTP/AVP 0
a=cap: audio 49170 RTP/AVP 0/a/0 96/a/0
a=rtpmap:0 PCMU/8000
a=rtpmap:96 G726-32/8000
a=qos:mandatory sendrecv
In the above SDP the G.726 is still retained in the capabilities but
it is possible for the other end not to use the codec anymore which
would result with the SDP:
183 SDP:
Internet Draft draft-beser-mmusic-capabilities-00.txt March 2000
v=0
o=MotherShip 2987933615 2987933615 IN IP4 1.2.3.4
s=WannaGoHome
c=IN IP4 224.2.17.12/127
t=907165245 0
m=audio 49170 RTP/AVP 0
a=cap: audio 49170 RTP/AVP 0/a/0
a=rtpmap:0 PCMU/8000
a=rtpmap:96 G726-32/8000
a=qos:mandatory sendrecv
8.6. Tying Multiple Media Types
If there is a limited bandwidth between two end-points that is not
sufficient for both high quality high bandwidth voice Codec and
Video communications. Than the definition of SDP will be:
High Quality Voice:
v=0
o=MotherShip 2987933615 2987933615 IN IP4 1.2.3.4
s=WannaGoHome
c=IN IP4 224.2.17.12/127
t=907165245 0
m=audio 49170 RTP/AVP 99
a=cap: audio 49170 RTP/AVP 99/a/0 0/a/1
a=rtpmap:0 PCMU/8000
a=rtpmap:99 VeryHighQualityCodec/64000
a=qos:mandatory sendrecv
a=cap: video 51372 RTP/AVP 31 b 1
Both Voice and Video:
INVITE:
v=0
o=MotherShip 2987933615 2987933615 IN IP4 1.2.3.4
s=WannaGoHome
c=IN IP4 224.2.17.12/127
t=907165245 0
m=audio 49170 RTP/AVP 99
a=cap: audio 49170 RTP/AVP 0/a/1 99/a/0
a=rtpmap:0 PCMU/8000
a=rtpmap:99 VeryHighQualityCodec/64000
a=qos:mandatory sendrecv
a=cap: video 51372 RTP/AVP 31 b 1
183/200:
v=0
o=MotherShip 2987933615 2987933615 IN IP4 1.2.3.4
s=TakeMeHome
c=IN IP4 224.2.17.12/127
t=907165245 0
m=audio 49170 RTP/AVP 0
a=cap: audio 49170 RTP/AVP 0/a/1 99/a/0
a=rtpmap:0 PCMU/8000
a=rtpmap:99 VeryHighQualityCodec/64000
Internet Draft draft-beser-mmusic-capabilities-00.txt March 2000
a=qos:mandatory sendrecv
m= video 51372 RTP/AVP 31 b 1
a=cap: video 51372 RTP/AVP 31 b 1
9. Security Considerations
If the contents of the SDP contained in the messages are private
then end-to-end encryption of the message body can be used to
prevent unauthorized access to the content.
10. References
1. Bradner, S., "The Internet Standards Process -- Revision 3", BCP
9, RFC 2026, October 1996.
2. RFC 2210, The Use of RSVP with IETF Integrated Services by J.
Wroclawski, September 1997.
3. SBM (Subnet Bandwidth Manager): A Protocol for RSVP-based
Admission Control over IEEE 802-style networks by Raj Yavatkar,
Don Hoffman, Yoram Bernet, Fred Baker and Michael Speer.
Internet-Draft, work in progress, May 1999.
4. Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
5. M. Handley and V. Jacobson, "SDP: session description protocol,
"Request for Comments (Proposed Standard) 2327, Internet
Engineering
6. Rosenberg, J., Schulzrinne,H., Donovan S., _Establishing QoS and
Security Preconditions for SDP Sessions_, Internet Draft, April
1998
7. Manyfolks, " Integration of Resource Management and SIP for IP
Telephony", draft-manyfolks-sip-resource-00.txt, March 2000.
8. Sinnreich, H., Donovan, S., Rawlins, D., Thomas, S., _IP
Communication with QoS, Authorization and Usage Reporting_,
draft-sinnreich-sip-qos-sp-00.txt, October 1999.
9. 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.
11. Acknowledgments
I would like to extend a heartfelt thanks to all those who
contributed to the development of PacketCable DCS specification.
Particular thanks are given Mike Mannette, Kurt Steinbrenner (3Com);
Dave Boardman (Arris), K.K. Ramakrishnan, Bill Marshall, Doug Nortz,
Chuck Kalmanek, and Tung-Hai Hsiao (AT&T); Dave Oran, Bill Guckel,
Flemming Andreasen and Michael Ramalho (Cisco); John Pickens
(Com21); D.R. Evans (Lucent Cable Communications); Poornima
Internet Draft draft-beser-mmusic-capabilities-00.txt March 2000
Lalwaney, Jon Fellows, John Wheeler (Motorola); Keith Kelly
(NetSpeak); Edward Miller, and Glenn Russell (CableLabs).
11. Author's Address
Burcak Beser
3Com
Mount Prospect, IL 60056
Email: Burcak_Beser@3com.com
Internet Draft draft-beser-mmusic-capabilities-00.txt March 2000
| PAFTECH AB 2003-2026 | 2026-04-24 03:22:23 |