One document matched: draft-garcia-mmusic-sdp-cs-00.txt
MMUSIC WG M. Garcia-Martin
Internet-Draft S. Veikkolainen
Intended status: Standards Track Nokia Siemens Networks
Expires: August 21, 2008 February 18, 2008
Describing CS audio streams in the Session Description Protocol (SDP)
draft-garcia-mmusic-sdp-cs-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 August 21, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Abstract
This memo describes use cases and requirements for controlling
circuit-switched media streams using the Session Description Protocol
(SDP). Additional, it proposes conventions on how to use SDP and the
SDP capability negotiation framework for agreeing on alternative
media streams between the endpoints.
Garcia-Martin & Veikkolainen Expires August 21, 2008 [Page 1]
Internet-Draft CS audio streams in SDP February 2008
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Document Conventions . . . . . . . . . . . . . . . . . . . . . 4
3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. General Requirements . . . . . . . . . . . . . . . . . . . 4
3.2. Media-specific requirements . . . . . . . . . . . . . . . 5
4. Overview of operation . . . . . . . . . . . . . . . . . . . . 5
4.1. Example call flow . . . . . . . . . . . . . . . . . . . . 5
5. Protocol Description . . . . . . . . . . . . . . . . . . . . . 6
5.1. Extensions to SDP . . . . . . . . . . . . . . . . . . . . 6
5.1.1. Connection Data . . . . . . . . . . . . . . . . . . . 7
5.1.2. Media Descriptions . . . . . . . . . . . . . . . . . . 7
5.2. Offering alternative media streams . . . . . . . . . . . . 9
5.3. Determining the direction of the circuit-switched
connection setup . . . . . . . . . . . . . . . . . . . . . 12
5.4. Formal syntax . . . . . . . . . . . . . . . . . . . . . . 12
6. SDP Examples . . . . . . . . . . . . . . . . . . . . . . . . . 14
6.1. Basic SDP example: Single Circuit-Switched Audio Stream . 14
6.1.1. CS audio stream as an alternative to RTP . . . . . . . 14
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
7.1. Registration of a new "nettype" value . . . . . . . . . . 15
7.2. Registration of new "addrtype" values . . . . . . . . . . 15
7.3. Registration of a new "proto" value . . . . . . . . . . . 15
8. Security Considerations . . . . . . . . . . . . . . . . . . . 16
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
10.1. Normative References . . . . . . . . . . . . . . . . . . . 16
10.2. Informative References . . . . . . . . . . . . . . . . . . 17
Appendix A. Design Alternatives . . . . . . . . . . . . . . . . . 17
A.1. Analysis of alternative conventions for describing
circuit-switched audio media streams in SDP . . . . . . . 18
A.1.1. Grouping of media lines . . . . . . . . . . . . . . . 18
A.1.2. Alternative network types . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
Intellectual Property and Copyright Statements . . . . . . . . . . 21
Garcia-Martin & Veikkolainen Expires August 21, 2008 [Page 2]
Internet-Draft CS audio streams in SDP February 2008
1. Introduction
The Session Description Protocol (SDP) [RFC4566] is intended for
describing multimedia sessions for the purposes of session
announcement, session invitation, and other forms of multimedia
session initiation. SDP is most commonly used for describing media
streams that are transported over the Real-Time Transport Protocol
(RTP) [RFC3550], using the profiles for audio and video media defined
in RTP Profile for Audio and Video Conferences with Minimal Control
[RFC3551].
However, SDP can be used to describe other transport protocols than
RTP. Previous work includes SDP conventions for describing ATM
bearers [RFC3108] and the Message Session Relay Protocol [RFC4975].
SDP is commonly carried in Session Initiation Protocol (SIP)
[RFC3261] messages in order to agree on a common media description
among the endpoints. An Offer/Answer Model with Session Description
Protocol (SDP) [RFC3264] defines a framework by which two endpoints
can exchange SDP media descriptions and come to an agreement as to
which media streams should be used, along with the media related
parameters.
In some scenarios it might be desirable to establish the media stream
over a circuit-switched bearer even if the signaling for the session
is carried over an IP bearer. An example of such a scenario is two
mobile devices capable of both circuit-switched and packet-switched
communication over a low-bandwidth radio bearer. The radio bearer
may not be suitable for carrying real-time audio media, and using a
circuit-switched bearer would offer a better perceived quality of
service. So, according to this scenario, SIP is used over regular IP
connectivity, while the audio is received through the classical
circuit-switched bearer. Additional media streams, such as text
messaging can also be used over the IP bearer.
At a later point in time the mobile device might move to an area
where a high-bandwidth packet-switched bearer, for example a Wireless
Local Are Network (WLAN) connection, is available. At this point the
mobile device may perform a handover and move the audio media streams
over to the high-speed bearer. This implies a new exchange of SDP
offer/answer that least to a re-negotiation of the media streams.
Other use cases exists. For example, and endpoint might have at its
disposal circuit-switch and packet-switched connectivity, but the
audio codecs are not the same in both access networks. Consider that
the circuit-switched audio stream supports narrow-bandwidth codecs,
while the packet-switched access allows any other audio codec
implemented in the endpoint. In this case, it might be beneficial
Garcia-Martin & Veikkolainen Expires August 21, 2008 [Page 3]
Internet-Draft CS audio streams in SDP February 2008
for the endpoint to describe different codecs for each access type
and get an agreement on the bearer together with the remote endpoint.
The rest of the document is structured as follows: Section 2 provides
the document conventions, Section 3 introduces the requirements,
Section 4 presents an overview of the proposed solutions, and
Section 5 contains the protocol description. Section 6 provide a few
examples of descriptions of circuit-switched audio streams in SDP.
Section 7 and Section 8 contain the IANA and Security considerations,
respectively.
2. Document Conventions
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 BCP 14, RFC 2119
[RFC2119] and indicate requirement levels for compliant
implementations.
3. Requirements
3.1. General Requirements
This section presents the general requirements that are specific for
the circuit-switched audio media stream.
REQ-GEN-1: A mechanism for endpoints to negotiate and agree on a
circuit-switch bearer for audio media must be available.
REQ-GEN-2: The mechanism must allow the endpoints to combine
circuit-switched audio media streams with other
complementary media streams, for example, text messaging.
REQ-GEN-3: An endpoint might be able to offer an audio stream where
the circuit-switched bearer is an alternative to the IP
bearer, and vice versa.
REQ-GEN-4: The mechanism must be backwards compatible with SDP
[RFC4566] and the SDP Offer/Answer Model [RFC3264] in the
sense that if an endpoint offers a description of a
circuit-switched audio stream in addition to a classical
RTP-based audio stream, and the other endpoint supports
only the classical RTP, then both endpoints can agree on
the RTP-based audio stream, according to the rules in SDP
offer/answer [RFC3264], and communication may still be
possible.
Garcia-Martin & Veikkolainen Expires August 21, 2008 [Page 4]
Internet-Draft CS audio streams in SDP February 2008
3.2. Media-specific requirements
This section presents the requirements that are specific for the
circuit-switched audio media.
REQ-CS-1: It must be possible for endpoints to advertise a circuit-
switch audio stream with a different list of audio codecs
from those used in a packet-switched audio stream.
REQ-CS-2: It must be possible for endpoints to not advertise the
list of available codecs for circuit-switched audio
streams.
REQ-CS-3: There must be a mechanism that helps an endpoint to
correlate an incoming CS call with the one negotiated in
SDP, as opposed to another incoming call that is not
related to that.
4. Overview of operation
The mechanism defined in this memo extends SDP and allows describing
a circuit-switched media stream in SDP. Since circuit-switched
bearers are a sort of connection-oriented media streams, the
mechanism re-uses the connection-oriented extensions defined in RFC
4145 [RFC4145] to negotiate the active and passive sides of a
connection setup.
The mechanism allows expressing an audio media stream with two
separate bearers: a regular IP bearer using RTP [RFC3550] and a
circuit-switched bearer. The endpoints agree on a given bearer and
establish the media stream.
4.1. Example call flow
Consider the example presented in Figure 1. In this example, Alice
is located in an environment where she has access to both IP and
circuit-switched bearers for communicating with other endpoints.
Alice issues an SDP Offer containing two alternative audio media
stream descriptions: one that uses a circuit-switched connection, and
the other uses an IP bearer and RTP.
Garcia-Martin & Veikkolainen Expires August 21, 2008 [Page 5]
Internet-Draft CS audio streams in SDP February 2008
Alice Bob
| (1) SDP Offer (RTP and CS audio) |
|--------------------------------->|
| |
| (2) SDP Answer (CS audio) |
|<---------------------------------|
| |
| cs call setup |
|<---------------------------------|
| |
| |
|<======media over cs bearer======>|
| |
Figure 1: Example flow
Bob receives the SDP Offer and determines that he is located in an
environment where the IP based bearer is not suitable for real-time
audio media, but he has circuit-switched bearer available for audio.
Bob sends back an SDP Answer where he selects the circuit-switched
media stream description.
During the offer-answer exchange Alice and Bob also agree the
direction in which the circuit-switched connection should be
established. The exchange also contained identifiers or references
that can be used on the circuit-switched network for addressing the
other endpoint, as well as identifying that the incoming circuit-
switched connection establishment is related to the ongoing session
between Alice and Bob.
Bob establishes a circuit-switched connection towards Alice using
whatever mechanisms are defined for the network type in question.
When receiving the incoming circuit-switched connection attempt,
Alice is able to determine that the attempt is related to the session
she has with Bob.
Alice accepts the circuit-switched connection, and the circuit-
switched connection setup is completed. Bob and Alice can now use
the circuit-switched connection for two-way audio media.
5. Protocol Description
5.1. Extensions to SDP
This section provides the syntax and semantics of the extensions
required for providing a description of circuit-switched streams in
SDP.
Garcia-Martin & Veikkolainen Expires August 21, 2008 [Page 6]
Internet-Draft CS audio streams in SDP February 2008
5.1.1. Connection Data
According to SDP [RFC4566], the connection data line in SDP has the
following syntax:
c=<nettype> <addrtype> <connection-address>
where <nettype> indicates the network type, <addrtype> indicates the
address type, and the <connection-address> is the connection address,
which is dependent on the address type.
At the moment, the only network type defined is "IN", which indicates
Internet network type. The address types "IP4" and "IP6" indicate
the type of IP addresses.
This memo defines a new network type for describing circuit-switched
network type. The mnemonic "CS" is used for this network type.
For the address type, we initially consider the possibility of
describing E.164 telephone numbers. We define a new "E164" address
type. When used, the "E164" address type indicates that the
connection address contains a telephone number represented according
to the ITU-T E.164 [ITU.E164.1991] specification.
There are cases, though, when the endpoint is merely aware of a
circuit-switched bearer, without having further information about the
address type or the E.164 number allocated to it. In these cases, we
indicate with a dash "-" an unknown address type or connection
address. This makes the connection data line be according to the SDP
syntax.
Note that <addrtype> and/or <connection-address> should not be
omitted without being set to a "-" since this would violate basic
syntax of SDP [RFC4566].
The following are examples of the extension to the connection data
line:
c=CS E164 +15551234
c=CS - -
5.1.2. Media Descriptions
According to SDP [RFC4566], the media descriptions line in SDP has
the following syntax:
Garcia-Martin & Veikkolainen Expires August 21, 2008 [Page 7]
Internet-Draft CS audio streams in SDP February 2008
m=<media> <port> <proto> <fmt> ...
The <media> sub-field carries the media type. Since this document
deals with establishing an audio bearer, the currently defined
"audio" media type is used.
The <port> sub-field is the transport port to which the media stream
is sent. Circuit-switched access lacks the concept of a port number.
However, an endpoint might be capable of simultaneous circuit-
switched connections, in which case, there is a need for an
identifier so that the endpoint can have its own reference for
correlation. The <port> sub-field serves the purpose. We use the
<port> sub-field as a locally scoped circuit identification. In
circuit-switched streams the <port> is a decimal number. Most
endpoints are capable of a single circuit-switched bearer, thus, the
decimal number "1" can be used. However, any other decimal number
that is useful for the endpoint can be used as well.
The <proto> sub-field is the transport protocol. The circuit-
switched bearer uses whatever transport protocol it has available.
This subfield SHOULD be set to the mnemonic "CS" to be syntactically
correct with SDP [RFC4566] and to indicate the usage of circuit-
switched protocols.
The <fmt> sub-field is the media format description. When the
<proto> sub-field is set to "RTP/AVP" or "RTP/SAVP", the <fmt> sub-
field contains the payload types as defined in the RTP audio profile
[RFC3551].
In the case of circuit-switched descriptions, RTP is not really used.
Rather than specifying the RTP audio profile payload type, we use the
<fmt> sub-field to indicate the list of available codecs over the
circuit-switched bearer. Therefore, the <fmt> sub-field MAY indicate
one or more available audio codecs for a circuit-switched audio
stream. The namespace applicable to the <fmt> sub-field is composed
of the union of the mnemonics listed in the "encoding name" column of
the RTP Payload types for standard audio encodings and the "subtype"
column in the RTP Payload Format media types in the RTP registry
maintained by IANA.
However, in some cases, the endpoint is not able to determine the
list of available codecs for circuit-switched audio streams. In this
case, in order to be syntactically compliant with SDP [RFC4566], the
endpoint MUST include a single dash "-" in the <fmt> sub-field.
As per RFC 4566 [RFC4566], the media format descriptions are listed
in priority order.
Garcia-Martin & Veikkolainen Expires August 21, 2008 [Page 8]
Internet-Draft CS audio streams in SDP February 2008
Examples of media descriptions for circuit-switched audio streams
are:
m=audio 1 CS AMR GSM
m=audio 1 CS -
5.2. Offering alternative media streams
In many cases where circuit-switched audio streams are described in
SDP it is foreseen that CS audio streams will be an alternative to
regular RTP media streams. Therefore, it is reasonable to provide a
mechanism to define a CS audio stream as an alternative to an RTP-
based audio stream.
To offer an audio media stream with alternative bearers for RTP and
circuit-switched bearer, we reuse some of the capability attributes
defined in SDP capability negotiation
[I-D.ietf-mmusic-sdp-capability-negotiation] as well as in SDP media
capabilities negotiation [I-D.ietf-mmusic-sdp-media-capabilities].
Additionally, we define a new capability attribute "a=ccap" in this
document that allows to express a connection address as a
capabilities.
The "a=mcap" media capability attribute defined in SDP media
capabilities negotiation [I-D.ietf-mmusic-sdp-media-capabilities]
lists media formats as capabilities in the form a media type and one
or more subtypes.
An example provided in [I-D.ietf-mmusic-sdp-capability-negotiation]
lists four audio media subtypes which are numbered consecutively
(starting from 1 in this example).
a=mcap:1 audio g729 iLBC PCMU g729
Similarly, we can use the a=mcap capability attribute to indicate
media capabilities that correspond to the m-line described in
Section 5.1.2.
a=mcap:1 audio GSM AMR
Here, we declare two media subtype capabilities with associated
numbers 1 and 2, for GSM and AMR codecs, respectively.
Transport Protocols can be expressed as capabilities by the "a=tcap"
capability attribute defined in SDP capability negotiation
[I-D.ietf-mmusic-sdp-capability-negotiation]. The "a=tcap"
capability attribute lists one or more <proto> elements, defined in
Garcia-Martin & Veikkolainen Expires August 21, 2008 [Page 9]
Internet-Draft CS audio streams in SDP February 2008
SDP [RFC4566].
An example of transport protocol capability indicating "CS" transport
protocol defined in this document would thus be:
a=tcap:1 CS
In this document, we define a new capability attribute, the
connection address capability attribute, "a=ccap". The connection
address capability lists connection addresses as capabilities, and is
defined as follows:
a=ccap:<c-cap-num> <c-cap-attr> *[ <c-cap-attr>]
where <c-cap-num> is an integer between 1 and 2^31-1 (both included)
used to number the connection address capability attribute.
The <c-cap-attr> field consists of network type, address type and a
connection address, as specified for a "c=" line in SDP [RFC4566].
As an example, to list <nettype> value of "CS", <addrtype> value of
"E164", and a <connection-address> value of "+15551234" as a
connection capability attribute, we get:
a=ccap:1 CS E164 +15551234
We also define an extension to the potential configuration attribute
("a=pcfg"), originally defined in SDP capabilities negotiation
[I-D.ietf-mmusic-sdp-capability-negotiation], according to which the
'pcfg' attribute has the following definition:
a=pcfg: <config-number> [<pot-cfg-list>]
We extend the <pot-cfg-list> field to be able to convey one or more
connection capability numbers.according to the following definition:
pot-connection-config = "c=" c-cap-list *(BAR c-cap-list)
c-cap-list = c-cap-num *("," c-cap-num)
c-cap-num = 1*DIGIT
; BAR defined in SDP capabilities
; negotiation
Each potential connection configuration is a comma-separated list of
connection capability numbers where c-cap-num refers to connection
capability numbers defined explicitly by a=ccap attributes and hence
must be between 1 and 2^31-1 (both included). Alternative potential
connection configurations are separated by a vertical bar ("|").
Garcia-Martin & Veikkolainen Expires August 21, 2008 [Page 10]
Internet-Draft CS audio streams in SDP February 2008
An exmple SDP consisting of two alternative media stream is as
follows:
v=0
o=jdoe 2890844526 2890842807 IN IP4 10.47.16.5
s=
t=0 0
m=audio 49170 RTP/AVP 0 8 3
c=IN IP4 10.47.16.5
a=mcap:1 audio GSM AMR
a=tcap:1 CS
a=ccap:1 CS - -
a=pcfg:1 m=1|2 t=1 c=1
Figure 2: Example SDP with alternative media streams
In this example, the SDP defines a media capability 1 (a=mcap:1) that
uses audio media using GSM codec and an alternative media capability
2 that uses AMR, a transport capability 1 that defines CS protocol
type, as well as a connection capability 1 (a=ccap:1) that defines a
CS network type for the capability, and omits the connection address.
The potential configuration 1 consist of the media capabilities 1 or
2, transport protocol capability 1, and connection capability 1.
This is also the preferred configuration.
Note that according to the SDP capabilities negotiation framework
the potential configurations are preferred over the actual
configurations. In some use cases the offerer may want to offer
two media streams as truly alternatives, and not prefer one over
the other. Further consideration is needed to determine how this
is accomplished.
An exmple SDP answer to the offer presented in Figure 2 where CS
audio has been selected as the actual configration is as follows:
v=0
o=- 2890973824 2890987289 IN IP4 10.47.16.7
s=
t=0 0
a=csup:med-v0
m=audio 1 CS AMR
c=CS - -
a=acfg:1
Figure 3: Example SDP answer with CS audio media selected
Garcia-Martin & Veikkolainen Expires August 21, 2008 [Page 11]
Internet-Draft CS audio streams in SDP February 2008
The answer contains the "a=csup" and "a=acfg" attributes to indicate
that the answerer supports the med-v0 level of capability
negotiations as defined in SDP media capabilities negotiation
[I-D.ietf-mmusic-sdp-media-capabilities]. The answer carries the
accepted configuration in the m and c lines.
5.3. Determining the direction of the circuit-switched connection setup
The circuit-switched connection can typically be initiated by either
endpoint. In order to avoid a situation where both endpoints attempt
to initiate a connection simultaneously, the direction in which the
circuit-switched connection is set up should be negotiated during the
Offer/Answer exchange.
The framework defined in TCP-Based Media Transport in the Session
Description Protocol (SDP) [RFC4145] allows the endpoints to agree
which endpoint acts as the active endpoint when initiating a TCP
connection. The "setup" attribute defines which endpoint is the
active party and which one is the passive in setting up the circuit-
switched media stream. The "connection" attribute indicates whether
a new connection is needed, or an existing connection is reused.
While RFC 4145 was originally designed for establishing TCP
connection, it could be extended to allow other types of connections
as well, or, alternatively, a new mechanism based on the ideas
presented in RFC4145 could be developed for the purposes of
negotiating the direction of the circuit-switched connection.
5.4. Formal syntax
The following is the formal Augmented Backus-Naur Form (ABNF)
[RFC4234] syntax that supports the extensions defined in his
specification. The syntax is built above the SDP [RFC4566] grammar
and the SDP capability negotiation
[I-D.ietf-mmusic-sdp-capability-negotiation]. Implementations
according to this specification MUST implement this syntax.
; sub-rules of 'c='
connection-field = [%x63 "=" nettype SP addrtype SP
connection-address CRLF]
;a connection field must be present
;in every media description or at the
;session-level
nettype = token
;typically "IN"
;"CS" added by this spec
Garcia-Martin & Veikkolainen Expires August 21, 2008 [Page 12]
Internet-Draft CS audio streams in SDP February 2008
addrtype = token
;typically "IP4" or "
;"E164" and "-" added by this spec
connection-address = multicast-address / unicast-address /
telephone-number ; added by this spec
telephone-number = token ;token specified in RFC 4566
media-field = %x6d "=" media SP port ["/" integer]
SP proto 1*(SP fmt) CRLF
; sub-rules of 'm='
media = token
;typically "audio", "video", "text", or
;"application"
fmt = token
;typically an RTP payload type for audio
;and video media
;codec mnemonics used by this specification
proto = token *("/" token)
;typically "RTP/AVP" or "udp"
;"CS" added by this specification
port = 1*DIGIT
;subrules for the media capabilities negotiation
attribute = ccapattr
ccapattr = "ccap:" c-cap-num SP c-cap-attr
c-cap-num = 1*DIGIT
c-cap-attr = connection-field
;subrules for the potential configuration attribute
pot-config = pot-conn-config
; pot-config defined in SDP capability
negotiation
pot-conn-config = "c=" c-cap-list *(BAR c-cap-list)
; BAR defined in SDP capability
negotiation
c-cap-list = c-cap-num *("," c-cap-num)
Figure 4: Syntax of the SDP extension
Garcia-Martin & Veikkolainen Expires August 21, 2008 [Page 13]
Internet-Draft CS audio streams in SDP February 2008
6. SDP Examples
6.1. Basic SDP example: Single Circuit-Switched Audio Stream
Figure 5 shows a basic example that describes a single audio stream
over a circuit-switched bearer. The endpoint describes as the
circuit with reference "1" where it can provide the AMR and GSM
codecs. It also indicates that it can initiate the circuit-switched
connection or be the recipient of it.
v=0
o=jdoe 2890844526 2890842807 IN IP4 10.47.16.5
s=
t=0 0
m=audio 1 CS AMR GSM
c=CS - -
a=setup:actpass
a=connection:new
Figure 5: Basic SDP example
6.1.1. CS audio stream as an alternative to RTP
Figure 6 provides an exmple of SDP consisting of two alternative
audio media streams, one using RTP over an IP bearer, the other using
a CS bearer. The SDP offerer describes the PCMU, PCMA, and GSM
payload types for RTP usage and the GSM and AMR codecs for CS audio.
It also indicates that can initiate or receive the CS connection.
v=0
o=jdoe 2890844526 2890842807 IN IP4 10.47.16.5
s=
t=0 0
m=audio 49170 RTP/AVP 0 8 3
c=IN IP4 10.47.16.5
a=mcap:1 audio GSM AMR
a=tcap:1 CS
a=ccap:1 CS - -
a=pcfg:1 m=1|2 t=1 c=1
a=setup:actpass
a=connection:new
Figure 6: Example of an SDP offer with alternative media streams
The SDP answerer replies with the SDP of Figure 7 where the CS audio
stream is selected.
Garcia-Martin & Veikkolainen Expires August 21, 2008 [Page 14]
Internet-Draft CS audio streams in SDP February 2008
v=0
o=- 2890973824 2890987289 IN IP4 10.47.16.7
s=
t=0 0
a=csup:med-v0
m=audio 1 CS AMR
c=CS - -
a=acfg:1
a=setup:active
a=connection:new
Figure 7: Example of an SDP answer with CS audio media selected
7. IANA Considerations
This document instructs IANA to register a number of SDP tokens
according to the following data.
7.1. Registration of a new "nettype" value
This memo provides instructions to IANA to register a new "nettype"
in the Session Description Protocol Parameters registry [1]. The
registration data, according to RFC 4566 [RFC4566] follows.
Type SDP Name Reference
---- ------------------ ---------
nettype CS [RFCxxxx]
7.2. Registration of new "addrtype" values
This memo provides instructions to IANA to register a new "addrtype"
in the Session Description Protocol Parameters registry [1]. The
registration data, according to RFC 4566 [RFC4566] follows.
Type SDP Name Reference
---- ------------------ ---------
addrtype E164 [RFCxxxx]
- [RFCxxxx]
7.3. Registration of a new "proto" value
This memo provides instructions to IANA to register a new "proto" in
the Session Description Protocol Parameters registry [1]. The
registration data, according to RFC 4566 [RFC4566] follows.
Type SDP Name Reference
-------------- --------------------------- ---------
Garcia-Martin & Veikkolainen Expires August 21, 2008 [Page 15]
Internet-Draft CS audio streams in SDP February 2008
proto CS [RFCxxxx]
8. Security Considerations
TBD.
9. Acknowledgments
The authors want to thank Thomas Belling, Jari Mutikainen, and Miikka
Poikselka for providing a discussion and comments on preliminary
versions of this document.
10. References
10.1. Normative References
[I-D.ietf-mmusic-sdp-capability-negotiation]
Andreasen, F., "SDP Capability Negotiation",
draft-ietf-mmusic-sdp-capability-negotiation-08 (work in
progress), December 2007.
[I-D.ietf-mmusic-sdp-media-capabilities]
Gilman, R., Even, R., and F. Andreasen, "SDP media
capabilities Negotiation",
draft-ietf-mmusic-sdp-media-capabilities-02 (work in
progress), November 2007.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3108] Kumar, R. and M. Mostafa, "Conventions for the use of the
Session Description Protocol (SDP) for ATM Bearer
Connections", RFC 3108, May 2001.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264,
June 2002.
[RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in
the Session Description Protocol (SDP)", RFC 4145,
September 2005.
[RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 4234, October 2005.
Garcia-Martin & Veikkolainen Expires August 21, 2008 [Page 16]
Internet-Draft CS audio streams in SDP February 2008
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006.
10.2. Informative References
[ITU.E164.1991]
International Telecommunications Union, "The International
Public Telecommunication Numbering Plan", ITU-
T Recommendation E.164, 1991.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
[RFC3388] Camarillo, G., Eriksson, G., Holler, J., and H.
Schulzrinne, "Grouping of Media Lines in the Session
Description Protocol (SDP)", RFC 3388, December 2002.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003.
[RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and
Video Conferences with Minimal Control", STD 65, RFC 3551,
July 2003.
[RFC4091] Camarillo, G. and J. Rosenberg, "The Alternative Network
Address Types (ANAT) Semantics for the Session Description
Protocol (SDP) Grouping Framework", RFC 4091, June 2005.
[RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message
Session Relay Protocol (MSRP)", RFC 4975, September 2007.
URIs
[1] <http://www.iana.org/assignments/sdp-parameters>
Appendix A. Design Alternatives
NOTE: This Appendix provides an analysis of the alternatives that
were considered. The intention is to provide background information
to the reader. Eventually, this Appendix should be removed from the
specification.
Garcia-Martin & Veikkolainen Expires August 21, 2008 [Page 17]
Internet-Draft CS audio streams in SDP February 2008
A.1. Analysis of alternative conventions for describing circuit-
switched audio media streams in SDP
A.1.1. Grouping of media lines
An alternative way of indicating alternative media streams could be
based on Grouping of Media Lines in the Session Description Protocol
(SDP) [RFC3388]. RFC3388 defines two new attributes
o a=mid (media stream identification)
o a=group (group creation)
The media grouping semantics are defined in the a=group line.
Currently two semantics are defined: LS (Lip Synchronization) and FID
(Flow Identification). While defining additional semantics is
allowed by a standards-track document, RFC3388 explicitly discourages
additional semantics and proposes to use other session description
mechanisms, such as SDPng.
Several "m" lines that are grouped together with the FID attribute
form a media flow. A flow consists of media streams which logically
belong together, like an audio stream, a video stream and whiteboard
sharing for an online meeting. Another example presented in RFC3388
is audio media using two or more codecs which can be dynamically
changed during the session's lifetime. This can be beneficial is
some environments, for example when the multimedia session is carried
over a cellular radio network, which may use separate port numbers
and separate bearers for different codecs.
An example SDP provided in RFC3388 presents a configuration where two
codecs are grouped using the FID attribute. The semantics of the FID
attribute define that whenever there is media to be sent using a
specific codec, and that codec is part of the flow and the direction
attribute is "sendonly" or "sendrecv" then media is copied to that
specific stream. RFC3388 further states that if a codec is not used,
or the direction attribute is neither "sendonly" nor "sendrecv", then
media is "muted".
Garcia-Martin & Veikkolainen Expires August 21, 2008 [Page 18]
Internet-Draft CS audio streams in SDP February 2008
v=0
o=Laura 289083124 289083124 IN IP4 two.example.com
t=0 0
c=IN IP4 131.160.1.112
a=group:FID 1 2
m=audio 30000 RTP/AVP 3
a=rtpmap:3 GSM/8000
a=mid:1
m=audio 30002 RTP/AVP 97
a=rtpmap:97 AMR/8000
a=fmtp:97 mode-set=0,2,5,7; mode-change-period=2;
mode-change-neighbor; maxframes=1
a=mid:2
Figure 8: Example SDP according to RFC 3388
While this would seem like an appropriate use case for using circuit-
switched bearer as an alternative for RTP, there is one difference.
Even though FID grouping allows media to be sent alternatively on
difference ports depending on the codec used, the assumption is that
the underlying bearer is established at the time of session
initiation.
For our purposes, the circuit-switched and RTP based bearers are
alternatives in the sense that once one is selected during Offer/
Answer exchange, the other one is not established. For example, if
the endpoints agree to use circuit-switched bearer for he audio
media, no resources are reserved in the IP domain.
A.1.2. Alternative network types
The Alternative Network Address Types (ANAT) Semantics for the
Session Description Protocol (SDP) Grouping Framework [RFC4091]
defines additional semantics for the media grouping framework. The
ANAT semantics provide alternative network addresses of different
types for a single logical media stream. The primary use case is to
offer alternative addresses, one from IPv4 address space, and the
other from IPv6 address space.
The idea of ANAT could be extended for provide alternative network
types (ANT). ANT semantics defines that the media streams offered
are alternatives on the network type level.
An example SDP showing alternative network types is presented in
Figure 9 below.
Garcia-Martin & Veikkolainen Expires August 21, 2008 [Page 19]
Internet-Draft CS audio streams in SDP February 2008
v=0
o=bob 280744730 28977631 IN IP4 host.example.com
s=
t=0 0
a=group:ANT 1 2
m=audio 25000 RTP/AVP 0
c=IN IP6 2001:DB8::1
a=mid:1
m=audio 1 CS gsm amr
c=CS
a=mid:2
Figure 9: Example of SDP with alternative network types
Authors' Addresses
Miguel Garcia-Martin
Nokia Siemens Networks
P.O. Box 6
Nokia Siemens Networks, FIN 02022
Finland
Phone: +358 50 480 4586
Email: miguel.garcia@nsn.com
Simo Veikkolainen
Nokia Siemens Networks
P.O. Box 6
Nokia Siemens Networks, FIN 02022
Finland
Phone: +358 50 486 4463
Email: simo.veikkolainen@nsn.com
Garcia-Martin & Veikkolainen Expires August 21, 2008 [Page 20]
Internet-Draft CS audio streams in SDP February 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
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.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Garcia-Martin & Veikkolainen Expires August 21, 2008 [Page 21]
| PAFTECH AB 2003-2026 | 2026-04-23 04:22:18 |