| TOC |
|
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.
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.
1.
Introduction
2.
Document Conventions
3.
Requirements
3.1.
General Requirements
3.2.
Media-specific requirements
4.
Overview of operation
4.1.
Example call flow
5.
Protocol Description
5.1.
Extensions to SDP
5.1.1.
Connection Data
5.1.2.
Media Descriptions
5.2.
Offering alternative media streams
5.3.
Determining the direction of the
circuit-switched connection setup
5.4.
Formal syntax
6.
SDP Examples
6.1.
Basic SDP example: Single Circuit-Switched Audio
Stream
6.1.1.
CS audio stream as an alternative to RTP
7.
IANA Considerations
7.1.
Registration of a new "nettype" value
7.2.
Registration of new "addrtype" values
7.3.
Registration of a new "proto" value
8.
Security Considerations
9.
Acknowledgments
10.
References
10.1.
Normative References
10.2.
Informative References
Appendix A.
Design Alternatives
A.1.
Analysis of alternative conventions for describing
circuit-switched audio media
streams in SDP
A.1.1.
Grouping of media lines
A.1.2.
Alternative network types
§
Authors' Addresses
§
Intellectual Property and Copyright Statements
| TOC |
The Session Description Protocol (SDP) (Handley, M., Jacobson, V., and C. Perkins, “SDP: Session Description Protocol,” July 2006.) [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) (Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, “RTP: A Transport Protocol for Real-Time Applications,” July 2003.) [RFC3550], using the profiles for audio and video media defined in RTP Profile for Audio and Video Conferences with Minimal Control (Schulzrinne, H. and S. Casner, “RTP Profile for Audio and Video Conferences with Minimal Control,” July 2003.) [RFC3551].
However, SDP can be used to describe other transport protocols than RTP. Previous work includes SDP conventions for describing ATM bearers (Kumar, R. and M. Mostafa, “Conventions for the use of the Session Description Protocol (SDP) for ATM Bearer Connections,” May 2001.) [RFC3108] and the Message Session Relay Protocol (Campbell, B., Mahy, R., and C. Jennings, “The Message Session Relay Protocol (MSRP),” September 2007.) [RFC4975].
SDP is commonly carried in Session Initiation Protocol (SIP) (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.) [RFC3261] messages in order to agree on a common media description among the endpoints. An Offer/Answer Model with Session Description Protocol (SDP) (Rosenberg, J. and H. Schulzrinne, “An Offer/Answer Model with Session Description Protocol (SDP),” June 2002.) [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 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 (Document Conventions) provides the document conventions, Section 3 (Requirements) introduces the requirements, Section 4 (Overview of operation) presents an overview of the proposed solutions, and Section 5 (Protocol Description) contains the protocol description. Section 6 (SDP Examples) provide a few examples of descriptions of circuit-switched audio streams in SDP. Section 7 (IANA Considerations) and Section 8 (Security Considerations) contain the IANA and Security considerations, respectively.
| TOC |
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 (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.) [RFC2119] and indicate requirement levels for compliant implementations.
| TOC |
| TOC |
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 (Handley, M., Jacobson, V., and C. Perkins, “SDP: Session Description Protocol,” July 2006.) [RFC4566] and the SDP Offer/Answer Model (Rosenberg, J. and H. Schulzrinne, “An Offer/Answer Model with Session Description Protocol (SDP),” June 2002.) [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 (Rosenberg, J. and H. Schulzrinne, “An Offer/Answer Model with Session Description Protocol (SDP),” June 2002.) [RFC3264], and communication may still be possible.
| TOC |
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.
| TOC |
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 (Yon, D. and G. Camarillo, “TCP-Based Media Transport in the Session Description Protocol (SDP),” September 2005.) [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 (Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, “RTP: A Transport Protocol for Real-Time Applications,” July 2003.) [RFC3550] and a circuit-switched bearer. The endpoints agree on a given bearer and establish the media stream.
| TOC |
Consider the example presented in Figure 1 (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.
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.
| TOC |
| TOC |
This section provides the syntax and semantics of the extensions required for providing a description of circuit-switched streams in SDP.
| TOC |
According to SDP (Handley, M., Jacobson, V., and C. Perkins, “SDP: Session Description Protocol,” July 2006.) [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 (International Telecommunications Union, “The International Public Telecommunication Numbering Plan,” 1991.) [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 (Handley, M., Jacobson, V., and C. Perkins, “SDP: Session Description Protocol,” July 2006.) [RFC4566].
The following are examples of the extension to the connection data line:
c=CS E164 +15551234
c=CS - -
| TOC |
According to SDP (Handley, M., Jacobson, V., and C. Perkins, “SDP: Session Description Protocol,” July 2006.) [RFC4566], the media descriptions line in SDP has the following syntax:
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 (Handley, M., Jacobson, V., and C. Perkins, “SDP: Session Description Protocol,” July 2006.) [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 (Schulzrinne, H. and S. Casner, “RTP Profile for Audio and Video Conferences with Minimal Control,” July 2003.) [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 (Handley, M., Jacobson, V., and C. Perkins, “SDP: Session Description Protocol,” July 2006.) [RFC4566], the endpoint MUST include a single dash "-" in the <fmt> sub-field.
As per RFC 4566 (Handley, M., Jacobson, V., and C. Perkins, “SDP: Session Description Protocol,” July 2006.) [RFC4566], the media format descriptions are listed in priority order.
Examples of media descriptions for circuit-switched audio streams are:
m=audio 1 CS AMR GSM
m=audio 1 CS -
| TOC |
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 (Andreasen, F., “SDP Capability Negotiation,” March 2010.) [I‑D.ietf‑mmusic‑sdp‑capability‑negotiation] as well as in SDP media capabilities negotiation (Gilman, R., Even, R., and F. Andreasen, “SDP media capabilities Negotiation,” February 2010.) [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 (Gilman, R., Even, R., and F. Andreasen, “SDP media capabilities Negotiation,” February 2010.) [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] (Andreasen, F., “SDP Capability Negotiation,” March 2010.) 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 (Media Descriptions).
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 (Andreasen, F., “SDP Capability Negotiation,” March 2010.) [I‑D.ietf‑mmusic‑sdp‑capability‑negotiation]. The "a=tcap" capability attribute lists one or more <proto> elements, defined in SDP (Handley, M., Jacobson, V., and C. Perkins, “SDP: Session Description Protocol,” July 2006.) [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 (Handley, M., Jacobson, V., and C. Perkins, “SDP: Session Description Protocol,” July 2006.) [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 (Andreasen, F., “SDP Capability Negotiation,” March 2010.) [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 ("|").
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 (Example SDP with alternative media streams) 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 |
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 (Gilman, R., Even, R., and F. Andreasen, “SDP media capabilities Negotiation,” February 2010.) [I‑D.ietf‑mmusic‑sdp‑media‑capabilities]. The answer carries the accepted configuration in the m and c lines.
| TOC |
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) (Yon, D. and G. Camarillo, “TCP-Based Media Transport in the Session Description Protocol (SDP),” September 2005.) [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.
| TOC |
The following is the formal Augmented Backus-Naur Form (ABNF) (Crocker, D., Ed. and P. Overell, “Augmented BNF for Syntax Specifications: ABNF,” October 2005.) [RFC4234] syntax that supports the extensions defined in his specification. The syntax is built above the SDP (Handley, M., Jacobson, V., and C. Perkins, “SDP: Session Description Protocol,” July 2006.) [RFC4566] grammar and the SDP capability negotiation (Andreasen, F., “SDP Capability Negotiation,” March 2010.) [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
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 |
| TOC |
| TOC |
Figure 5 (Basic SDP example) 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 |
| TOC |
Figure 6 (Example of an SDP offer with alternative media streams) 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 (Example of an SDP answer with CS audio media selected) where the CS audio stream is selected.
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 |
| TOC |
This document instructs IANA to register a number of SDP tokens according to the following data.
| TOC |
This memo provides instructions to IANA to register a new "nettype" in the Session Description Protocol Parameters registry. The registration data, according to RFC 4566 (Handley, M., Jacobson, V., and C. Perkins, “SDP: Session Description Protocol,” July 2006.) [RFC4566] follows.
Type SDP Name Reference ---- ------------------ --------- nettype CS [RFCxxxx]
| TOC |
This memo provides instructions to IANA to register a new "addrtype" in the Session Description Protocol Parameters registry. The registration data, according to RFC 4566 (Handley, M., Jacobson, V., and C. Perkins, “SDP: Session Description Protocol,” July 2006.) [RFC4566] follows.
Type SDP Name Reference
---- ------------------ ---------
addrtype E164 [RFCxxxx]
- [RFCxxxx]
| TOC |
This memo provides instructions to IANA to register a new "proto" in the Session Description Protocol Parameters registry. The registration data, according to RFC 4566 (Handley, M., Jacobson, V., and C. Perkins, “SDP: Session Description Protocol,” July 2006.) [RFC4566] follows.
Type SDP Name Reference -------------- --------------------------- --------- proto CS [RFCxxxx]
| TOC |
TBD.
| TOC |
The authors want to thank Thomas Belling, Jari Mutikainen, and Miikka Poikselka for providing a discussion and comments on preliminary versions of this document.
| TOC |
| TOC |
| TOC |
| [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 (TXT). |
| [RFC3388] | Camarillo, G., Eriksson, G., Holler, J., and H. Schulzrinne, “Grouping of Media Lines in the Session Description Protocol (SDP),” RFC 3388, December 2002 (TXT). |
| [RFC3550] | Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, “RTP: A Transport Protocol for Real-Time Applications,” STD 64, RFC 3550, July 2003 (TXT, PS, PDF). |
| [RFC3551] | Schulzrinne, H. and S. Casner, “RTP Profile for Audio and Video Conferences with Minimal Control,” STD 65, RFC 3551, July 2003 (TXT, PS, PDF). |
| [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 (TXT). |
| [RFC4975] | Campbell, B., Mahy, R., and C. Jennings, “The Message Session Relay Protocol (MSRP),” RFC 4975, September 2007 (TXT). |
| TOC |
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.
| TOC |
| TOC |
An alternative way of indicating alternative media streams could be based on Grouping of Media Lines in the Session Description Protocol (SDP) (Camarillo, G., Eriksson, G., Holler, J., and H. Schulzrinne, “Grouping of Media Lines in the Session Description Protocol (SDP),” December 2002.) [RFC3388]. RFC3388 defines two new attributes
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".
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.
| TOC |
The Alternative Network Address Types (ANAT) Semantics for the Session Description Protocol (SDP) Grouping Framework (Camarillo, G. and J. Rosenberg, “The Alternative Network Address Types (ANAT) Semantics for the Session Description Protocol (SDP) Grouping Framework,” June 2005.) [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 (Example of SDP with alternative network types) below.
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 |
| TOC |
| 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 |
| TOC |
Copyright © 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.
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.