< draft-ietf-mmusic-sdp-cs-17.txt		draft-ietf-mmusic-sdp-cs-18.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: July 18, 2013 Nokia		Expires: October 27, 2013 Nokia
	January 14, 2013		April 25, 2013
	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 Switched		Video Media Streams Over Circuit-Switched Bearers In The Public Switched
	Telephone Network (PSTN)		Telephone Network (PSTN)
	draft-ietf-mmusic-sdp-cs-17		draft-ietf-mmusic-sdp-cs-18
	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 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). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		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."
	This Internet-Draft will expire on July 18, 2013.		This Internet-Draft will expire on October 27, 2013.
	Copyright Notice		Copyright Notice
	Copyright (c) 2013 IETF Trust and the persons identified as the		Copyright (c) 2013 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 Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Conventions Used in This Document . . . . . . . . . . . . . . 6		2. Conventions Used in This Document . . . . . . . . . . . . . . 4
	3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 6		3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 4
	4. Overview of Operation . . . . . . . . . . . . . . . . . . . . 7		4. Overview of Operation . . . . . . . . . . . . . . . . . . . . 5
	4.1. Example Call Flow . . . . . . . . . . . . . . . . . . . . 7		4.1. Example Call Flow . . . . . . . . . . . . . . . . . . . . 5
	5. Protocol Description . . . . . . . . . . . . . . . . . . . . . 9		5. Protocol Description . . . . . . . . . . . . . . . . . . . . 7
	5.1. Level of Compliance . . . . . . . . . . . . . . . . . . . 9		5.1. Level of Compliance . . . . . . . . . . . . . . . . . . . 7
	5.2. Extensions to SDP . . . . . . . . . . . . . . . . . . . . 9		5.2. Extensions to SDP . . . . . . . . . . . . . . . . . . . . 7
	5.2.1. Connection Data . . . . . . . . . . . . . . . . . . . 9		5.2.1. Connection Data . . . . . . . . . . . . . . . . . . . 7
	5.2.2. Media Descriptions . . . . . . . . . . . . . . . . . . 11		5.2.2. Media Descriptions . . . . . . . . . . . . . . . . . 8
	5.2.3. Correlating the PSTN Circuit-Switched Bearer with		5.2.3. Correlating the PSTN Circuit-Switched Bearer with SDP 10
	SDP . . . . . . . . . . . . . . . . . . . . . . . . . 12		5.2.3.1. The "cs-correlation" attribute . . . . . . . . . 11
	5.2.3.1. The "cs-correlation" attribute . . . . . . . . . . 13		5.2.3.2. Caller-ID Correlation Mechanism . . . . . . . . . 11
	5.2.3.2. Caller-ID Correlation Mechanism . . . . . . . . . 13
	5.2.3.3. User-User Information Element Correlation		5.2.3.3. User-User Information Element Correlation
	Mechanism . . . . . . . . . . . . . . . . . . . . 14		Mechanism . . . . . . . . . . . . . . . . . . . . 12
	5.2.3.4. DTMF Correlation Mechanism . . . . . . . . . . . . 16		5.2.3.4. DTMF Correlation Mechanism . . . . . . . . . . . 14
	5.2.3.5. Extensions to correlation mechanisms . . . . . . . 17		5.2.3.5. Extensions to correlation mechanisms . . . . . . 15
	5.3. Negotiating the correlation mechanisms . . . . . . . . . . 17		5.3. Negotiating the correlation mechanisms . . . . . . . . . 15
	5.3.1. Determining the Direction of the Circuit-Switched		5.3.1. Determining the Direction of the Circuit-Switched
	Bearer Setup . . . . . . . . . . . . . . . . . . . . . 17		Bearer Setup . . . . . . . . . . . . . . . . . . . . 15
	5.3.2. Populating the cs-correlation attribute . . . . . . . 18		5.3.2. Populating the cs-correlation attribute . . . . . . . 16
	5.3.3. Considerations on correlations . . . . . . . . . . . . 19		5.3.3. Considerations on correlations . . . . . . . . . . . 17
	5.4. Considerations for Usage of Existing SDP . . . . . . . . . 19		5.4. Considerations for Usage of Existing SDP . . . . . . . . 18
	5.4.1. Originator of the Session . . . . . . . . . . . . . . 19		5.4.1. Originator of the Session . . . . . . . . . . . . . . 18
	5.4.2. Contact information . . . . . . . . . . . . . . . . . 20		5.4.2. Contact information . . . . . . . . . . . . . . . . . 18
	5.5. Considerations for Usage of Third Party Call Control		5.5. Considerations for Usage of Third Party Call Control
	(3PCC) . . . . . . . . . . . . . . . . . . . . . . . . . . 20		(3PCC) . . . . . . . . . . . . . . . . . . . . . . . . . 18
	5.6. Offer/Answer mode extensions . . . . . . . . . . . . . . . 21		5.6. Offer/Answer mode extensions . . . . . . . . . . . . . . 19
	5.6.1. Generating the Initial Offer . . . . . . . . . . . . . 21		5.6.1. Generating the Initial Offer . . . . . . . . . . . . 19
	5.6.2. Generating the Answer . . . . . . . . . . . . . . . . 23		5.6.2. Generating the Answer . . . . . . . . . . . . . . . . 21
	5.6.3. Offerer processing the Answer . . . . . . . . . . . . 26		5.6.3. Offerer processing the Answer . . . . . . . . . . . . 24
	5.6.4. Modifying the session . . . . . . . . . . . . . . . . 27		5.6.4. Modifying the session . . . . . . . . . . . . . . . . 25
	5.7. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . 27		5.7. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . 26
	6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 28		6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 27
	6.1. Single PSTN audio stream . . . . . . . . . . . . . . . . . 29		6.1. Single PSTN audio stream . . . . . . . . . . . . . . . . 27
	6.2. Advanced SDP example: Circuit-Switched Audio and Video		6.2. Advanced SDP example: Circuit-Switched Audio and
	Streams . . . . . . . . . . . . . . . . . . . . . . . . . 31		Video Streams . . . . . . . . . . . . . . . . . . . . . . 29
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 32		7. Security Considerations . . . . . . . . . . . . . . . . . . . 30
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31
	8.1. Registration of new cs-correlation SDP attribute . . . . . 33		8.1. Registration of new cs-correlation SDP attribute . . . . 31
	8.2. Registration of a new "nettype" value . . . . . . . . . . 34		8.2. Registration of a new "nettype" value . . . . . . . . . . 32
	8.3. Registration of new "addrtype" values . . . . . . . . . . 34		8.3. Registration of new "addrtype" values . . . . . . . . . . 32
	8.4. Registration of a new "proto" value . . . . . . . . . . . 34		8.4. Registration of a new "proto" value . . . . . . . . . . . 33
	9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 35
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35		9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 33
	10.1. Normative References . . . . . . . . . . . . . . . . . . . 35		10. References . . . . . . . . . . . . . . . . . . . . . . . . . 33
	10.2. Informative References . . . . . . . . . . . . . . . . . . 36		10.1. Normative References . . . . . . . . . . . . . . . . . . 33
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 37		10.2. Informative References . . . . . . . . . . . . . . . . . 34
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35
	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 6, line 43		skipping to change at page 4, line 49
	"OPTIONAL" in this document are to be interpreted as described in BCP		"OPTIONAL" in this document are to be interpreted as described in BCP
	14, RFC 2119 [RFC2119] and indicate requirement levels for compliant		14, RFC 2119 [RFC2119] and indicate requirement levels for compliant
	implementations.		implementations.
	3. Requirements		3. Requirements
	This section presents the general requirements that are specific for		This section presents the general requirements that are specific for
	the audio or video media streams over circuit-switched bearers.		the audio or video media streams over circuit-switched bearers.
	REQ-1: A mechanism for endpoints to negotiate and agree on an audio		REQ-1: A mechanism for endpoints to negotiate and agree on an audio
	or video media stream established over a circuit-switched		or video media stream established over a circuit-switched bearer
	bearer MUST be available.		MUST be available.
	REQ-2: The mechanism MUST allow the endpoints to combine circuit-		REQ-2: The mechanism MUST allow the endpoints to combine circuit-
	switched audio or video media streams with other		switched audio or video media streams with other complementary
	complementary media streams, for example, text messaging.		media streams, for example, text messaging.
	REQ-3: The mechanism MUST allow the endpoint to negotiate the		REQ-3: The mechanism MUST allow the endpoint to negotiate the
	direction of the circuit-switched bearer, i.e., which		direction of the circuit-switched bearer, i.e., which endpoint is
	endpoint is active when initiating the circuit-switched		active when initiating the circuit-switched bearer.
	bearer.
	REQ-4: The mechanism MUST be independent of the type of the circuit-		REQ-4: The mechanism MUST be independent of the type of the circuit-
	switched access (e.g., Integrated Services Digital Network		switched access (e.g., Integrated Services Digital Network (ISDN),
	(ISDN), Global System for Mobile Communication (GSM), etc.)		Global System for Mobile Communication (GSM), etc.)
	REQ-5: There MUST be a mechanism that helps an endpoint to correlate		REQ-5: There MUST be a mechanism that helps an endpoint to correlate
	an incoming circuit-switched bearer with the one negotiated		an incoming circuit-switched bearer with the one negotiated in
	in SDP, as opposed to another incoming call that is not		SDP, as opposed to another incoming call that is not related to
	related to that.		that.
	REQ-6: It MUST be possible for endpoints to advertise different		REQ-6: It MUST be possible for endpoints to advertise different
	lists of audio or video codecs in the circuit-switched audio		lists of audio or video codecs in the circuit-switched audio or
	or video stream from those used in a packet-switched audio or		video stream from those used in a packet-switched audio or video
	video stream.		stream.
	REQ-7: It MUST be possible for endpoints to not advertise the list		REQ-7: It MUST be possible for endpoints to not advertise the list
	of available codecs for circuit-switched audio or video		of available codecs for circuit-switched audio or video streams.
	streams.
	4. Overview of Operation		4. Overview of Operation
	The mechanism defined in this memo extends SDP and allows describing		The mechanism defined in this memo extends SDP and allows describing
	an audio or video media stream established over a circuit-switched		an audio or video media stream established over a circuit-switched
	bearer. A new network type ("PSTN") and a new protocol type ("PSTN")		bearer. A new network type ("PSTN") and a new protocol type ("PSTN")
	are defined for the "c=" and "m=" lines to be able to describe a		are defined for the "c=" and "m=" lines to be able to describe a
	media stream over a circuit-switched bearer. These SDP extensions		media stream over a circuit-switched bearer. These SDP extensions
	are described in Section 5.2. Since circuit-switched bearers are		are described in Section 5.2. Since circuit-switched bearers are
	connection-oriented media streams, the mechanism re-uses the		connection-oriented media streams, the mechanism re-uses the
	skipping to change at page 8, line 5		skipping to change at page 6, line 5
	4.1. Example Call Flow		4.1. Example Call Flow
	Consider the example presented in Figure 1. In this example, Alice		Consider the example presented in Figure 1. In this example, Alice
	is located in an environment where she has access to both IP and		is located in an environment where she has access to both IP and
	circuit-switched bearers for communicating with other endpoints.		circuit-switched bearers for communicating with other endpoints.
	Alice decides that the circuit-switched bearer offers a better		Alice decides that the circuit-switched bearer offers a better
	perceived quality of service for voice, and issues an SDP Offer		perceived quality of service for voice, and issues an SDP Offer
	containing the description of an audio media stream over circuit-		containing the description of an audio media stream over circuit-
	switched bearer.		switched bearer.
	Alice Bob		Alice Bob
	| (1) SDP Offer (PSTN audio) |		| (1) SDP Offer (PSTN audio) |
	|----------------------------------->|		|----------------------------------->|
	| |		| |
	| (2) SDP Answer (PSTN audio) |		| (2) SDP Answer (PSTN audio) |
	|<-----------------------------------|		|<-----------------------------------|
	| |		| |
	| PSTN call setup |		| PSTN call setup |
	|<-----------------------------------|		|<-----------------------------------|
	| |		| |
	| |		| |
	|<===== media over PSTN bearer =====>|		|<===== media over PSTN bearer =====>|
	| |		| |
	Figure 1: Example Flow		Figure 1: Example Flow
	Bob receives the SDP offer and determines that he is located in an		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		environment where the IP based bearer is not suitable for real-time
	audio media. However he also has PSTN circuit-switched bearer		audio media. However he also has PSTN circuit-switched bearer
	available for audio. Bob generates an SDP answer containing a		available for audio. Bob generates an SDP answer containing a
	description of the audio media stream over a circuit-switched bearer.		description of the audio media stream over a circuit-switched bearer.
	During the offer-answer exchange Alice and Bob also agree the		During the offer-answer exchange Alice and Bob also agree the
	skipping to change at page 10, line 36		skipping to change at page 8, line 36
	when unknown since this would violate basic syntax of SDP [RFC4566].		when unknown since this would violate basic syntax of SDP [RFC4566].
	In such cases, they MUST be set to a "-".		In such cases, they MUST be set to a "-".
	The following are examples of the extension to the connection data		The following are examples of the extension to the connection data
	line:		line:
	c=PSTN E164 +441134960123		c=PSTN E164 +441134960123
	c=PSTN - -		c=PSTN - -
	When the <addrtype> is PSTN, the connection address is defined as		When the <addrtype> is E164, the connection address is defined as
	follows:		follows:
	o an international E.164 number		o an international E.164 number
	When the <addrtype> is "-", the connection address is defined as		When the <addrtype> is "-", the connection address is defined as
	follows:		follows:
	o the value "-", signifying that the address is unknown		o the value "-", signifying that the address is unknown
	o any syntactically valid value, which is to be ignored		o any value resulting from the production rule of connection-address
			in RFC4566 [RFC4566], but in all cases any value encountered will
			be ignored.
	5.2.2. Media Descriptions		5.2.2. Media Descriptions
	According to SDP [RFC4566], the media description line in SDP has the		According to SDP [RFC4566], the media description line in SDP has the
	following syntax:		following syntax:
	m=<media> <port> <proto> <fmt> ...		m=<media> <port> <proto> <fmt> ...
	The <media> subfield carries the media type. For establishing an		The <media> subfield carries the media type. For establishing an
	audio bearer, the existing "audio" media type is used. For		audio bearer, the existing "audio" media type is used. For
	establishing a video bearer, the existing "video" media type is used.		establishing a video bearer, the existing "video" media type is used.
	The <port> subfield is the transport port to which the media stream		The <port> subfield is the transport port to which the media stream
	skipping to change at page 11, line 48		skipping to change at page 9, line 45
	subfield is set to "RTP/AVP" or "RTP/SAVP", the <fmt> subfield		subfield is set to "RTP/AVP" or "RTP/SAVP", the <fmt> subfield
	contains the payload types as defined in the RTP audio profile		contains the payload types as defined in the RTP audio profile
	[RFC3551].		[RFC3551].
	When "RTP/AVP" is used in the <proto> field, the <fmt> subfield		When "RTP/AVP" is used in the <proto> field, the <fmt> subfield
	contains the RTP payload type numbers. We use the <fmt> subfield to		contains the RTP payload type numbers. We use the <fmt> subfield to
	indicate the list of available codecs over the circuit-switched		indicate the list of available codecs over the circuit-switched
	bearer, by re-using the conventions and payload type numbers defined		bearer, by re-using the conventions and payload type numbers defined
	for RTP/AVP. The RTP audio and video media types, which, when		for RTP/AVP. The RTP audio and video media types, which, when
	applied to PSTN circuit-switched bearers, represent merely an audio		applied to PSTN circuit-switched bearers, represent merely an audio
	or video codec. The endpoint SHOULD only use those payload type		or video codec. If the endpoint is able to determine the list of
	whose corresponding codecs is available for PSTN media streams.		available codecs for circuit-switched media streams, it MUST use the
			corresponding payload type numbers in the <fmt> subfield.
	In some cases, the endpoint is not able to determine the list of		In some cases, the endpoint is not able to determine the list of
	available codecs for circuit-switched media streams. In this case,		available codecs for circuit-switched media streams. In this case,
	in order to be syntactically compliant with SDP [RFC4566], the		in order to be syntactically compliant with SDP [RFC4566], the
	endpoint MUST include a single dash ("-") in the <fmt> subfield.		endpoint MUST include a single dash ("-") in the <fmt> subfield.
	As per RFC 4566 [RFC4566], the media format descriptions are listed		As per RFC 4566 [RFC4566], the media format descriptions are listed
	in priority order.		in priority order.
	Examples of media descriptions for circuit-switched audio streams		Examples of media descriptions for circuit-switched audio streams
	skipping to change at page 13, line 21		skipping to change at page 11, line 24
	a new media-level SDP attribute called "cs-correlation". This "cs-		a new media-level SDP attribute called "cs-correlation". This "cs-
	correlation" attribute can include any of the "callerid", "uuie", or		correlation" attribute can include any of the "callerid", "uuie", or
	"dtmf" subfields, which specify additional information required by		"dtmf" subfields, which specify additional information required by
	the Caller-ID, User to User Information, or DTMF correlation		the Caller-ID, User to User Information, or DTMF correlation
	mechanisms, respectively. The list of correlation mechanisms may be		mechanisms, respectively. The list of correlation mechanisms may be
	extended by other specifications, see Section 5.2.3.5 for more		extended by other specifications, see Section 5.2.3.5 for more
	details. There MUST be at most one "cs-correlation" attribute per		details. There MUST be at most one "cs-correlation" attribute per
	media description.		media description.
	The following sections provide more detailed information of these		The following sections provide more detailed information of these
	subfields. Section 5.7> defined the formal syntax.		subfields.
	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
	Section 5.2.3.4, respectively. The formal Augmented Backus-Naur		Section 5.2.3.4, respectively. The formal Augmented Backus-Naur
	Format (ABNF) syntax of the "cs-correlation" attribute is presented		Format (ABNF) syntax of the "cs-correlation" attribute is presented
	in Section 5.7.		in Section 5.7.
	5.2.3.2. Caller-ID Correlation Mechanism		5.2.3.2. Caller-ID Correlation Mechanism
	The Caller-ID correlation mechanisms consists of an exchange of the		The Caller-ID correlation mechanisms consists of an exchange of the
	skipping to change at page 16, line 15		skipping to change at page 14, line 34
	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 described with SDP. This is based on		bearer with the session described 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
	Offer/Answer exchange and sent as Dual Tone Multifrequency (DTMF)		/Answer exchange and sent as Dual Tone Multifrequency (DTMF) tones
	tones over the circuit-switched bearer once this bearer is		over the circuit-switched bearer once this bearer is established. If
	established. If the DTMF digit sequence received through the		the DTMF digit sequence received through the circuit-switched bearer
	circuit-switched bearer matches the digit string negotiated in the		matches the digit string negotiated in the SDP, the circuit-switched
	SDP, the circuit-switched bearer is correlated with the session		bearer is correlated with the session described in the SDP. The
	described in the SDP. The mechanism is similar to many voice		mechanism is similar to many voice conferencing systems which require
	conferencing systems which require the user to enter a PIN code using		the user to enter a PIN code using DTMF tones in order to be accepted
	DTMF tones in order to be accepted in a voice conference.		in a voice conference.
	The mechanism works as follows: An endpoint selects a DTMF digit		The mechanism works as follows: An endpoint selects a DTMF digit
	sequence. The same sequence is included in the SDP offer or SDP		sequence. The same sequence is included in the SDP offer or SDP
	answer, in a "dtmf" subfield of the "cs-correlation" attribute. When		answer, in a "dtmf" subfield of the "cs-correlation" attribute. When
	the SDP Offer/Answer exchange is completed, each endpoint has become		the SDP Offer/Answer exchange is completed, each endpoint has become
	aware of the DTMF sequence that will be sent right after the circuit-		aware of the DTMF sequence that will be sent right after the circuit-
	switched bearer is set up. The endpoint that initiates the call		switched bearer is set up. The endpoint that initiates the call
	setup attempt sends the DTMF digits according to the procedures		setup attempt sends the DTMF digits according to the procedures
	defined for the circuit-switched bearer technology used. The		defined for the circuit-switched bearer technology used. The
	recipient (passive side of the bearer setup) of the call setup		recipient (passive side of the bearer setup) of the call setup
	skipping to change at page 17, line 32		skipping to change at page 16, line 4
	5.3. Negotiating the correlation mechanisms		5.3. Negotiating the correlation mechanisms
	The three correlation mechanisms presented above (based on called		The three correlation mechanisms presented above (based on called
	party number, User-User Information Element and DTMF digit sending)		party number, User-User Information Element and DTMF digit sending)
	are non-exclusive, and can be used independently of each other. In		are non-exclusive, and can be used independently of each other. In
	order to know how to populate the "cs-correlation" attribute, the		order to know how to populate the "cs-correlation" attribute, the
	endpoints need to agree which endpoint will become the active party,		endpoints need to agree which endpoint will become the active party,
	i.e., the one that will set up the circuit-switched bearer.		i.e., the one that will set up the circuit-switched bearer.
	5.3.1. Determining the Direction of the Circuit-Switched Bearer Setup		5.3.1. Determining the Direction of the Circuit-Switched Bearer Setup
	In order to avoid a situation where both endpoints attempt to		In order to avoid a situation where both endpoints attempt to
	initiate a connection simultaneously, the direction in which the		initiate a connection simultaneously, the direction in which the
	circuit-switched bearer is set up MUST be negotiated during the		circuit-switched bearer is set up MUST be negotiated during the Offer
	Offer/Answer exchange.		/Answer exchange.
	The framework defined in RFC 4145 [RFC4145] allows the endpoints to		The framework defined in RFC 4145 [RFC4145] allows the endpoints to
	agree which endpoint acts as the active endpoint when initiating a		agree which endpoint acts as the active endpoint when initiating a
	TCP connection. While RFC 4145 [RFC4145] was originally designed for		TCP connection. While RFC 4145 [RFC4145] was originally designed for
	establishing TCP connections, it can be easily extrapolated to the		establishing TCP connections, it can be easily extrapolated to the
	connection establishment of circuit-switched bearers. This		connection establishment of circuit-switched bearers. This
	specification uses the concepts specified in RFC 4145 [RFC4145] for		specification uses the concepts specified in RFC 4145 [RFC4145] for
	agreeing on the direction of establishment of a circuit-switched		agreeing on the direction of establishment of a circuit-switched
	bearer.		bearer.
	skipping to change at page 19, line 11		skipping to change at page 17, line 27
	MUST include all correlation mechanisms it supports in the "a=cs-		MUST include all correlation mechanisms it supports in the "a=cs-
	correlation" attribute, and MUST also specify values for the		correlation" attribute, and MUST also specify values for the
	subfields.		subfields.
	5.3.3. Considerations on correlations		5.3.3. Considerations on correlations
	Passive endpoints should expect an incoming CS call for setting up		Passive endpoints should expect an incoming CS call for setting up
	the audio bearer. Passive endpoints MAY suppress the incoming CS		the audio bearer. Passive endpoints MAY suppress the incoming CS
	alert during a certain time periods. Additional restrictions can be		alert during a certain time periods. Additional restrictions can be
	applied, such as the passive endpoint not alerting incoming calls		applied, such as the passive endpoint not alerting incoming calls
	originated from the number that was observed uduring the offer/answer		originated from the number that was observed during the offer/answer
	negotiation.		negotiation.
	Note that it cannot be guaranteed that any given correlation		Note that it cannot be guaranteed that any given correlation
	mechanism will succeed even if the usage of those was agreed		mechanism will succeed even if the usage of those was agreed
	beforehand. This is due to the fact that the correlation mechanisms		beforehand. This is due to the fact that the correlation mechanisms
	require support from the circuit-switched bearer technology used.		require support from the circuit-switched bearer technology used.
	Therefore, even a single positive indication using any of these		Therefore, even a single positive indication using any of these
	mechanisms SHOULD be interpreted by the passive endpoint so that the		mechanisms SHOULD be interpreted by the passive endpoint so that the
	circuit-switched bearer establishment is related to the ongoing		circuit-switched bearer establishment is related to the ongoing
	skipping to change at page 20, line 29		skipping to change at page 18, line 46
	SDP [RFC4566] defines the "p=" line which may include the phone		SDP [RFC4566] defines the "p=" line which may include the phone
	number of the person responsible for the conference. Even though		number of the person responsible for the conference. Even though
	this line can carry a phone number, it is not suited for the purpose		this line can carry a phone number, it is not suited for the purpose
	of defining a connection address for the media. Therefore, we have		of defining a connection address for the media. Therefore, we have
	selected to define the PSTN specific connection addresses in the "c="		selected to define the PSTN specific connection addresses in the "c="
	line.		line.
	5.5. Considerations for Usage of Third Party Call Control (3PCC)		5.5. Considerations for Usage of Third Party Call Control (3PCC)
	Best Current Practices for Third Party Call Control (3pcc) in the		Best Current Practices for Third Party Call Control (3pcc) in the
	Session Initiation Protocol (SIP) [RFC3725] outlines several flows		Session Initiation Protocol (SIP) [RFC3725] outlines several flows
	which are possible in third party call control scenarios and		which are possible in third party call control scenarios and
	recommends some flows for specific situations.		recommends some flows for specific situations.
	One of the assumptions in [RFC3725] is that an SDP Offer may include		One of the assumptions in [RFC3725] is that an SDP Offer may include
	a "black hole" connection address, which has the property that		a "black hole" connection address, which has the property that
	packets sent to it will never leave the host which sent them. For		packets sent to it will never leave the host which sent them. For
	IPv4, this "black hole" connection address is 0.0.0.0, or a domain		IPv4, this "black hole" connection address is 0.0.0.0, or a domain
	name within the .invalid DNS top level domain.		name within the .invalid DNS top level domain.
	When using an E.164 address scheme in the context of third-party call		When using an E.164 address scheme in the context of third-party call
	skipping to change at page 21, line 32		skipping to change at page 19, line 45
	In the "m=" line, the endpoint MUST set the <media> subfield to		In the "m=" line, the endpoint MUST set the <media> subfield to
	"audio" or "video", depending on the media type, and the <proto>		"audio" or "video", depending on the media type, and the <proto>
	subfield to "PSTN". The <port> subfield SHOULD be set to "9" (the		subfield to "PSTN". The <port> subfield SHOULD be set to "9" (the
	discard port).		discard port).
	The <fmt> subfield carries the payload type number(s) the endpoint is		The <fmt> subfield carries the payload type number(s) the endpoint is
	wishing to use. Payload type numbers in this case refer to the		wishing to use. Payload type numbers in this case refer to the
	codecs that the endpoint wishes to use on the PSTN media stream. For		codecs that the endpoint wishes to use on the PSTN media stream. For
	example, if the endpoint wishes to use the GSM codec, it would add		example, if the endpoint wishes to use the GSM codec, it would add
	payload type number 3 in the list of codecs. The list of payload		payload type number 3 in the list of codecs. The list of payload
	types SHOULD only contain those codecs the endpoint is able to use on		types MUST only contain those codecs the endpoint is able to use on
	the PSTN bearer. In case the endpoint is not aware of the codecs		the PSTN bearer. In case the endpoint is not aware of the codecs
	available for the circuit-switched media streams, it MUST include a		available for the circuit-switched media streams, it MUST include a
	dash ("-") in the <fmt> subfield.		dash ("-") in the <fmt> subfield.
	For dynamic payload types, the endpoint MUST define the set of valid		For dynamic payload types, the endpoint MUST define the set of valid
	encoding names and related parameters using the "a=rtpmap" attribute		encoding names and related parameters using the "a=rtpmap" attribute
	line. See Section 6 of SDP [RFC4566] for details.		line. See Section 6 of SDP [RFC4566] for details.
	When generating the Offer, if the Offerer supports any of the		When generating the Offer, if the Offerer supports any of the
	correlation mechanisms defined in this memo, it MUST include an		correlation mechanisms defined in this memo, it MUST include an
	skipping to change at page 22, line 19		skipping to change at page 20, line 35
	o the international E.164 number as the value in the "callerid"		o the international E.164 number as the value in the "callerid"
	subfield,		subfield,
	o the contents of the User-User information element as the value of		o the contents of the User-User information element as the value of
	the "uuie" subfield, and/or		the "uuie" subfield, and/or
	o the DTMF tone string as the value of the "dtmf" subfield		o the DTMF tone string as the value of the "dtmf" subfield
	If the Offerer is only able to become the passive party in the		If the Offerer is only able to become the passive party in the
	circuit-switched bearer setup, it MUST add the "callerid", "uuie"		circuit-switched bearer setup, it MUST add at least one of the
	and/or "dtmf" subfields, but MUST NOT specify values for those		possible correlation mechanisms, but MUST NOT specify values for
	subfields.		those subfields.
	For example, if the Offerer is willing to use the User-User		For example, if the Offerer is willing to use the User-User
	Information element and DTMF digit sending mechanisms, but can only		Information element and DTMF digit sending mechanisms, but can only
	become the passive party, it includes the following lines in the SDP:		become the passive party, it includes the following lines in the SDP:
	a=cs-correlation:uuie dtmf		a=cs-correlation:uuie dtmf
	a=setup:passive		a=setup:passive
	If, on the other hand, the Offerer is willing to use the User-User		If, on the other hand, the Offerer is willing to use the User-User
	skipping to change at page 23, line 24		skipping to change at page 21, line 38
	The Offerer uses the "a=connection" attribute to decide whether a new		The Offerer uses the "a=connection" attribute to decide whether a new
	circuit-switched bearer is to be established or not. For the initial		circuit-switched bearer is to be established or not. For the initial
	Offer, the Offerer MUST use value 'new'.		Offer, the Offerer MUST use value 'new'.
	5.6.2. Generating the Answer		5.6.2. Generating the Answer
	If the Offer contained a circuit-switched audio or video stream, the		If the Offer contained a circuit-switched audio or video stream, the
	Answerer first determines whether it is able to accept and use such		Answerer first determines whether it is able to accept and use such
	streams. If the Answerer is not willing to use circuit-switched		streams. If the Answerer is not willing to use circuit-switched
	media for the session, it MUST construct an Answer where the port		media for the session, it MUST construct an Answer where the port
	number for such media stream(s) is set to zero, according to Section		number for such media stream(s) is set to zero, according to
	6 of An Offer/Answer Model with the Session Description Protocol		Section 6 of An Offer/Answer Model with the Session Description
	(SDP) [RFC3264]. If the Answerer is willing to use circuit-switched		Protocol (SDP) [RFC3264]. If the Answerer is willing to use circuit-
	media for the session, it MUST ignore the received port number		switched media for the session, it MUST ignore the received port
	(unless the port number is set to zero).		number (unless the port number is set to zero).
	If the Offer included a "-" as the payload type number, it indicates		If the Offer included a "-" as the payload type number, it indicates
	that the Offerer is not willing or able to define any specific		that the Offerer is not willing or able to define any specific
	payload type. Most often, a "-" is expected to be used instead of		payload type. Most often, a "-" is expected to be used instead of
	the payload type when the endpoint is not aware of or not willing to		the payload type when the endpoint is not aware of or not willing to
	define the codecs which will eventually be used on the circuit-		define the codecs which will eventually be used on the circuit-
	switched bearer. The circuit-switched signaling protocols have their		switched bearer. The circuit-switched signaling protocols have their
	own means of negotiating or indicating the codecs, therefore an		own means of negotiating or indicating the codecs, therefore an
	Answerer SHOULD accept such Offers, and SHOULD set the payload type		Answerer SHOULD accept such Offers, and SHOULD set the payload type
	to "-" also in the Answer.		to "-" also in the Answer.
	skipping to change at page 24, line 31		skipping to change at page 23, line 7
	international E.164 number in the "c=" line, the Answerer SHOULD		international E.164 number in the "c=" line, the Answerer SHOULD
	become the active party. If the Offer does not include an E.164		become the active party. If the Offer does not include an E.164
	number, and if the Answerer is aware of its international E.164		number, and if the Answerer is aware of its international E.164
	number, it MUST become the passive party. If the Offer does not		number, it MUST become the passive party. If the Offer does not
	include an E.164 number in the "c=" line and the Answerer is not		include an E.164 number in the "c=" line and the Answerer is not
	aware of its E.164 number, it MUST reject the circuit-switched media		aware of its E.164 number, it MUST reject the circuit-switched media
	by setting the port number to zero in the Answer.		by setting the port number to zero in the Answer.
	For each media description where the Offer includes a "a=cs-		For each media description where the Offer includes a "a=cs-
	correlation" attribute, the Answerer MUST select from the Offer those		correlation" attribute, the Answerer MUST select from the Offer those
	correlation mechanisms it supports, and include in the Answer one		correlation mechanisms it supports, and include in the Answer one "a
	"a=cs-correlation" attribute line containing those mechanisms it is		=cs-correlation" attribute line containing those mechanisms it is
	willing to use. The Answerer MUST only add one "a=cs-correlation"		willing to use. The Answerer MUST only add one "a=cs-correlation"
	attribute in those media descriptions where also the Offer included a		attribute in those media descriptions where also the Offer included a
	"a=cs-correlation" attribute. The Answerer MUST NOT add any		"a=cs-correlation" attribute. The Answerer MUST NOT add any
	mechanisms which were not included in the offer. If there are more		mechanisms which were not included in the offer. If there are more
	than one "cs-correlation" attributes per media description in the		than one "cs-correlation" attributes per media description in the
	Offer, the Answerer MUST discard all but the first for any media		Offer, the Answerer MUST discard all but the first for any media
	description. Also, the Answerer MUST discard all unknown "cs-		description. Also, the Answerer MUST discard all unknown "cs-
	correlation" attribute values.		correlation" attribute values.
	If the Answerer becomes the active party, it MUST add any of the		If the Answerer becomes the active party, it MUST add a value to any
	"callerid", "uuie" or "dtmf" subfield values.		of the possible subfields.
	If the Answerer becomes the passive party, it MUST NOT add values to		If the Answerer becomes the passive party, it MUST NOT add any values
	the "callerid", "uuie" and/or "dtmf" subfields.		to the subfields in the "cs-correlation" attribute.
	After generating and sending the Answer, if the Answerer became the		After generating and sending the Answer, if the Answerer became the
	active party, it		active party, it
	o MUST extract the E.164 number from the "c=" line of the Offer and		o MUST extract the E.164 number from the "c=" line of the Offer and
	MUST establish a circuit-switched bearer to that address.		MUST establish a circuit-switched bearer to that address.
	o if the SDP Answer contained a value for the "callerid" subfield,		o if the SDP Answer contained a value for the "callerid" subfield,
	MUST set the Calling Party Number Information Element to that		MUST set the Calling Party Number Information Element to that
	number,		number,
	o if the SDP Answer contained a value for the "uuie" subfield, MUST		o if the SDP Answer contained a value for the "uuie" subfield, MUST
	send the User-User Information element according to the rules		send the User-User Information element according to the rules
	defined for the circuit-switched technology used, and set the		defined for the circuit-switched technology used, and set the
	skipping to change at page 28, line 6		skipping to change at page 26, line 26
	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] and the		specification. The syntax is built above the SDP [RFC4566] and the
	tel URI [RFC3966] grammars. Implementations according to this		tel URI [RFC3966] grammars. Implementations according to this
	specification MUST be compliant with this syntax.		specification MUST be compliant 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 RFC4566
	connection-field = [%x63 "=" nettype SP addrtype SP		connection-field = [%x63 "=" nettype SP addrtype SP
	connection-address CRLF]		connection-address CRLF]
			; CRLF defined in RFC5234
	;nettype and addrtype are defined in RFC 4566		;nettype and addrtype are defined in RFC 4566
	connection-address /= global-number-digits / "-"		connection-address /= global-number-digits / "-"
	; global-number-digits specified in RFC 3966		; global-number-digits specified in RFC3966
	;subrules for correlation attribute		;subrules for correlation attribute
	attribute /= cs-correlation-attr		attribute /= cs-correlation-attr
	; attribute defined in RFC 4566		; attribute defined in RFC4566
	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 /		corr-mech = caller-id-mech / uuie-mech /
	dtmf-mech / ext-mech		dtmf-mech / ext-mech
	caller-id-mech = "callerid" [":" caller-id-value]		caller-id-mech = "callerid" [":" caller-id-value]
	caller-id-value = "+" 1*15DIGIT		caller-id-value = "+" 1*15DIGIT
			; DIGIT defined in RFC5234
	uuie-mech = "uuie" [":" uuie-value]		uuie-mech = "uuie" [":" uuie-value]
	uuie-value = 1*65(HEXDIG HEXDIG)		uuie-value = 1*65(HEXDIG HEXDIG)
	;This represents up to 130 HEXDIG		;This represents up to 130 HEXDIG
	; (65 octets)		; (65 octets)
	;HEXDIG defined in RFC5234		;HEXDIG defined in RFC5234
	;HEXDIG defined as 0-9, A-F		;HEXDIG defined as 0-9, A-F
	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 = ext-mech-name [":" ext-mech-value]		ext-mech = ext-mech-name [":" ext-mech-value]
	ext-mech-name = token		ext-mech-name = token
	ext-mech-value = token		ext-mech-value = token
	; token is specified in RFC4566		; token is specified in RFC4566
	Figure 2: Syntax of the SDP extensions		Figure 2: Syntax of the SDP extensions
	skipping to change at page 29, line 7		skipping to change at page 27, line 25
	6. Examples		6. Examples
	In the examples below, where an SDP line is too long to be displayed		In the examples below, where an SDP line is too long to be displayed
	as a single line, a breaking character "\" indicates continuation in		as a single line, a breaking character "\" indicates continuation in
	the following line. Note that this character is included for display		the following line. Note that this character is included for display
	purposes only. Implementations MUST write a single line without		purposes only. Implementations MUST write a single line without
	breaks.		breaks.
	6.1. Single PSTN audio stream		6.1. Single PSTN 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) |
	|<---------------------------------|		|<---------------------------------|
	| |		| |
	| PSTN call setup |		| PSTN call setup |
	|<---------------------------------|		|<---------------------------------|
	| |		| |
	|<==== media over PSTN bearer ====>|		|<==== media over PSTN bearer ====>|
	| |		| |
	Figure 3: Basic flow		Figure 3: Basic flow
	Figure 3 shows a basic example that describes a single audio media		Figure 3 shows a basic example that describes a single audio media
	stream over a circuit-switched bearer. Alice generates a SDP Offer		stream over a circuit-switched bearer. Alice generates a SDP Offer
	which is shown in Figure 4. The Offer describes a PSTN circuit-		which is shown in Figure 4. The Offer describes a PSTN circuit-
	switched bearer in the "m=" and "c=" line where it also indicates its		switched bearer in the "m=" and "c=" line where it also indicates its
	international E.164 number format. Additionally, Alice expresses		international E.164 number format. Additionally, Alice expresses
	that she can initiate the circuit-switched bearer or be the recipient		that she can initiate the circuit-switched bearer or be the recipient
	of it in the "a=setup" attribute line. The SDP Offer also includes		of it in the "a=setup" attribute line. The SDP Offer also includes
	correlation identifiers that this endpoint will insert in the Calling		correlation identifiers that this endpoint will insert in the Calling
	Party Number and/or User-User Information Element of the PSTN call		Party Number and/or User-User Information Element of the PSTN call
	setup if eventually this endpoint initiates the PSTN call.		setup if eventually this endpoint initiates the PSTN call.
	v=0		v=0
	o=jdoe 2890844526 2890842807 IN IP4 192.0.2.5		o=alice 2890844526 2890842807 IN IP4 192.0.2.5
	s=		s=
	t=0 0		t=0 0
	m=audio 9 PSTN -		m=audio 9 PSTN -
	c=PSTN E164 +441134960123		c=PSTN E164 +441134960123
	a=setup:actpass		a=setup:actpass
	a=connection:new		a=connection:new
	a=cs-correlation:callerid:+441134960123 \		a=cs-correlation:callerid:+441134960123 \
	uuie:56A390F3D2B7310023		uuie:56A390F3D2B7310023
	Figure 4: SDP offer (1)		Figure 4: SDP offer (1)
	Bob generates a SDP Answer (Figure 5), describing a PSTN audio media		Bob generates a SDP Answer (Figure 5), describing a PSTN audio media
	on port 9 without information on the media sub-type on the "m=" line.		on port 9 without information on the media sub-type on the "m=" line.
	The "c=" line contains Bob's international E.164 number. In the		The "c=" line contains Bob's international E.164 number. In the
	"a=setup" line Bob indicates that he is willing to become the active		"a=setup" line Bob indicates that he is willing to become the active
	endpoint when establishing the PSTN call, and he also includes the		endpoint when establishing the PSTN call, and he also includes the "a
	"a=cs-correlation" attribute line containing the values he is going		=cs-correlation" attribute line containing the values he is going to
	to include in the Calling Party Number and User-User IE of the PSTN		include in the Calling Party Number and User-User IE of the PSTN call
	call establishment.		establishment.
	v=0		v=0
	o=- 2890973824 2890987289 IN IP4 192.0.2.7		o=- 2890973824 2890987289 IN IP4 192.0.2.7
	s=		s=
	t=0 0		t=0 0
	m=audio 9 PSTN -		m=audio 9 PSTN -
	c=PSTN E164 +441134960124		c=PSTN E164 +441134960124
	a=setup:active		a=setup:active
	a=connection:new		a=connection:new
	a=cs-correlation:callerid:+441134960124 \		a=cs-correlation:callerid:+441134960124 \
	uuie:56A390F3D2B7310023		uuie:56A390F3D2B7310023
	Figure 5: SDP Answer with circuit-switched media		Figure 5: SDP Answer with circuit-switched media
	When Alice receives the Answer, she examines that Bob is willing to		When Alice receives the Answer, she examines that Bob is willing to
	become the active endpoint when setting up the PSTN call. Alice		become the active endpoint when setting up the PSTN call. Alice
	temporarily stores Bob's E.164 number and the User-User IE value of		temporarily stores Bob's E.164 number and the User-User IE value of
	the "cs-correlation" attribute, and waits for a circuit-switched		the "cs-correlation" attribute, and waits for a circuit-switched
	bearer establishment.		bearer establishment.
	Bob initiates a circuit-switched bearer using whatever circuit-		Bob initiates a circuit-switched bearer using whatever circuit-
	skipping to change at page 31, line 7		skipping to change at page 29, line 21
	received by the called party, or the format of the calling party		received by the called party, or the format of the calling party
	number is changed by the PSTN. Implementations may still accept such		number is changed by the PSTN. Implementations may still accept such
	call establishment attempts as being related to the session that was		call establishment attempts as being related to the session that was
	established in the IP network. As it cannot be guaranteed that the		established in the IP network. As it cannot be guaranteed that the
	values used for correlation are always passed intact through the		values used for correlation are always passed intact through the
	network, they should be treated as additional hints that the circuit-		network, they should be treated as additional hints that the circuit-
	switched bearer is actually related to the session.		switched bearer is actually related to the session.
	6.2. Advanced SDP example: Circuit-Switched Audio and Video Streams		6.2. Advanced SDP example: Circuit-Switched Audio and Video Streams
	Alice Bob		Alice Bob
	| |		| |
	| (1) SDP Offer (PSTN audio and video) |		| (1) SDP Offer (PSTN audio and video) |
	|------------------------------------------->|		|------------------------------------------->|
	| |		| |
	| (2) SDP Answer (PSTN audio) |		| (2) SDP Answer (PSTN audio) |
	|<-------------------------------------------|		|<-------------------------------------------|
	| |		| |
	| PSTN call setup |		| PSTN call setup |
	|<-------------------------------------------|		|<-------------------------------------------|
	| |		| |
	|<======== media over PSTN bearer ==========>|		|<======== media over PSTN bearer ==========>|
	| |		| |
	Figure 6: Circuit-Switched Audio and Video streams		Figure 6: Circuit-Switched Audio and Video streams
	Figure 6 shows an example of negotiating audio and video media		Figure 6 shows an example of negotiating audio and video media
	streams over circuit-switched bearers.		streams over circuit-switched bearers.
	v=0		v=0
	o=jdoe 2890844526 2890842807 IN IP4 192.0.2.5		o=alice 2890844526 2890842807 IN IP4 192.0.2.5
	s=		s=
	t=0 0		t=0 0
	a=setup:actpass		a=setup:actpass
	a=connection:new		a=connection:new
	c=PSTN E164 +441134960123		c=PSTN E164 +441134960123
	m=audio 9 PSTN -		m=audio 9 PSTN -
	a=cs-correlation:dtmf:1234536		a=cs-correlation:dtmf:1234536
	m=video 9 PSTN 34		m=video 9 PSTN 34
	a=rtpmap:34 H263/90000		a=rtpmap:34 H263/90000
	a=cs-correlation:callerid:+441134960123		a=cs-correlation:callerid:+441134960123
	Figure 7: SDP offer with circuit-switched audio and video (1)		Figure 7: SDP offer with circuit-switched audio and video (1)
	Upon receiving the SDP offer described in Figure 7, Bob rejects the		Upon receiving the SDP offer described in Figure 7, Bob rejects the
	video stream as his device does not currently support video, but		video stream as his device does not currently support video, but
	accepts the circuit-switched audio stream. As Alice indicated that		accepts the circuit-switched audio stream. As Alice indicated that
	she is able to become either the active, or passive party, Bob gets		she is able to become either the active, or passive party, Bob gets
	to select which role he would like to take. Since the Offer		to select which role he would like to take. Since the Offer
	contained the international E.164 number of Alice, Bob decides that		contained the international E.164 number of Alice, Bob decides that
	he becomes the active party in setting up the circuit-switched		he becomes the active party in setting up the circuit-switched
	bearer. Bob includes a new value in the "dtmf" subfield of the "cs-		bearer. Bob includes a new value in the "dtmf" subfield of the "cs-
	correlation" attribute, which he is going to send as DTMF tones once		correlation" attribute, which he is going to send as DTMF tones once
	the bearer setup is complete. The Answer is described in Figure 8		the bearer setup is complete. The Answer is described in Figure 8
	v=0
	o=- 2890973824 2890987289 IN IP4 192.0.2.7		v=0
	s=		o=- 2890973824 2890987289 IN IP4 192.0.2.7
	t=0 0		s=
	a=setup:active		t=0 0
	a=connection:new		a=setup:active
	c=PSTN E164 +441134960124		a=connection:new
	m=audio 9 PSTN -		c=PSTN E164 +441134960124
	a=cs-correlation:dtmf:654321		m=audio 9 PSTN -
	m=video 0 PSTN 34		a=cs-correlation:dtmf:654321
	a=cs-correlation:callerid:+441134960124		m=video 0 PSTN 34
			a=cs-correlation:callerid:+441134960124
	Figure 8: SDP answer with circuit-switched audio and video (2)		Figure 8: SDP answer with circuit-switched audio and video (2)
	7. Security Considerations		7. Security Considerations
	This document provides an extension on top of RFC 4566 [RFC4566], and		This document provides an extension on top of RFC 4566 [RFC4566], and
	RFC 3264 [RFC3264]. As such, the security considerations of those		RFC 3264 [RFC3264]. As such, the security considerations of those
	documents apply.		documents apply.
	This memo provides mechanisms to agree on a correlation identifier or		This memo provides mechanisms to agree on a correlation identifier or
	identifiers that are used to evaluate whether an incoming circuit-		identifiers that are used to evaluate whether an incoming circuit-
	switched bearer is related to an ongoing session in the IP domain.		switched bearer is related to an ongoing session in the IP domain.
	If an attacker replicates the correlation identifier and establishes		If an attacker replicates the correlation identifier and establishes
	a call within the time window the receiving endpoint is expecting a		a call within the time window the receiving endpoint is expecting a
	call, the attacker may be able to hijack the circuit-switched bearer.		call, the attacker may be able to hijack the circuit-switched bearer.
	These types of attacks are not specific to the mechanisms presented		These types of attacks are not specific to the mechanisms presented
	in this memo. For example, caller ID spoofing is a wellknown attack		in this memo. For example, caller ID spoofing is a well known attack
	in the PSTN. Users are advised to use the same caution before		in the PSTN. Users are advised to use the same caution before
	revealing sensitive information as they would on any other phone		revealing sensitive information as they would on any other phone
	call. Furthermore, users are advised that mechanisms that may be in		call. Furthermore, users are advised that mechanisms that may be in
	use in the IP domain for securing the media, like Secure RTP (SRTP)		use in the IP domain for securing the media, like Secure RTP (SRTP)
	[RFC3711], are not available in the CS domain.		[RFC3711], are not available in the CS domain.
	For the purposes of establishing a circuit-switched bearer, the		For the purposes of establishing a circuit-switched bearer, the
	active endpoint needs to know the passive endpoint's phone number.		active endpoint needs to know the passive endpoint's phone number.
	Phone numbers are sensitive information, and some people may choose		Phone numbers are sensitive information, and some people may choose
	not to reveal their phone numbers when calling using supplementary		not to reveal their phone numbers when calling using supplementary
	skipping to change at page 33, line 38		skipping to change at page 32, line 4
	Attribute name: cs-correlation		Attribute name: cs-correlation
	Long-form attribute name: PSTN Correlation Identifier		Long-form attribute name: PSTN Correlation Identifier
	Type of attribute: media level only		Type of attribute: media level only
	Subject to charset: No		Subject to charset: No
	Description: This attribute provides the Correlation Identifier		Description: This attribute provides the Correlation Identifier
	used in PSTN signaling		used in PSTN signaling
	Appropriate values:see Section 5.2.3.1		Appropriate values:see Section 5.2.3.1
	Specification: RFC XXXX		Specification: RFC XXXX
	The IANA is requested to create a subregistry for 'cs-correlation'		The IANA is requested to create a subregistry for 'cs-correlation'
	attribute under the Session Description Protocol (SDP) Parameters		attribute under the Session Description Protocol (SDP) Parameters
	registry. The initial values for the subregistry are presented in		registry. The initial values for the subregistry are presented in
	the following, and IANA is requested to add them into its database:		the following, and IANA is requested to add them into its database:
	Value of 'cs-correlation' attribute Reference Description		Value of 'cs-correlation' attribute Reference Description
	----------------------------------- --------- -----------		----------------------------------- --------- -----------
	callerid RFC XXXX Caller ID		callerid RFC XXXX Caller ID
	uuie RFC XXXX User-User		uuie RFC XXXX User-User
	Information Element		Information Element
	dtmf RFC XXXX Dual-tone Multifrequency		dtmf RFC XXXX Dual-tone Multifrequency
	Note for the RFC Editor: 'RFC XXXX' above should be replaced by a		Note for the RFC Editor: 'RFC XXXX' above should be replaced by a
	reference to the RFC number of this draft.		reference to the RFC number of this draft.
	As per the terminology in [RFC5226], the registration policy for new		As per the terminology in [RFC5226], the registration policy for new
	values of 'cs-correlation' parameter is 'Specification Required'.		values of 'cs-correlation' parameter is 'Specification Required'.
	8.2. Registration of a new "nettype" value		8.2. Registration of a new "nettype" value
	This memo provides instructions to IANA to register a new "nettype"		This memo provides instructions to IANA to register a new "nettype"
	in the Session Description Protocol Parameters registry [1]. The		in the Session Description Protocol Parameters registry [1]. The
	registration data, according to RFC 4566 [RFC4566] follows.		registration data, according to RFC 4566 [RFC4566] follows.
	Type SDP Name Reference		Type SDP Name Reference
	---- ------------------ ---------		---- ------------------ ---------
	nettype PSTN [RFCxxxx]		nettype PSTN [RFCxxxx]
	8.3. Registration of new "addrtype" values		8.3. Registration of new "addrtype" values
	This memo provides instructions to IANA to register two new		This memo provides instructions to IANA to register two new
	"addrtype" in the Session Description Protocol Parameters		"addrtype" in the Session Description Protocol Parameters registry
	registry [1]. The registration data, according to RFC 4566 [RFC4566]		[2]. The registration data, according to RFC 4566 [RFC4566] follows.
	follows.
	Type SDP Name Reference		Type SDP Name Reference
	---- ------------------ ---------		---- ------------------ ---------
	addrtype E164 [RFCxxxx]		addrtype E164 [RFCxxxx]
	- [RFCxxxx]		addrtype - [RFCxxxx]
			Note: RFC XXXX defines the "E164" and "-" addrtypes in the context of
	Note: RFC XXXX defines the "E164" and "-" addrtypes in conjunction		the "PSTN" nettype only. Please refer to the relevant RFC for a
	with the "PSTN" nettype only. Please refer to the relevant RFC for a
	description of that representation.		description of that representation.
	Note to IANA: The current "addrtype" sub-registry structure does not
	capture the fact that a given addrtype is defined in the context of a
	particular "nettype". The sub-registry structure should be to
	correct that as part of this registration.
	8.4. Registration of a new "proto" value		8.4. Registration of a new "proto" value
	This memo provides instructions to IANA to register a new "proto" in		This memo provides instructions to IANA to register a new "proto" in
	the Session Description Protocol Parameters registry [1]. The		the Session Description Protocol Parameters registry [3]. The
	registration data, according to RFC 4566 [RFC4566] follows.		registration data, according to RFC 4566 [RFC4566] follows.
	Type SDP Name Reference		Type SDP Name Reference
	-------------- --------------------------- ---------		-------------- --------------------------- ---------
	proto PSTN [RFCxxxx]		proto PSTN [RFCxxxx]
	The related "fmt" namespace re-uses the conventions and payload type		The related "fmt" namespace re-uses the conventions and payload type
	number defined for RTP/AVP. In this document, the RTP audio and		number defined for RTP/AVP. In RFC XXXX, the RTP audio and video
	video media types, when applied to PSTN circuit-switched bearers,		media types, when applied to PSTN circuit-switched bearers, represent
	represent merely an audio or video codec in its native format		merely an audio or video codec in its native format directly on top
	directly on top of a single PSTN bearer.		of a single PSTN bearer.
	In come cases, the endpoint is not able to determine the list of		In come cases, the endpoint is not able to determine the list of
	available codecs for circuit-switched media streams. In this case,		available codecs for circuit-switched media streams. In this case,
	in order to be syntactically compliant with SDP [RFC4566], the		in order to be syntactically compliant with SDP [RFC4566], the
	endpoint MUST include a single dash ("-") in the <fmt> subfield.		endpoint MUST include a single dash ("-") in the <fmt> subfield.
	9. Acknowledgments		9. Acknowledgments
	The authors want to thank Paul Kyzivat, Flemming Andreasen, Thomas		The authors want to thank Paul Kyzivat, Flemming Andreasen, Thomas
	Belling, John Elwell, Jari Mutikainen, Miikka Poikselka, Jonathan		Belling, John Elwell, Jari Mutikainen, Miikka Poikselka, Jonathan
	skipping to change at page 35, line 37		skipping to change at page 33, line 45
	their insight and comments on this document.		their insight and comments on this document.
	10. References		10. References
	10.1. Normative References		10.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model		[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
	with Session Description Protocol (SDP)", RFC 3264,		with Session Description Protocol (SDP)", RFC 3264, June
	June 2002.		2002.
	[RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers",		[RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC
	RFC 3966, December 2004.		3966, December 2004.
	[RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in		[RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in
	the Session Description Protocol (SDP)", RFC 4145,		the Session Description Protocol (SDP)", RFC 4145,
	September 2005.		September 2005.
	[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session		[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
	Description Protocol", RFC 4566, July 2006.		Description Protocol", RFC 4566, July 2006.
	[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data		[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
	Encodings", RFC 4648, October 2006.		Encodings", RFC 4648, October 2006.
	skipping to change at page 36, line 20		skipping to change at page 34, line 27
	May 2008.		May 2008.
	[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
	[I-D.ietf-cuss-sip-uui]		[I-D.ietf-cuss-sip-uui]
	Johnston, A. and J. Rafferty, "A Mechanism for		Johnston, A. and J. Rafferty, "A Mechanism for
	Transporting User to User Call Control Information in		Transporting User to User Call Control Information in
	SIP", draft-ietf-cuss-sip-uui-08 (work in progress),		SIP", draft-ietf-cuss-sip-uui-10 (work in progress), April
	December 2012.		2013.
	[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
	T Recommendation E.164, 1991.		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) -
	User - Network Interface Layer 3 Specification for Basic		ISDN User - Network Interface Layer 3 Specification for
	Call Control", ISO Standard 9594-1, May 1998.		Basic Call Control", ISO Standard 9594-1, May 1998.
	[RFC3108] Kumar, R. and M. Mostafa, "Conventions for the use of the		[RFC3108] Kumar, R. and M. Mostafa, "Conventions for the use of the
	Session Description Protocol (SDP) for ATM Bearer		Session Description Protocol (SDP) for ATM Bearer
	Connections", RFC 3108, May 2001.		Connections", RFC 3108, May 2001.
	[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,		[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
	A., Peterson, J., Sparks, R., Handley, M., and E.		A., Peterson, J., Sparks, R., Handley, M., and E.
	Schooler, "SIP: Session Initiation Protocol", RFC 3261,		Schooler, "SIP: Session Initiation Protocol", RFC 3261,
	June 2002.		June 2002.
	skipping to change at page 37, line 14		skipping to change at page 35, line 22
	[RFC3725] Rosenberg, J., Peterson, J., Schulzrinne, H., and G.		[RFC3725] Rosenberg, J., Peterson, J., Schulzrinne, H., and G.
	Camarillo, "Best Current Practices for Third Party Call		Camarillo, "Best Current Practices for Third Party Call
	Control (3pcc) in the Session Initiation Protocol (SIP)",		Control (3pcc) in the Session Initiation Protocol (SIP)",
	BCP 85, RFC 3725, April 2004.		BCP 85, RFC 3725, April 2004.
	[RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message		[RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message
	Session Relay Protocol (MSRP)", RFC 4975, September 2007.		Session Relay Protocol (MSRP)", RFC 4975, September 2007.
	[TS.24.008]		[TS.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.
	URIs
	[1] <http://www.iana.org/assignments/sdp-parameters>
	Authors' Addresses		Authors' Addresses
	Miguel A. Garcia-Martin		Miguel A. Garcia-Martin
	Ericsson		Ericsson
	Calle Via de los Poblados 13		Calle Via de los Poblados 13
	Madrid, ES 28033		Madrid, ES 28033
	Spain		Spain
	Email: miguel.a.garcia@ericsson.com		Email: miguel.a.garcia@ericsson.com
End of changes. 60 change blocks.
	236 lines changed or deleted		228 lines changed or added
This html diff was produced by rfcdiff 1.39p1. The latest version is available from http://www.tools.ietf.org/tools/rfcdiff/