draft-ietf-mmusic-sdp-cs-03.txt   draft-ietf-mmusic-sdp-cs-04.txt 
MMUSIC WG M. Garcia-Martin MMUSIC WG M. Garcia-Martin
Internet-Draft Ericsson Internet-Draft Ericsson
Intended status: Standards Track S. Veikkolainen Intended status: Standards Track S. Veikkolainen
Expires: August 21, 2010 Nokia Expires: February 23, 2011 Nokia
February 17, 2010 August 22, 2010
Session Description Protocol (SDP) Extension For Setting Up Audio and Session Description Protocol (SDP) Extension For Setting Up Audio and
Video Media Streams Over Circuit-Switched Bearers In The Public Video Media Streams Over Circuit-Switched Bearers In The Public
Switched Telephone Network (PSTN) Switched Telephone Network (PSTN)
draft-ietf-mmusic-sdp-cs-03 draft-ietf-mmusic-sdp-cs-04
Abstract Abstract
This memo describes use cases, requirements, and protocol extensions This memo describes use cases, requirements, and protocol extensions
for using the Session Description Protocol (SDP) Offer/Answer model for using the Session Description Protocol (SDP) Offer/Answer model
for establishing audio and video media streams over circuit-switched for establishing audio and video media streams over circuit-switched
bearers in the Public Switched Telephone Network (PSTN). bearers in the Public Switched Telephone Network (PSTN).
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF). Note that other groups may also distribute
other groups may also distribute working documents as Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at This Internet-Draft will expire on February 23, 2011.
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, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the BSD License. described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this 10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process. modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
skipping to change at page 3, line 19 skipping to change at page 3, line 19
3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Overview of Operation . . . . . . . . . . . . . . . . . . . . 6 4. Overview of Operation . . . . . . . . . . . . . . . . . . . . 6
4.1. Example Call Flow . . . . . . . . . . . . . . . . . . . . 6 4.1. Example Call Flow . . . . . . . . . . . . . . . . . . . . 6
5. Protocol Description . . . . . . . . . . . . . . . . . . . . . 8 5. Protocol Description . . . . . . . . . . . . . . . . . . . . . 8
5.1. Level of Compliance . . . . . . . . . . . . . . . . . . . 8 5.1. Level of Compliance . . . . . . . . . . . . . . . . . . . 8
5.2. Extensions to SDP . . . . . . . . . . . . . . . . . . . . 8 5.2. Extensions to SDP . . . . . . . . . . . . . . . . . . . . 8
5.2.1. Connection Data . . . . . . . . . . . . . . . . . . . 8 5.2.1. Connection Data . . . . . . . . . . . . . . . . . . . 8
5.2.2. Media Descriptions . . . . . . . . . . . . . . . . . . 9 5.2.2. Media Descriptions . . . . . . . . . . . . . . . . . . 9
5.2.3. Correlating the PSTN Circuit-Switched Bearer with 5.2.3. Correlating the PSTN Circuit-Switched Bearer with
SDP . . . . . . . . . . . . . . . . . . . . . . . . . 10 SDP . . . . . . . . . . . . . . . . . . . . . . . . . 10
5.2.3.1. The "correlation" attribute . . . . . . . . . . . 11 5.2.3.1. The "cs-correlation" attribute . . . . . . . . . . 11
5.2.3.2. Caller-ID Correlation Mechanism . . . . . . . . . 11 5.2.3.2. Caller-ID Correlation Mechanism . . . . . . . . . 11
5.2.3.3. User-User Information Element Correlation 5.2.3.3. User-User Information Element Correlation
Mechanism . . . . . . . . . . . . . . . . . . . . 12 Mechanism . . . . . . . . . . . . . . . . . . . . 12
5.2.3.4. DTMF Correlation Mechanism . . . . . . . . . . . . 13 5.2.3.4. DTMF Correlation Mechanism . . . . . . . . . . . . 13
5.2.3.5. Negotiating the used correlation mechanisms . . . 15 5.2.3.5. Negotiating the used correlation mechanisms . . . 15
5.3. Considerations for Usage of Existing SDP . . . . . . . . . 17 5.3. Considerations for Usage of Existing SDP . . . . . . . . . 17
5.3.1. Originator of the Session . . . . . . . . . . . . . . 17 5.3.1. Originator of the Session . . . . . . . . . . . . . . 17
5.3.2. Contact information . . . . . . . . . . . . . . . . . 17 5.3.2. Contact information . . . . . . . . . . . . . . . . . 17
5.3.3. Determining the Direction of the Circuit-Switched 5.3.3. Determining the Direction of the Circuit-Switched
Connection Setup . . . . . . . . . . . . . . . . . . . 17 Connection Setup . . . . . . . . . . . . . . . . . . . 17
5.4. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . 18 5.4. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . 18
6. SDP Examples . . . . . . . . . . . . . . . . . . . . . . . . . 19 6. SDP Examples . . . . . . . . . . . . . . . . . . . . . . . . . 19
6.1. Basic SDP example: Single Circuit-Switched Audio Stream . 19 6.1. Basic SDP example: Single Circuit-Switched Audio Stream . 20
6.2. Advanced SDP example: Alternative and IP 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
Circuit-Switched Audio and Video Streams . . . . . . . . . 20 7.1. Registration of new correlation SDP attribute . . . . . . 21
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 7.2. Registration of a new "nettype" value . . . . . . . . . . 21
7.1. Registration of new correlation SDP attribute . . . . . . 22 7.3. Registration of new "addrtype" values . . . . . . . . . . 21
7.2. Registration of a new "nettype" value . . . . . . . . . . 22 7.4. Registration of a new "proto" value . . . . . . . . . . . 21
7.3. Registration of new "addrtype" values . . . . . . . . . . 22 8. Security Considerations . . . . . . . . . . . . . . . . . . . 22
7.4. Registration of a new "proto" value . . . . . . . . . . . 22 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22
8. Security Considerations . . . . . . . . . . . . . . . . . . . 23 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 10.1. Normative References . . . . . . . . . . . . . . . . . . . 22
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 10.2. Informative References . . . . . . . . . . . . . . . . . . 23
10.1. Normative References . . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24
10.2. Informative References . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25
1. Introduction 1. Introduction
The Session Description Protocol (SDP) [RFC4566] is intended for The Session Description Protocol (SDP) [RFC4566] is intended for
describing multimedia sessions for the purposes of session describing multimedia sessions for the purposes of session
announcement, session invitation, and other forms of multimedia announcement, session invitation, and other forms of multimedia
session initiation. SDP is most commonly used for describing media session initiation. SDP is most commonly used for describing media
streams that are transported over the Real-Time Transport Protocol streams that are transported over the Real-Time Transport Protocol
(RTP) [RFC3550], using the profiles for audio and video media defined (RTP) [RFC3550], using the profiles for audio and video media defined
in RTP Profile for Audio and Video Conferences with Minimal Control in RTP Profile for Audio and Video Conferences with Minimal Control
skipping to change at page 5, line 24 skipping to change at page 5, line 24
codecs for each access type and get an agreement on the bearer codecs for each access type and get an agreement on the bearer
together with the remote endpoint. together with the remote endpoint.
There are additional use cases related to third party call control There are additional use cases related to third party call control
where the session setup time is improved when the circuit-switched where the session setup time is improved when the circuit-switched
bearer in the PSTN is described together with one or more codecs. bearer in the PSTN is described together with one or more codecs.
The rest of the document is structured as follows: Section 2 provides The rest of the document is structured as follows: Section 2 provides
the document conventions, Section 3 introduces the requirements, the document conventions, Section 3 introduces the requirements,
Section 4 presents an overview of the proposed solutions, and Section 4 presents an overview of the proposed solutions, and
Section 5 contains the protocol description. Section 6 provides a Section 5 contains the protocol description. Section 6 provides an
few examples of descriptions of circuit-switched audio or video example of descriptions of circuit-switched audio or video streams in
streams in SDP. Section 7 and Section 8 contain the IANA and SDP. Section 7 and Section 8 contain the IANA and Security
Security considerations, respectively. considerations, respectively.
2. Conventions Used in This Document 2. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14, RFC 2119 document are to be interpreted as described in BCP 14, RFC 2119
[RFC2119] and indicate requirement levels for compliant [RFC2119] and indicate requirement levels for compliant
implementations. implementations.
3. Requirements 3. Requirements
skipping to change at page 11, line 15 skipping to change at page 11, line 15
The second mechanism is based on the inclusion in SDP of a value that The second mechanism is based on the inclusion in SDP of a value that
is also sent in the User-to-User Information Element that is part of is also sent in the User-to-User Information Element that is part of
the bearer setup signaling in the PSTN. the bearer setup signaling in the PSTN.
The third mechanism is based on sending in SDP a string that The third mechanism is based on sending in SDP a string that
represents Dual Tone MultiFrequency (DTMF) digits that will be later represents Dual Tone MultiFrequency (DTMF) digits that will be later
sent right after the circuit-switched bearer is established. sent right after the circuit-switched bearer is established.
Implementations MAY use any of these mechanisms and MAY use two or Implementations MAY use any of these mechanisms and MAY use two or
more mechanisms simultaneously. more mechanisms simultaneously.
5.2.3.1. The "correlation" attribute 5.2.3.1. The "cs-correlation" attribute
In order to provide support for the correlation mechanisms, we define In order to provide support for the correlation mechanisms, we define
a new SDP attribute called "cs-correlation". This "cs-correlation" a new SDP attribute called "cs-correlation". This "cs-correlation"
attribute can include any of the "callerid", "uuie", or "dtmf" attribute can include any of the "callerid", "uuie", or "dtmf"
parameters, which specify additional information required by the parameters, which specify additional information required by the
Caller-ID, User to User Information, or DTMF correlation mechanisms, Caller-ID, User to User Information, or DTMF correlation mechanisms,
respectively. respectively. The list of correlation mechanisms may be extended by
other specifications.
The following sections provide more detailed information of these The following sections provide more detailed information of these
parameters. The "cs-correlation" attribute has the following format: parameters. The "cs-correlation" attribute has the following format:
"a=cs-correlation: "callerid:<callerid-value>" | "a=cs-correlation: "callerid:<callerid-value>" |
"uuie:<uuie-value>" | "uuie:<uuie-value>" |
"dtmf:<dtmf-value>" "dtmf:<dtmf-value>"
The values "callerid", "uuie" and "dtmf" refer to the correlation The values "callerid", "uuie" and "dtmf" refer to the correlation
mechanisms defined in Section 5.2.3.2, Section 5.2.3.3, and mechanisms defined in Section 5.2.3.2, Section 5.2.3.3, and
skipping to change at page 12, line 52 skipping to change at page 13, line 6
A second correlation mechanism is based on indicating in SDP a string A second correlation mechanism is based on indicating in SDP a string
that represents the User-User Information Element that is part of the that represents the User-User Information Element that is part of the
call setup signaling of the circuit-switched bearer. The User-User call setup signaling of the circuit-switched bearer. The User-User
Information Element is specified in ITU-T Q.931 [ITU.Q931.1998] and Information Element is specified in ITU-T Q.931 [ITU.Q931.1998] and
3GPP TS 24.008 [3GPP.24.008], among others. The User-User 3GPP TS 24.008 [3GPP.24.008], among others. The User-User
Information Element has a maximum size of 35 or 131 octets, depending Information Element has a maximum size of 35 or 131 octets, depending
on the actual message of the PSTN protocol where it is included. on the actual message of the PSTN protocol where it is included.
The mechanism works as follows: An endpoint creates a User-User The mechanism works as follows: An endpoint creates a User-User
Information Element, according to the requirement of the call setup Information Element, according to the requirements of the call setup
signaling protocol. The same value is included in the SDP offer or signaling protocol. The same value is included in the SDP offer or
SDP answer, in a "cs-correlation:uuie" attribute. When the SDP SDP answer, in a "cs-correlation:uuie" attribute. When the SDP
offer/answer exchange is completed, each endpoint has become aware of offer/answer exchange is completed, each endpoint has become aware of
the value that will be used in the User-User Information Element of the value that will be used in the User-User Information Element of
the call setup message of the PSTN protocol. The endpoint that the call setup message of the PSTN protocol. The endpoint that
initiates the call setup attempt includes this value in the User-User initiates the call setup attempt includes this value in the User-User
Information Element. The recipient of the call setup attempt can Information Element. The recipient of the call setup attempt can
extract the User-User Information Element and correlate it with the extract the User-User Information Element and correlate it with the
value previously received in the SDP. If both values match, then the value previously received in the SDP. If both values match, then the
call setup attempt corresponds to that indicated in the SDP. call setup attempt corresponds to that indicated in the SDP.
skipping to change at page 13, line 49 skipping to change at page 13, line 52
hand, the generation of the User-User Information Element is hand, the generation of the User-User Information Element is
controlled by the PSTN circuit-switched call protocol, which might controlled by the PSTN circuit-switched call protocol, which might
not offer enough freedom for generating different values from one not offer enough freedom for generating different values from one
endpoint to another one, or from one call to another in the same endpoint to another one, or from one call to another in the same
endpoint. This might result in the same value of the User-User endpoint. This might result in the same value of the User-User
Information Element for all calls. Information Element for all calls.
5.2.3.4. DTMF Correlation Mechanism 5.2.3.4. DTMF Correlation Mechanism
We introduce a third mechanism for correlating the circuit-switched We introduce a third mechanism for correlating the circuit-switched
bearer with the session controlled with SDP. This is based in bearer with the session controlled with SDP. This is based on
agreeing on a sequence of digits that are negotiated in the SDP agreeing on a sequence of digits that are negotiated in the SDP
Offer/Answer exchange and sent as Dual Tone Multifrequency Offer/Answer exchange and sent as Dual Tone Multifrequency
(DTMF)tones over the circuit-switched bearer once this bearer is (DTMF)tones over the circuit-switched bearer once this bearer is
established. If the DTMF digit sequence received through the established. If the DTMF digit sequence received through the
circuit-switched bearer matches the digit string negotiated in the circuit-switched bearer matches the digit string negotiated in the
SDP, the circuit-switched bearer is correlated with the session SDP, the circuit-switched bearer is correlated with the session
described in the SDP. The mechanism is similar to many voice described in the SDP. The mechanism is similar to many voice
conferencing systems which require the user to enter a PIN code using conferencing systems which require the user to enter a PIN code using
DTMF tones in order to be accepted in a voice conference. DTMF tones in order to be accepted in a voice conference.
skipping to change at page 19, line 5 skipping to change at page 19, line 8
The following is the formal Augmented Backus-Naur Form (ABNF) The following is the formal Augmented Backus-Naur Form (ABNF)
[RFC5234] syntax that supports the extensions defined in this [RFC5234] syntax that supports the extensions defined in this
specification. The syntax is built above the SDP [RFC4566] grammar. specification. The syntax is built above the SDP [RFC4566] grammar.
Implementations according to this specification MUST be compliant Implementations according to this specification MUST be compliant
with this syntax. with this syntax.
Figure 2 shows the formal syntax of the extensions defined in this Figure 2 shows the formal syntax of the extensions defined in this
memo. memo.
; extension to the connection field originally specified ; extension to the connection field originally specified
; in RFC 4566 ; in RFC 4566
connection-field = [%x63 "=" nettype SP addrtype SP connection-field = [%x63 "=" nettype SP addrtype SP
connection-address CRLF] connection-address CRLF]
;nettype and addrtype are defined in RFC 4566 ;nettype and addrtype are defined in RFC 4566
connection-address /= e164-address / "-" connection-address /= e164-address / "-"
e164-address = ["+"] 1*15DIGIT e164-address = ["+"] 1*15DIGIT
; DIGIT is specified in RFC 5234 ; DIGIT is specified in RFC 5234
;subrules for correlation attribute ;subrules for correlation attribute
attribute /= cs-correlation-attr attribute /= cs-correlation-attr
; attribute defined in RFC 4566 ; attribute defined in RFC 4566
cs-correlation-attr= "cs-correlation:" corr-mechanisms cs-correlation-attr= "cs-correlation:" corr-mechanisms
corr-mechanisms = corr-mech *(SP corr-mech) corr-mechanisms = corr-mech *(SP corr-mech)
corr-mech = caller-id-mech / uuie-mech / dtmf-mech corr-mech = caller-id-mech / uuie-mech / dtmf-mech / ext-mech
caller-id-mech = "callerid" [":" caller-id-value] caller-id-mech = "callerid" [":" caller-id-value]
caller-id-value = ["+"] 1*DIGIT caller-id-value = ["+"] 1*DIGIT
uuie-mech = "uuie" [":" uuie-value] uuie-mech = "uuie" [":" uuie-value]
uuie-value = 1*32(ALPHA/DIGIT) uuie-value = 1*32(ALPHA/DIGIT)
dtmf-mech = "dtmf" [":" dtmf-value] dtmf-mech = "dtmf" [":" dtmf-value]
dtmf-value = 1*32(DIGIT / %x41-44 / %x23 / %x2A ) dtmf-value = 1*32(DIGIT / %x41-44 / %x23 / %x2A )
;0-9, A-D, '#' and '*' ;0-9, A-D, '#' and '*'
ext-mech = token
; token is specified in RFC4566
Figure 2: Syntax of the SDP extensions Figure 2: Syntax of the SDP extensions
6. SDP Examples 6. SDP Examples
6.1. Basic SDP example: Single Circuit-Switched Audio Stream 6.1. Basic SDP example: Single Circuit-Switched Audio Stream
Alice Bob Alice Bob
| | | |
| (1) SDP Offer (PSTN audio) | | (1) SDP Offer (PSTN audio) |
|--------------------------------->| |--------------------------------->|
| | | |
| (2) SDP Answer (PSTN audio) | | (2) SDP Answer (PSTN audio) |
|<---------------------------------| |<---------------------------------|
| | | |
skipping to change at page 20, line 27 skipping to change at page 20, line 44
s= s=
t=0 0 t=0 0
m=audio 9 PSTN - m=audio 9 PSTN -
c=PSTN E164 +15551234 c=PSTN E164 +15551234
a=setup:actpass a=setup:actpass
a=connection:new a=connection:new
a=cs-correlation:uuie:2890W284hAT452612908awudfjang908 a=cs-correlation:uuie:2890W284hAT452612908awudfjang908
Figure 4: SDP offer (1) Figure 4: SDP offer (1)
6.2. Advanced SDP example: Alternative and IP Circuit-Switched Audio
and Video Streams
Alice Bob
| |
| (1) SDP Offer (IP and PSTN audio and video)|
|------------------------------------------->|
| |
| (2) SDP Answer (PSTN audio and video) |
|<-------------------------------------------|
| |
| PSTN call setup |
|<-------------------------------------------|
| |
|<======== media over PSTN bearer ==========>|
| |
Figure 5: Alternative media
Figure 5 shows an example of negotiating audio and video media
streams over IP or circuit-switched bearers. Using the mechanisms
described in SDP Capability Negotiation Framework
[I-D.ietf-mmusic-sdp-capability-negotiation] and extensions thereof
(SDP media capabilities Negotiation
[I-D.ietf-mmusic-sdp-media-capabilities] and SDP Miscellaneous
Capabilities [I-D.garcia-mmusic-sdp-misc-cap]) it is possible to
construct an SDP offer where audio and video media can be offered
alternatively over IP or circuit-switched bearer.
v=0
o=jdoe 2890844526 2890842807 IN IP4 192.0.2.5
s=
t=0 0
c=IN IP4 192.0.2.5
a=sescap:1 1,3
a=sescap:2 2,4
a=creq:med-v0,ccap-v0
a=acap:1 cs-correlation:uuie:2890W284hAT452612908awudfjang908
a=acap:2 setup:actpass
a=acap:3 connection:new
a=tcap:1 PSTN
m=audio 49170 RTP/AVP 0 8 3
a=mcap:1 -
a=ccap:1 PSTN E164 +15551234 9
a=pcfg:1
a=pcfg:2 m=1 t=1 c=1 a=1,2,3
m=video 49174 RTP/AVP 34
a=mcap:2 -
a=ccap:2 PSTN E164 +15551234 9
a=pcfg:3
a=pcfg:4 m=2 t=1 c=2 a=1,2,3
Figure 6: SDP offer with alternative media (1)
Upon receiving the SDP offer descibed in Figure 6, Bob decided to
select the circuit-switched bearer and generates the answer described
in Figure 7
v=0
o=- 2890973824 2890987289 IN IP4 192.0.2.7
s=
t=0 0
a=setup:active
a=connection:new
a=cs-correlation:uuie:2890W284hAT452612908awudfjang908
m=audio 9 PSTN -
c= PSTN E164 +1551234
m=video 9 PSTN -
c=PSTN E164 +1551234
a=acfg:2
Figure 7: SDP answer with circuit-switched media (2)
7. IANA Considerations 7. IANA Considerations
This document instructs IANA to register a number of SDP tokens This document instructs IANA to register a number of SDP tokens
according to the following data. according to the following data.
7.1. Registration of new correlation SDP attribute 7.1. Registration of new correlation SDP attribute
Contact: Miguel Garcia <miguel.a.garcia@ericsson.com> Contact: Miguel Garcia <miguel.a.garcia@ericsson.com>
Attribute name: cs-correlation Attribute name: cs-correlation
skipping to change at page 24, line 22 skipping to change at page 23, line 18
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008. Specifications: ABNF", STD 68, RFC 5234, January 2008.
10.2. Informative References 10.2. Informative References
[3GPP.24.008] [3GPP.24.008]
3GPP, "Mobile radio interface Layer 3 specification; Core 3GPP, "Mobile radio interface Layer 3 specification; Core
network protocols; Stage 3", 3GPP TS 24.008 3.20.0, network protocols; Stage 3", 3GPP TS 24.008 3.20.0,
December 2005. December 2005.
[I-D.garcia-mmusic-sdp-misc-cap]
Garcia, M., Veikkolainen, S., and R. Gilman,
"Miscellaneous Capabilities Negotiation in the Session
Description Protocol (SDP)",
draft-garcia-mmusic-sdp-misc-cap-01 (work in progress),
July 2009.
[I-D.ietf-mmusic-sdp-capability-negotiation]
Andreasen, F., "SDP Capability Negotiation",
draft-ietf-mmusic-sdp-capability-negotiation-10 (work in
progress), May 2009.
[I-D.ietf-mmusic-sdp-media-capabilities]
Gilman, R., Even, R., and F. Andreasen, "SDP media
capabilities Negotiation",
draft-ietf-mmusic-sdp-media-capabilities-08 (work in
progress), July 2009.
[ITU.E164.1991] [ITU.E164.1991]
International Telecommunications Union, "The International International Telecommunications Union, "The International
Public Telecommunication Numbering Plan", ITU- Public Telecommunication Numbering Plan", ITU-
T Recommendation E.164, 1991. T Recommendation E.164, 1991.
[ITU.Q931.1998] [ITU.Q931.1998]
"Digital Subscriber Signalling System No. 1 (DSS 1) - ISDN "Digital Subscriber Signalling System No. 1 (DSS 1) - ISDN
User - Network Interface Layer 3 Specification for Basic User - Network Interface Layer 3 Specification for Basic
Call Control", ISO Standard 9594-1, May 1998. Call Control", ISO Standard 9594-1, May 1998.
 End of changes. 20 change blocks. 
151 lines changed or deleted 54 lines changed or added

This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/