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/