One document matched: draft-garcia-mmusic-sdp-cs-00.xml
<?xml version="1.0"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc compact="yes"?>
<?rfc sortrefs="yes"?>
<?rfc linkmailto="no"?>
<?rfc strict="no"?>
<?rfc subcompact="no"?>
<?rfc symrefs="yes"?>
<rfc ipr="full3978" category="std">
<!-- ************************************************************** -->
<!-- The FRONT section includes the title, date, authors names and -->
<!-- addresses, abstract etc. Some of the stuff, like TOC, expiration -->
<!-- date and the rest are automatically generated by the conversion -->
<!-- tools (e.g., xml2rfc) -->
<!-- ************************************************************** -->
<front>
<title abbrev="CS audio streams in SDP">
Describing CS audio streams in the Session Description Protocol (SDP)
</title>
<author initials="M" surname="Garcia-Martin" fullname="Miguel Garcia-Martin">
<organization>Nokia Siemens Networks</organization>
<address>
<postal>
<street>P.O. Box 6</street>
<city>Nokia Siemens Networks</city>
<region>FIN</region>
<code>02022</code>
<country>Finland</country>
</postal>
<phone>+358 50 480 4586</phone>
<email>miguel.garcia@nsn.com</email>
</address>
</author>
<author initials="S" surname="Veikkolainen" fullname="Simo Veikkolainen">
<organization>Nokia Siemens Networks</organization>
<address>
<postal>
<street>P.O. Box 6</street>
<city>Nokia Siemens Networks</city>
<region>FIN</region>
<code>02022</code>
<country>Finland</country>
</postal>
<phone>+358 50 486 4463 </phone>
<email>simo.veikkolainen@nsn.com</email>
</address>
</author>
<date day="18" month="February" year="2008" />
<area>RAI</area>
<workgroup>MMUSIC WG</workgroup>
<keyword>I-D</keyword>
<keyword>Internet-Draft</keyword>
<keyword>cs audio</keyword>
<abstract>
<t>
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.
</t>
</abstract>
</front>
<!-- ************************************************************** -->
<!-- The MIDDLE section includes the actual draft contents -->
<!-- ************************************************************** -->
<middle>
<!-- Introduction -->
<section anchor="intro" title="Introduction">
<t>
The <xref target="RFC4566">Session Description Protocol
(SDP)</xref> 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 <xref target="RFC3550">Real-Time
Transport Protocol (RTP)</xref>, using the profiles for audio
and video media defined in <xref target="RFC3551">RTP Profile
for Audio and Video Conferences with Minimal Control</xref>.
</t>
<t>
However, SDP can be used to describe other transport
protocols than RTP. Previous work includes <xref
target="RFC3108">SDP conventions for describing ATM
bearers</xref> and the <xref target="RFC4975">Message Session
Relay Protocol</xref>.
</t>
<t>
SDP is commonly carried in <xref target="RFC3261">Session
Initiation Protocol (SIP)</xref> messages in order to agree on
a common media description among the endpoints. <xref
target="RFC3264">An Offer/Answer Model with Session
Description Protocol (SDP)</xref> 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.
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
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 for the endpoint to describe different codecs for
each access type and get an agreement on the bearer together
with the remote endpoint.
</t>
<t>
The rest of the document is structured as follows: <xref
target="sec-conventions"/> provides the document conventions,
<xref target="sec-requirements"/> introduces the requirements,
<xref target="sec-overview"/> presents an overview of the
proposed solutions, and <xref
target="sec-protocol-description"/> contains the protocol
description. <xref target="sec-sdp-examples" /> provide a
few examples of descriptions of circuit-switched audio streams
in SDP. <xref target="sec-iana" /> and <xref
target="sec-security"/> contain the IANA and Security
considerations, respectively.
</t>
</section>
<section title="Document Conventions" anchor="sec-conventions">
<t>
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, <xref target="RFC2119">RFC 2119</xref> and indicate
requirement levels for compliant implementations.
</t>
</section>
<section title="Requirements" anchor="sec-requirements">
<section title="General Requirements" anchor="sec-gen-reqs">
<t>
This section presents the general requirements that are specific for
the circuit-switched audio media stream.
</t>
<t><list style='format REQ-GEN-%d:'>
<t>
A mechanism for endpoints to negotiate and agree on a
circuit-switch bearer for audio media must be available.
</t>
<t>
The mechanism must allow the endpoints to combine
circuit-switched audio media streams with other
complementary media streams, for example, text messaging.
</t>
<t>
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.
</t>
<t>
The mechanism must be backwards compatible with <xref
target="RFC4566">SDP </xref> and the <xref
target="RFC3264">SDP Offer/Answer Model</xref> 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
<xref target="RFC3264">SDP offer/answer</xref>, and
communication may still be possible.
</t>
</list></t>
</section>
<section title="Media-specific requirements" anchor="sec-media-reqs">
<t>
This section presents the requirements that are specific for
the circuit-switched audio media.
</t>
<t><list style='format REQ-CS-%d:'>
<t>
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.
</t>
<t>
It must be possible for endpoints to not advertise the
list of available codecs for circuit-switched audio streams.
</t>
<t>
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.
</t>
</list></t>
</section>
</section>
<section title="Overview of operation" anchor="sec-overview">
<t>
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 <xref target="RFC4145">RFC 4145</xref>
to negotiate the active and passive sides of a connection
setup.
</t>
<t>
The mechanism allows expressing an audio media stream with two
separate bearers: a regular IP bearer using <xref
target="RFC3550">RTP</xref> and a circuit-switched bearer. The
endpoints agree on a given bearer and establish the media
stream.
</t>
<section title="Example call flow" anchor="sec-example">
<t>
Consider the example presented in <xref
target="fig-example-flow"/>. 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.
</t>
<figure anchor="fig-example-flow" title="Example flow" align="center">
<artwork><![CDATA[
Alice Bob
| (1) SDP Offer (RTP and CS audio) |
|--------------------------------->|
| |
| (2) SDP Answer (CS audio) |
|<---------------------------------|
| |
| cs call setup |
|<---------------------------------|
| |
| |
|<======media over cs bearer======>|
| |
]]></artwork>
</figure>
<t>
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.
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
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.
</t>
</section>
</section>
<section title="Protocol Description" anchor="sec-protocol-description">
<section title="Extensions to SDP" anchor="sec-sdp-extensions">
<t>
This section provides the syntax and semantics of the
extensions required for providing a description of
circuit-switched streams in SDP.
</t>
<section title="Connection Data " anchor="sec-c-line">
<t>
According to <xref target="RFC4566">SDP</xref>, the
connection data line in SDP has the following syntax:
</t>
<t><list>
<t>
c=<nettype> <addrtype> <connection-address>
</t>
</list></t>
<t>
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.
</t>
<t>
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.
</t>
<t>
This memo defines a new network type for describing
circuit-switched network type. The mnemonic "CS" is used for
this network type.
</t>
<t>
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 <xref
target="ITU.E164.1991">ITU-T E.164 </xref> specification.
</t>
<t>
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.
</t>
<!-- Note: the dash "-" is inspired in RFC 3108 -->
<t><list>
<t>
Note that <addrtype> and/or
<connection-address> should not be omitted without being
set to a "-" since this would violate basic syntax of <xref
target="RFC4566">SDP</xref>.
</t>
</list></t>
<t>
The following are examples of the extension to the
connection data line:
</t>
<t><list>
<t>
c=CS E164 +15551234
</t>
<t>
c=CS - -
</t>
</list></t>
</section>
<section title="Media Descriptions" anchor="sec-m-line">
<t>
According to <xref target="RFC4566">SDP</xref>, the
media descriptions line in SDP has the following syntax:
</t>
<t><list>
<t>
m=<media> <port> <proto> <fmt> ...
</t>
</list>
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
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 <xref
target="RFC4566">SDP </xref> and to indicate the usage of
circuit-switched protocols.
</t>
<t>
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 <xref target="RFC3551">RTP audio profile</xref>.
</t>
<t>
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.
</t>
<!-- At some point in time we should
describe CS video streams, for example m=video CS
..... -->
<t>
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 <xref target="RFC4566">SDP </xref>, the
endpoint MUST include a single dash "-" in the <fmt>
sub-field.
</t>
<t>
As per <xref target="RFC4566">RFC 4566</xref>, the media
format descriptions are listed in priority order.
</t>
<t>
Examples of media descriptions for circuit-switched audio
streams are:
</t>
<t>
<list>
<t>
m=audio 1 CS AMR GSM
</t>
<t>
m=audio 1 CS -
</t>
</list>
</t>
</section>
</section>
<section title="Offering alternative media streams" anchor="sec-alt-media">
<t>
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.
</t>
<t>
To offer an audio media stream with alternative bearers for
RTP and circuit-switched bearer, we reuse some of the
capability attributes defined in <xref
target="I-D.ietf-mmusic-sdp-capability-negotiation">SDP
capability negotiation</xref> as well as in <xref
target="I-D.ietf-mmusic-sdp-media-capabilities">SDP media
capabilities negotiation</xref>. Additionally, we define a
new capability attribute "a=ccap" in this document that
allows to express a connection address as a capabilities.
</t>
<t>
The "a=mcap" media capability attribute defined in <xref
target="I-D.ietf-mmusic-sdp-media-capabilities">SDP media
capabilities negotiation</xref> lists media formats as
capabilities in the form a media type and one or more subtypes.
</t>
<t>
An example provided in <xref
target="I-D.ietf-mmusic-sdp-capability-negotiation"/> lists
four audio media subtypes which are numbered consecutively
(starting from 1 in this example).
<list>
<t>a=mcap:1 audio g729 iLBC PCMU g729</t>
</list>
</t>
<t>
Similarly, we can use the a=mcap capability attribute to
indicate media capabilities that correspond to the m-line
described in <xref target="sec-m-line"/>.
<list>
<t>a=mcap:1 audio GSM AMR</t>
</list>
Here, we declare two media subtype capabilities with
associated numbers 1 and 2, for GSM and AMR codecs,
respectively.
</t>
<t>
Transport Protocols can be expressed as capabilities by the
"a=tcap" capability attribute defined in <xref
target="I-D.ietf-mmusic-sdp-capability-negotiation">SDP
capability negotiation</xref>. The "a=tcap" capability
attribute lists one or more <proto> elements, defined
in <xref target="RFC4566">SDP</xref>.
</t>
<t>
An example of transport protocol capability indicating "CS"
transport protocol defined in this document would thus be:
<list>
<t>a=tcap:1 CS</t>
</list>
</t>
<t>
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:
</t>
<t>
<list>
<t>a=ccap:<c-cap-num> <c-cap-attr> *[ <c-cap-attr>]</t>
</list>
</t>
<t>
where <c-cap-num> is an integer between 1 and 2^31-1
(both included) used to number the connection address
capability attribute.
</t>
<t>
The <c-cap-attr> field consists of network
type, address type and a connection address, as specified for
a "c=" line in <xref target="RFC4566">SDP</xref>. 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:
<list>
<t>a=ccap:1 CS E164 +15551234</t>
</list>
</t>
<t>
We also define an extension to the potential configuration
attribute ("a=pcfg"), originally defined in <xref
target="I-D.ietf-mmusic-sdp-capability-negotiation">SDP
capabilities negotiation</xref>, according to which the
'pcfg' attribute has the following definition:
</t>
<t>
<list>
<t>a=pcfg: <config-number> [<pot-cfg-list>]
</t>
</list>
</t>
<t>
We extend the <pot-cfg-list> field to be able to
convey one or more connection capability numbers.according to the
following definition:
</t>
<t>
<figure><artwork><![CDATA[
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
]]></artwork></figure>
</t>
<t>
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 ("|").
</t>
<t>
An exmple SDP consisting of two alternative media stream is as
follows:
</t>
<t>
<figure title="Example SDP with alternative media streams"
anchor="fig-sdp-alt-media"><artwork><![CDATA[
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
]]></artwork></figure>
</t>
<t>
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.
<list>
<t>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.</t>
</list>
</t>
<t>
An exmple SDP answer to the offer presented in <xref
target="fig-sdp-alt-media"/> where CS audio has been
selected as the actual configration is as follows:
</t>
<t>
<figure title="Example SDP answer with CS audio media selected"
anchor="fig-sdp-alt-media-answer"><artwork><![CDATA[
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
]]></artwork></figure>
</t>
<t>
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 <xref
target="I-D.ietf-mmusic-sdp-media-capabilities">SDP media
capabilities negotiation</xref>. The answer carries the
accepted configuration in the m and c lines.
</t>
</section>
<section title="Determining the direction of the
circuit-switched connection setup" anchor="sec-connection-direction">
<t>
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.
</t>
<t>
The framework defined in <xref target="RFC4145">TCP-Based Media Transport
in the Session Description Protocol (SDP)</xref> 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.
</t>
<t>
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.
</t>
</section>
<section title="Formal syntax" anchor="sec-syntax">
<t>
The following is the formal <xref target="RFC4234">
Augmented Backus-Naur Form (ABNF) </xref> syntax that
supports the extensions defined in his specification. The
syntax is built above the <xref target="RFC4566"> SDP
</xref> grammar and the <xref
target="I-D.ietf-mmusic-sdp-capability-negotiation">SDP
capability negotiation </xref>. Implementations according to this
specification MUST implement this syntax.
</t>
<!-- The following figure is a bit of a mess. For the c and m lines we
copy a lot of the defined ABNF, mostly because we don't define
anything new, but because we just add new values (tokens) to existing
definition.However, once we enter the media capabilities definition,
we merely extend the defined syntax. I think the latter makes more
sense, we so should make the ABNF consistent -->
<figure anchor="fig-sdp-syntax" title="Syntax of the SDP
extension"><artwork><![CDATA[
; 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
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)
]]></artwork></figure>
</section>
</section>
<section title="SDP Examples" anchor="sec-sdp-examples">
<section title="Basic SDP example: Single Circuit-Switched Audio
Stream" anchor="sec-example-basic">
<t>
<xref target="fig-sdp-basic"/> 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.
</t>
<figure title="Basic SDP example" anchor="fig-sdp-basic"><artwork><![CDATA[
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
]]></artwork></figure>
<section title="CS audio stream as an alternative to RTP">
<t>
<xref target="fig-example-sdp-alt-offer"/> 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.
</t>
<t>
<figure title="Example of an SDP offer with alternative media streams"
anchor="fig-example-sdp-alt-offer"><artwork><![CDATA[
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
]]></artwork></figure>
</t>
<t>
The SDP answerer replies with the SDP of <xref
target="fig-sdp-alt-answer"/> where the CS audio stream is
selected.
</t>
<t>
<figure title="Example of an SDP answer with CS audio media selected"
anchor="fig-sdp-alt-answer"><artwork><![CDATA[
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
]]></artwork></figure>
</t>
</section>
</section>
</section>
<section title="IANA Considerations" anchor="sec-iana">
<t>
This document instructs IANA to register a number of SDP
tokens according to the following data.
</t>
<section title="Registration of a new "nettype" value"
anchor="sec-iana-nettype">
<t>
This memo provides instructions to IANA to register a new
"nettype" in the <eref
target="http://www.iana.org/assignments/sdp-parameters">Session
Description Protocol Parameters registry </eref>. The
registration data, according to <xref target="RFC4566">RFC
4566</xref> follows.
</t>
<figure><artwork>
Type SDP Name Reference
---- ------------------ ---------
nettype CS [RFCxxxx]
</artwork></figure>
</section>
<section title="Registration of new "addrtype" values"
anchor="sec-iana-addrtype">
<t>
This memo provides instructions to IANA to register a new
"addrtype" in the <eref
target="http://www.iana.org/assignments/sdp-parameters">Session
Description Protocol Parameters registry </eref>. The
registration data, according to <xref target="RFC4566">RFC
4566</xref> follows.
</t>
<figure><artwork>
Type SDP Name Reference
---- ------------------ ---------
addrtype E164 [RFCxxxx]
- [RFCxxxx]
</artwork></figure>
</section>
<section title="Registration of a new "proto" value"
anchor="sec-iana-proto">
<t>
This memo provides instructions to IANA to register a new
"proto" in the <eref
target="http://www.iana.org/assignments/sdp-parameters">Session
Description Protocol Parameters registry </eref>. The
registration data, according to <xref target="RFC4566">RFC
4566</xref> follows.
</t>
<figure><artwork>
Type SDP Name Reference
-------------- --------------------------- ---------
proto CS [RFCxxxx]
</artwork></figure>
</section>
</section>
<section title="Security Considerations" anchor="sec-security">
<t>
TBD.
</t>
</section>
<section title="Acknowledgments" anchor="sec-acks">
<t>
The authors want to thank Thomas Belling, Jari Mutikainen, and
Miikka Poikselka for providing a discussion and comments on
preliminary versions of this document.
</t>
</section>
</middle>
<!-- ************************************************************** -->
<!-- The BACK section includes the rest of the stuff, references, -->
<!-- acknowledgements, authors addresses, etc. -->
<!-- ************************************************************** -->
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119" ?>
<?rfc include="reference.RFC.3108" ?>
<?rfc include="reference.RFC.3264" ?>
<?rfc include="reference.RFC.4145" ?>
<?rfc include="reference.RFC.4234" ?>
<?rfc include="reference.RFC.4566" ?>
<?rfc include="reference.I-D.ietf-mmusic-sdp-capability-negotiation" ?>
<?rfc include="reference.I-D.ietf-mmusic-sdp-media-capabilities" ?>
</references>
<references title="Informative References">
<?rfc include="reference.RFC.3388" ?>
<?rfc include="reference.RFC.3550" ?>
<?rfc include="reference.RFC.3551" ?>
<?rfc include="reference.RFC.3261" ?>
<?rfc include="reference.RFC.4091" ?>
<?rfc include="reference.RFC.4975" ?>
<?rfc include="reference.ITU.E164.1991" ?>
</references>
<section title="Design Alternatives"
anchor="appendix-alternatives">
<t>
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.
</t>
<section title="Analysis of alternative conventions for describing
circuit-switched audio media
streams in SDP" anchor="sec-alternatives">
<section title="Grouping of media lines" anchor="sec-grouping-lines">
<t>
An alternative way of indicating alternative media streams
could be based on <xref target="RFC3388">Grouping of Media Lines in
the Session Description Protocol (SDP)</xref>. RFC3388
defines two new attributes
<list style="symbols">
<t>a=mid (media stream identification)</t>
<t>a=group (group creation)</t>
</list>
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
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".
</t>
<figure title="Example SDP according to RFC 3388" anchor="fig-sdp-rfc3388"><artwork><![CDATA[
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
]]></artwork></figure>
<t>
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.
</t>
<t>
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.
</t>
</section>
<section title="Alternative network types" anchor="sec-alt-nw-types">
<t>
<xref target="RFC4091">The Alternative Network Address Types
(ANAT) Semantics for the Session Description Protocol (SDP)
Grouping Framework</xref> 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.
</t>
<t>
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.
</t>
<t>
An example SDP showing alternative network types is
presented in <xref target="fig-sdp-alt-net"/> below.
</t>
<figure title="Example of SDP with alternative network types" anchor="fig-sdp-alt-net"><artwork><![CDATA[
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
]]></artwork></figure>
</section>
</section>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 19:51:02 |