[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]

Versions: 00 01 02 draft-ietf-mmusic-sdp-cs

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]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/