draft-ietf-mmusic-sdp-cs-07.txt		draft-ietf-mmusic-sdp-cs-08.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: February 23, 2012 Nokia		Expires: April 15, 2012 Nokia
	August 22, 2011		October 13, 2011
	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
	Switched Telephone Network (PSTN)		Telephone Network (PSTN)
	draft-ietf-mmusic-sdp-cs-07		draft-ietf-mmusic-sdp-cs-08
	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
	skipping to change at page 1, line 36		skipping to change at page 1, line 36
	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 February 23, 2012.		This Internet-Draft will expire on April 15, 2012.
	Copyright Notice		Copyright Notice
	Copyright (c) 2011 IETF Trust and the persons identified as the		Copyright (c) 2011 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
	skipping to change at page 3, line 26		skipping to change at page 3, line 26
	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 "cs-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.3. Negotiating the correlation mechanisms . . . . . . . . . . 14		5.3. Negotiating the correlation mechanisms . . . . . . . . . . 14
	5.3.1. Determining the Direction of the Circuit-Switched		5.3.1. Determining the Direction of the Circuit-Switched
	Connection Setup . . . . . . . . . . . . . . . . . . . 14		Bearer Setup . . . . . . . . . . . . . . . . . . . . . 14
	5.3.2. Offerer behaviour . . . . . . . . . . . . . . . . . . 16		5.3.2. Populating the cs-correlation attribute . . . . . . . 15
	5.3.3. Answerer behaviour . . . . . . . . . . . . . . . . . . 17		5.3.3. Considerations on successful correlation . . . . . . . 16
	5.3.4. Considerations on successful correlation . . . . . . . 19		5.4. Considerations for Usage of Existing SDP . . . . . . . . . 16
	5.4. Considerations for Usage of Existing SDP . . . . . . . . . 19		5.4.1. Originator of the Session . . . . . . . . . . . . . . 16
	5.4.1. Originator of the Session . . . . . . . . . . . . . . 19		5.4.2. Contact information . . . . . . . . . . . . . . . . . 17
	5.4.2. Contact information . . . . . . . . . . . . . . . . . 20		5.5. Offer/Answer mode extensions . . . . . . . . . . . . . . . 17
	5.5. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . 20		5.5.1. Generating the Initial Offer . . . . . . . . . . . . . 17
	6. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 21		5.5.2. Generating the Answer . . . . . . . . . . . . . . . . 19
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22		5.5.3. Offerer processing the Answer . . . . . . . . . . . . 22
	7.1. Registration of new correlation SDP attribute . . . . . . 22		5.5.4. Modifying the session . . . . . . . . . . . . . . . . 23
	7.2. Registration of a new "nettype" value . . . . . . . . . . 23		5.6. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . 23
	7.3. Registration of new "addrtype" values . . . . . . . . . . 23		6. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
	7.4. Registration of a new "proto" value . . . . . . . . . . . 23		7. Security Considerations . . . . . . . . . . . . . . . . . . . 26
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 23		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
	9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24		8.1. Registration of new cs-correlation SDP attribute . . . . . 27
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24		8.2. Registration of a new "nettype" value . . . . . . . . . . 27
	10.1. Normative References . . . . . . . . . . . . . . . . . . . 24		8.3. Registration of new "addrtype" values . . . . . . . . . . 28
	10.2. Informative References . . . . . . . . . . . . . . . . . . 24		8.4. Registration of a new "proto" value . . . . . . . . . . . 28
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25		9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28
			10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28
			10.1. Normative References . . . . . . . . . . . . . . . . . . . 28
			10.2. Informative References . . . . . . . . . . . . . . . . . . 29
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30
	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 26		skipping to change at page 5, line 26
	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 an		Section 5 contains the protocol description. Section 6 provides an
	example of descriptions of circuit-switched audio or video streams in		example of descriptions of circuit-switched audio or video streams in
	SDP. Section 7 and Section 8 contain the IANA and Security		SDP. Section 8 and Section 7 contain the IANA and 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.
	skipping to change at page 6, line 6		skipping to change at page 6, line 6
	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 MUST be available.		bearer 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 media streams, for example, text messaging.		complementary 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 connection, i.e., which		direction of the circuit-switched bearer, i.e., which
	endpoint is active when initiating the circuit-switched		endpoint is active when initiating the circuit-switched
	connection.		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), Global System for Mobile Communication (GSM), etc.)		(ISDN), 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 SDP, as opposed to another incoming call that is not		in SDP, as opposed to another incoming call that is not
	related to that.		related to that.
	skipping to change at page 7, line 28		skipping to change at page 7, line 28
	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
	direction in which the circuit-switched connection should be		direction in which the circuit-switched bearer should be established.
	established. In this example, Bob becomes the active party, in other		In this example, Bob becomes the active party, in other words, he
	words, he establishes the circuit-switched call to the other		establishes the circuit-switched call to the other endpoint. The
	endpoint. The Offer/Answer exchange contains identifiers or		Offer/Answer exchange contains identifiers or references that can be
	references that can be used on the circuit-switched network for		used on the circuit-switched network for addressing the other
	addressing the other endpoint, as well as information that is used to		endpoint, as well as information that is used to determine that the
	determine that the incoming circuit-switched bearer establishment is		incoming circuit-switched bearer establishment is related to the
	related to the ongoing session between Alice and Bob.		ongoing session between Alice and Bob.
	Bob establishes a circuit-switched bearer towards Alice using		Bob establishes a circuit-switched bearer towards Alice using
	whatever mechanisms are defined for the network type in question.		whatever mechanisms are defined for the network type in question.
	When receiving the incoming circuit-switched connection attempt,		When receiving the incoming circuit-switched connection attempt,
	Alice is able to determine that the attempt is related to the session		Alice is able to determine that the attempt is related to the session
	she is just establishing with Bob.		she is just establishing with Bob.
	Alice accepts the circuit-switched connection; the circuit-switched		Alice accepts the circuit-switched connection; the circuit-switched
	bearer setup is completed. Bob and Alice can now use the circuit-		bearer setup is completed. Bob and Alice can now use the circuit-
	switched connection for two-way audio media.		switched connection for two-way audio media.
	skipping to change at page 8, line 11		skipping to change at page 8, line 11
	specified in RFC3264 [RFC3264]. Also, if Bob does not understand		specified in RFC3264 [RFC3264]. Also, if Bob does not understand
	some of the SDP attributes specified in this document, he would		some of the SDP attributes specified in this document, he would
	ignore them, as specified in RFC4566 [RFC4566].		ignore them, as specified in RFC4566 [RFC4566].
	5. Protocol Description		5. Protocol Description
	5.1. Level of Compliance		5.1. Level of Compliance
	Implementations according to this specification MUST implement the		Implementations according to this specification MUST implement the
	SDP extensions described in Section 5.2, and MUST implement the		SDP extensions described in Section 5.2, and MUST implement the
	considerations discussed in Section 5.3 and Section 5.4.		considerations discussed in Section 5.3, Section 5.4 and Section 5.5.
	5.2. Extensions to SDP		5.2. Extensions to SDP
	This section provides the syntax and semantics of the extensions		This section provides the syntax and semantics of the extensions
	required for providing a description of audio or video media streams		required for providing a description of audio or video media streams
	over circuit-switched bearers in SDP.		over circuit-switched bearers in SDP.
	5.2.1. Connection Data		5.2.1. Connection Data
	According to SDP [RFC4566], the connection data line in SDP has the		According to SDP [RFC4566], the connection data line in SDP has the
	skipping to change at page 11, line 31		skipping to change at page 11, line 31
	Caller-ID, User to User Information, or DTMF correlation mechanisms,		Caller-ID, User to User Information, or DTMF correlation mechanisms,
	respectively. The list of correlation mechanisms may be extended by		respectively. The list of correlation mechanisms may be extended by
	other specifications.		other specifications.
	The following sections provide more detailed information of these		The following sections provide more detailed information of these
	subfields. The "cs-correlation" attribute has the following format:		subfields. 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> |
	[extension-name:<extension-value>]		*[extension-name:<extension-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
	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.5.		in Section 5.6.
	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
	calling party number in E.164 format in SDP, followed by the		calling party number in E.164 format in SDP, followed by the
	availability of the Calling Party Number information element in the		availability of the Calling Party Number information element in the
	call setup signaling of the circuit switched connection. If both		call setup signaling of the circuit switched connection. If both
	pieces of information match, the circuit-switched bearer is		pieces of information match, the circuit-switched bearer is
	correlated to the session described in SDP.		correlated to the session described in SDP.
	Example of inclusion of E.164 number in the "cs-correlation"		Example of inclusion of E.164 number in the "cs-correlation"
	attribute is:		attribute is:
	a=cs-correlation:callerid:+15551234		a=cs-correlation:callerid:+15551234
	The presence of the "callerid" sub-field indicates that the endpoint		The presence of the "callerid" sub-field indicates that the endpoint
	supports use of the calling party number as a means of correlating a		supports use of the calling party number as a means of correlating a
	PSTN call with the session being negotiated. The "callerid" sub-		PSTN call with the session being negotiated. The "callerid" sub-
	field MAY be accompanied by the E.164 number of the party inserting		field MAY be accompanied by the E.164 number of the party inserting
	the parameter. For details on negotiating the correlation		the parameter.
	mechanisms, see Section 5.3.
	Note that there are no warranties that this correlation mechanism		Note that there are no warranties that this correlation mechanism
	works or is even available, due a number of problems:		works or is even available, due a number of problems:
	* The endpoint might not be aware of its own E.164 number, in		o The endpoint might not be aware of its own E.164 number, in which
	which case it cannot populate the SDP appropriately.		case it cannot populate the SDP appropriately.
	* The Calling Party Number information element in the circuit-		o The Calling Party Number information element in the circuit-
	switched signaling might not be available, e.g., due to policy		switched signaling might not be available, e.g., due to policy
	restrictions of the network operator or caller restriction due		restrictions of the network operator or caller restriction due to
	to privacy.		privacy.
	* The Calling Party Number information element in the circuit-		o The Calling Party Number information element in the circuit-
	switched signaling might be available, but the digit		switched signaling might be available, but the digit
	representation of the E.164 number might differ from the one		representation of the E.164 number might differ from the one
	expressed in the SDP. For example, one can be represented in		expressed in the SDP. For example, one can be represented in
	international format and the other might only contain the		international format and the other might only contain the
	significant national digits. To mitigate this problem		significant national digits. To mitigate this problem
	implementations should consider only some of the rightmost		implementations should consider only some of the rightmost digits
	digits from the E.164 number for correlation. For example, the		from the E.164 number for correlation. For example, the numbers
	numbers +358-1-555-12345 and 01-555-12345 could be considered		+358-1-555-12345 and 01-555-12345 could be considered as the same
	as the same number. This is also the behavior of some cellular		number. This is also the behavior of some cellular phones, which
	phones, which correlate the incoming calling party with a		correlate the incoming calling party with a number stored in the
	number stored in the phone book, for the purpose of displaying		phone book, for the purpose of displaying the caller's name.
	the caller's name.
	5.2.3.3. User-User Information Element Correlation Mechanism		5.2.3.3. User-User Information Element Correlation Mechanism
	A second correlation mechanism is based on including in SDP a string		A second correlation mechanism is based on including 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 [TS.24.008], among others. The User-User Information
	Information Element has a maximum size of 35 or 131 octets, depending		Element has a maximum size of 35 or 131 octets, depending on the
	on the actual message of the PSTN protocol where it is included.		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 requirements 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
	skipping to change at page 14, line 25		skipping to change at page 14, line 21
	As an example, an endpoint willing to send DTMF tone sequence "14D*3"		As an example, an endpoint willing to send DTMF tone sequence "14D*3"
	would include a "cs-correlation" attribute line as follows:		would include a "cs-correlation" attribute line as follows:
	a=cs-correlation:dtmf:14D*3		a=cs-correlation:dtmf:14D*3
	If the endpoints successfully agree on the usage of the DTMF digit		If the endpoints successfully agree on the usage of the DTMF digit
	correlation mechanism, but the passive side does not receive any DTMF		correlation mechanism, but the passive side does not receive any DTMF
	digits after successful circuit-switched bearer setup, or receives a		digits after successful circuit-switched bearer setup, or receives a
	set of DTMF digits that do not match the value of the "dtmf"		set of DTMF digits that do not match the value of the "dtmf"
	attribute (including receving too many digits), the passive side		attribute (including receiving too many digits), the passive side
	SHOULD treat the circuit-switched bearer as not correlated to the		SHOULD treat the circuit-switched bearer as not correlated to the
	ongoing session.		ongoing session.
	DTMF digits can only be sent once the circuit-switched bearer is		DTMF digits can only be sent once the circuit-switched bearer is
	set up. In order to suppress alerting for an incoming circuit-		set up. In order to suppress alerting for an incoming circuit-
	switched call, implementations may choose various mechanisms. For		switched call, implementations may choose various mechanisms. For
	example, alerting may be suppressed for a certain time period for		example, alerting may be suppressed for a certain time period for
	incoming call attempts that originate from the number that was		incoming call attempts that originate from the number that was
	observed during the offer/answer negotiation.		observed during the offer/answer negotiation.
	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.		are non-exclusive, and can be used independently of each other. In
			order to know how to populate the "a=cs-correlation" attribute, the
	In order to agree which correlation mechanisms are supported and used		endpoints need to agree which endpoint will become the active party,
	by each endpoint, we define a negotiation mechanism similar to the		i.e. the one that will set up the circuit-switched bearer.
	one defined for codec negotiation. The sections below describe
	active/passive party determination and Offerer and Answerer behaviour
	for negotiating the correlation mechanisms.
	5.3.1. Determining the Direction of the Circuit-Switched Connection		5.3.1. Determining the Direction of the Circuit-Switched Bearer Setup
	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 should be negotiated during the		circuit-switched bearer is set up should be negotiated during the
	Offer/Answer exchange.		Offer/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
	skipping to change at page 15, line 35		skipping to change at page 15, line 27
	The "connection" attribute indicates whether a new connection is		The "connection" attribute indicates whether a new connection is
	needed or an existing connection is reused. The attribute can take		needed or an existing connection is reused. The attribute can take
	the values "new" or "existing". Please refer to Section 5 of RFC		the values "new" or "existing". Please refer to Section 5 of RFC
	4145 [RFC4145] for a detailed description of this attribute.		4145 [RFC4145] for a detailed description of this attribute.
	Implementations according to this specification MUST support the		Implementations according to this specification MUST support the
	"setup" and "connection" attributes specified in RFC 4145 [RFC4145],		"setup" and "connection" attributes specified in RFC 4145 [RFC4145],
	but applied to circuit-switched bearers in the PSTN.		but applied to circuit-switched bearers in the PSTN.
	We define the active party as the one that initiates the circuit-		We define the active party as the one that initiates the circuit-
	switched call after the Offer/Answer process. The passive party is		switched bearer after the Offer/Answer process. The passive party is
	the one receiving the circuit-switched call. Either party may		the one receiving the circuit-switched bearer. Either party may
	indicate its desire to become the active or passive party during the		indicate its desire to become the active or passive party during the
	Offer/Answer exchange using the procedures described below.		Offer/Answer exchange using the procedures described in Section 5.5.
	In order to establish a circuit-switched connection in the PSTN, the		5.3.2. Populating the cs-correlation attribute
	initiating endpoint needs to know the address (E.164 number) of the
	other endpoint. Therefore, if an endpoint wants to be able to
	receive incoming circuit-switched calls (i.e., become the passive
	party), it must know its E.164 number and must indicate it in SDP.
	As a consequence, an endpoint that is not aware of its own E.164
	number cannot take the role of the passive side with respect the
	establishment of the circuit-switched connection.
	5.3.2. Offerer behaviour		By defining values for the sub-fields in the "a=cs-correlation"
			attribute, the endpoint indicates that it is willing to become the
			active party, and that it can use those values in the Calling party
			number, User-User Information Element, or as DTMF tones during the
			circuit-switched bearer setup.
	When generating the Offer, If the Offerer supports any of the		Thus, the following rules apply:
	correlation mechanisms defined in this memo, it SHOULD include an
			An endpoint that can only become the active party in the circuit-
			switched bearer setup MUST include all correlation mechanisms it
			supports in the "a=cs-correlation" attribute, and MUST also
			specify values for the sub-fields.
			An endpoint that can only become the passive party in the circuit-
			switched bearer setup MUST include all correlation mechanisms it
			supports in the "a=cs-correlation" attribute, but MUST NOT specify
			values for the sub-fields.
			An endpoint that is willing to become either the active or passive
			party (by including the "a=setup:actpass" attribute in the Offer),
			MUST include all correlation mechanisms it supports in the "a=cs-
			correlation" attribute, and MUST also specify values for the sub-
			fields.
			5.3.3. Considerations on successful correlation
			Note that, as stated above, it cannot be guaranteed that any given
			correlation mechanism will succeed even if the usage of those was
			agreed beforehand. This is due to the fact that the correlation
			mechanisms require support from the circuit-switched bearer
			technology used.
			Therefore, even a single positive indication using any of these
			mechanisms SHOULD be interpreted by the passive endpoint so that the
			circuit-switched bearer establishment is related to the ongoing
			session, even if the other correlation mechanisms fail.
			If, after negotiating one or more correlation mechanisms in the SDP
			offer/answer exchange, an endpoint receives a circuit-switched bearer
			with no correlation information present, the endpoint has two
			choices: it can either treat the call as unrelated, or treat the call
			as related to the ongoing session in the IP domain.
			An endpoint may for example specify a time window after SDP offer/
			answer exchange during which received calls are treated as correlated
			even if the signaling in the circuit-switched domain does not carry
			any correlation information. In this case, there is a chance that
			the call is erroneously treated as related to the ongoing session.
			An endpoint may also choose to always treat an incoming call as
			unrelated if the signaling in the circuit-switched domain does not
			carry any correlation information. In this case, there is a chance
			that the call is erroneously treated as unrelated.
			Since, in these cases, no correlation information can be deduced from
			the signaling, it is up to the implementation to decide how to
			behave. One option is also to let the user decide whether to accept
			the call as related, or to treat the call as unrelated.
			5.4. Considerations for Usage of Existing SDP
			5.4.1. Originator of the Session
			According to SDP [RFC4566], the origin line in SDP has the following
			syntax:
			o=<username> <sess-id> <sess-version> <nettype> <addrtype>
			<unicast-address>
			Of interest here are the <nettype> and <addrtype> fields, which
			indicate the type of network and type of address, respectively.
			Typically, this field carries the IP address of the originator of the
			session. Even if the SDP was used to negotiate an audio or video
			media stream transported over a circuit-switched bearer, the
			originator is using SDP over an IP bearer. Therefore, <nettype> and
			<addrtype> fields in the "o=" line should be populated with the IP
			address identifying the source of the signaling.
			5.4.2. Contact information
			SDP [RFC4566] defines the "p=" line which may include the phone
			number of the person responsible for the conference. Even though
			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
			selected to define the PSTN specific connection addresses in the "c="
			line.
			5.5. Offer/Answer mode extensions
			In this section, we define extensions to the Offer/Answer model
			defined in The Offer/Answer Model in SDP [RFC3264] and extended in
			the SDP Capability Negotiation [RFC5939] to allow for PSTN addresses
			to be used with the Offer/Answer model.
			5.5.1. Generating the Initial Offer
			The Offerer, wishing to use PSTN audio or video stream, MUST populate
			the "c=" and "m=" lines as follows.
			The endpoint MUST set the <nettype> in the "c=" line to "PSTN", and
			the <addrtype> to "E164". Furthermore, the endpoint SHOULD set the
			<connection-address> field to its own E.164 number in the
			international format (beginning with a "+"). If the endpoint is not
			aware of its own E.164 number, it MUST set the <connection-address>
			to "-".
			In the "m=" line, the endpoint MUST set the <media> subfield to
			"audio" or "video", depending on the media type, the <port> to "9"
			(the discard port), and the <proto> sub-field to "PSTN".
			The <fmt> sub-field carries the payload type number(s) the endpoint
			is wishing to use. Payload type numbers in this case refer to the
			codecs that the endpoint wishes to use. For example, if the endpoint
			wishes to use the GSM codec, it would add payload type number 3 in
			the list of codecs.
			For dynamic payload types, the endpoint MUST define the set of valid
			encoding names and related parameters using the "a=rtpmap" attribute
			line. See Section 6 of SDP [RFC4566] for details.
			When generating the Offer, if the Offerer supports any of the
			correlation mechanisms defined in this memo, it MUST include an
	attribute line "a=cs-correlation" in the SDP offer. The "a=cs-		attribute line "a=cs-correlation" in the SDP offer. The "a=cs-
	correlation" line contains an enumeration of the correlation		correlation" line contains an enumeration of the correlation
	mechanisms supported by the Offerer, in the format of sub-fields.		mechanisms supported by the Offerer, in the format of sub-fields.
	The current list of sub-fields include "callerid", "uuie" and "dtmf"		The current list of sub-fields include "callerid", "uuie" and "dtmf"
	and they refer to the correlation mechanisms defined in		and they refer to the correlation mechanisms defined in
	Section 5.2.3.2, Section 5.2.3.3, and Section 5.2.3.4, respectively.		Section 5.2.3.2, Section 5.2.3.3, and Section 5.2.3.4, respectively.
	If the Offerer is only able to become the active party (for example		If the Offerer supports any of the correlation mechanisms defined in
	because it doesn't know its E.164 address), the Offerer SHOULD add		this memo, and is willing to become the active party, the Offerer
	the "callerid", "uuie", and/or "dtmf" sub-fields but MUST NOT specify		MUST add the "callerid", "uuie", and/or "dtmf" sub-fields and MUST
	a value for those sub-fields.		specify values for those sub-fields.
	If the Offerer is able to become the passive party in the circuit-
	switched call setup, it SHOULD add values to all correlation
	mechanisms it supports:
	o the E.164 number as the value in the "callerid" sub-field,		o the E.164 number as the value in the "callerid" sub-field,
	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" sub-field, and		the "uuie" sub-field, and/or
	o the DTMF tone string as the value of the "dtmf" sub-field		o the DTMF tone string as the value of the "dtmf" sub-field
			If the Offerer is only able to become the passive party in the
			circuit-switched bearer setup, it MUST add the "callerid", "uuie"
			and/or "dtmf" sub-fields, but MUST NOT specify values for those sub-
			fields.
	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 active party, it includes the following line to the SDP:		become the passive party, it includes the following lines to the SDP:
	a=cs-correlation:uuie dtmf		a=cs-correlation:uuie dtmf
			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
	Information element and the DTMF correlation mechanisms, and is able		Information element and the DTMF correlation mechanisms, and is able
	to become the passive side, it includes to following line to the SDP:		to become the active or passive side, it includes to following lines
			to the SDP:
	a=cs-correlation:uuie:2890W284hAT452612908awudfjang908 dtmf:14D*3		a=cs-correlation:uuie:2890W284hAT452612908awudfjang908 dtmf:14D*3
	When receiving the Answer, if the SDP does not contain "a=cs-		a=setup:actpass
	correlation" attribute line, the Offerer should take that as an
	indication that the other party does not support or is not willing to
	use the procedures defined in the document for this session, and MUST
	revert to normal processing of SDP.
	When receiving the Answer, the Offerer MUST first determine whether		The negotiation of the value of the 'setup' attribute takes place as
	it becomes the active or passive party, as described in Section		defined in Section 4.1 of TCP-Based Media Transport in the SDP
	Section 5.3.1.		[RFC4145].
	If the Offerer becomes the active party, it		The Offerer states which role or roles it is willing to perform; and
			the Answerer, taking the Offerer's willingness into consideration,
			chooses which roles both endpoints will actually perform during the
			circuit-switched bearer setup.
	o SHOULD extract the E.164 address from the "c=" line and SHOULD		By 'active' endpoint, we refer to an endpoint that will establish the
	establish a circuit-switched call to that address.		circuit-switched bearer; and by 'passive' endpoint, we refer to an
			endpoint that will receive a circuit-switched bearer.
	o if the SDP Answer contained a value for the "uuie" sub-field,		If an Offerer does not know its E.164 address, it MUST set the
	SHOULD send the User-User Information element according to the		'a=setup' attribute to the value 'active'. If the Offerer knows its
	rules defined for the circuit-switched technology used, and set		E.164 address, it MUST set the value to either 'actpass' or
	the value of the Information Element to that received in the SDP		'passive'.
	Answer,
	o if the SDP Answer contained a value for the "dtmf" sub-field,		Also 'holdconn' is a permissible value in the 'a=setup' attribute.
	SHOULD send those DTMF digits according to the circuit-switched		It indicates that the connection is not established for the time
	technology used.		being.
	If the Offerer becomes the passive party, it		The Offerer uses the "a=connection" attribute to decide whether a new
			circuit-switched bearer is to be established or not. If there is no
			circuit-switched bearer established between the endpoints, the
			Offerer MUST use a value of 'new' in the "a=connection" attribute.
			If there is an existing circuit-switched bearer between the
			endpoints, and the Offerer wants to reuse that (for example, in the
			case of an updated Offer), the Offerer MUST set the value of the
			"a=connection" attribute to "existing".
	o MUST be prepared to receive a circuit-switched call,		5.5.2. Generating the Answer
	o MUST be prepared to receive and collect DTMF digits once the		If the Offer contained a circuit-switched audio or video stream, the
	circuit-switched bearer is set up. The Offerer SHOULD compare the		Answerer first determines whether it is able to accept and use such
	received DTMF digits to the value of the "dtmf" sub-field. If the		streams. If the Answerer is not willing to use circuit-switched
	received DTMF digits match the value of the "dtmf" sub-field in		media for the session, it MUST construct an Answer where the port
	the "cs-correlation" attribute, the call SHOULD be treated as		number for such media stream(s) is set to zero, according to Section
	correlated to the ongoing session.		6 of An Offer/Answer Model with the Session Description Protocol
			(SDP) [RFC3264].
	o MUST be prepared to receive a User-User Information element once		If the Offer included a "-" as the payload type number, it indicates
	the circuit-switched bearer is set up. The Offerer SHOULD compare		that the Offerer is not willing or able to define any specific
	the received UUI to the value of the "uuie" sub-field. If the		payload type. Most often, a "-" is expected to be used instead of
	value of the received UUI matches the value of the "uuie" sub-		the payload type when the endpoint is not aware of or not willing to
	field, the call SHOULD be treated as correlated to the ongoing		define the codecs which will eventually be used on the circuit-
	session.		switched bearer. The circuit-switched signaling protocols have their
			own means of negotiating or indicating the codecs, therefore an
			Answerer SHOULD accept such Offers, and SHOULD set the payload type
			to "-" also in the Answer.
	5.3.3. Answerer behaviour		If the Answerer explicitly wants to specify a codec for the circuit-
			switched media, it MAY set the respective payload numbers in the
			<fmt> sub-field in the answer. This behavior, however, is NOT
			RECOMMENDED.
	When receiving the Offer, the Answerer MUST first determine whether		When receiving the Offer, the Answerer MUST determine whether it
	it becomes the active or passive party, as described in Section		becomes the active or passive party.
	Section 5.3.1.
	If the SDP in the Offer indicates that the Offerer is only able to		If the SDP in the Offer indicates that the Offerer is only able to
	become the active party ("a=setup" line is set to "active", the		become the active party, the Answerer needs to determine whether it
	Answerer needs to determine whether it is able to become the passive		is able to become the passive party. If this is not possible e.g.
	party. If this is not possible e.g. due to the Answerer not knowing		due to the Answerer not knowing its E.164 address, the Answerer MUST
	its E.164 address, the Answerer MUST NOT include "a=setup",		reject the circuit-switched media by setting the port number to zero
	"a=connection" or "a=cs-correlation" attributes in the Answer.		on the Answer. If the Answerer is aware of its E.164 number, it MUST
			include the "a=setup" attribute in the Answer and set it to value
			"passive" or "holdconn".
	When generating the answer, the Answerer SHOULD select those		If the SDP in the Offer indicates that the Offerer is only able to
	correlation mechanisms from the Offer it supports, and include an		become the passive party, the Answerer MUST verify that the Offerer's
	"a=cs-correlation" attribute line in the answer containing those		E.164 number is included in the "c=" line of the Offer. If the
	mechanisms it supports. The Answerer MUST NOT add any mechanisms		number is included, the Answerer MUST include the "a=setup" attribute
	which were not included in the offer.		in the Answer and set it to value "active" or "holdconn". If the
			number is not included, call establishment is not possible, and the
			Answerer MUST reject the circuit-switched media by setting the port
			number to zero in the Answer.
	If the Answerer becomes the active party, it MUST NOT add parameter		If the SDP in the Offer indicates that the Offerer is able to become
			either the active or passive party, the Answerer needs to determine
			which role it would like to take. If the Offer includes an E.164
			address in the "c=" line, the Answerer SHOULD become the active
			party. If the Offer does not include an E.164 number, and if the
			Answerer is aware of its E.164 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 aware of its E.164 number, it MUST
			reject the circuit-switched media by setting the port number to zero
			in the Answer.
			The Answerer MUST select those correlation mechanisms from the Offer
			it supports, and include an "a=cs-correlation" attribute line in the
			Answer containing those mechanisms it supports. The Answerer MUST
			NOT add any mechanisms which were not included in the offer.
			If the Answerer becomes the active party, it MUST add parameter
	values to the "callerid", "uuie" or "dtmf" sub-fields.		values to the "callerid", "uuie" or "dtmf" sub-fields.
	If the Answerer becomes the passive party, it MUST add values to the		If the Answerer becomes the passive party, it MUST NOT add values to
	"callerid", "uuie" and/or "dtmf" sub-fields.		the "callerid", "uuie" and/or "dtmf" sub-fields.
	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 SHOULD extract the E.164 address from the "c=" line of the Offer		o MUST extract the E.164 address from the "c=" line of the Offer and
	and SHOULD establish a circuit-switched call to that address.		MUST establish a circuit-switched bearer to that address.
	o if the SDP Offer contained a value for the "uuie" sub-field,		o if the SDP Answer contained a value for the "callerid" sub-field,
	SHOULD send the User-User Information element according to the		must set the Calling Party Number Information Element to that
	rules defined for the circuit-switched technology used, and set		number,
	the value of the Information Element to that received in the SDP
			o if the SDP Answer contained a value for the "uuie" sub-field, MUST
			send the User-User Information element according to the rules
			defined for the circuit-switched technology used, and set the
			value of the Information Element to that received in the SDP
	Offer,		Offer,
	o if the SDP Offer contained a value for the "dtmf" sub-field,		o if the SDP Answer contained a value for the "dtmf" sub-field, MUST
	SHOULD send those DTMF digits according to the circuit-switched		send those DTMF digits according to the circuit-switched
	technology used		technology used.
	If, on the other hand, the Answerer became the passive party, it		If, on the other hand, the Answerer became the passive party, it
	MUST be prepared to receive a circuit-switched call,		o MUST be prepared to receive a circuit-switched bearer,
	MUST be prepared to receive and collect DTMF digits once the		o if the Offer contained a value for the "callerid" sub-field, MUST
	circuit-switched bearer is set up. The Answerer SHOULD compare		compare that value to the Calling Party Number Information Element
	the received DTMF digits to the value of the "dtmf" sub-field. If		of the circuit-switched bearer,
	the received DTMF digits match the value of the "dtmf" sub-field
	in the "cs-correlation" attribute, the call SHOULD be treated as
	correlated to the ongoing session.
	MUST be prepared to receive a User-User Information element once		o if the Offer contained a value for the "dtmf" sub-field, MUST be
	the circuit-switched bearer is set up. The Answerer SHOULD		prepared to receive and collect DTMF digits once the circuit-
	compare the received UUI to the value of the "uuie" sub-field. If		switched bearer is set up. The Answerer MUST compare the received
	the value of the received UUI matches the value of the "uuie" sub-		DTMF digits to the value of the "dtmf" sub-field. If the received
	field, the call SHOULD be treated as correlated to the ongoing		DTMF digits match the value of the "dtmf" sub-field in the "cs-
	session.		correlation" attribute, the call SHOULD be treated as correlated
			to the ongoing session.
	5.3.4. Considerations on successful correlation		o if the Offer contained a value for the "uuie" sub-field, MUST be
			prepared to receive a User-User Information element once the
			circuit-switched bearer is set up. The Answerer MUST compare the
			received UUI to the value of the "uuie" sub-field. If the value
			of the received UUI matches the value of the "uuie" sub-field, the
			call SHOULD be treated as correlated to the ongoing session.
	Note that, as stated above, it cannot be guaranteed that any given		5.5.3. Offerer processing the Answer
	correlation mechanism will succeed even if the usage of those was
	agreed beforehand. This is due to the fact that the correlation
	mechanisms require support from the circuit-switched bearer
	technology used.
	Therefore, even a single positive indication using any of these		When receiving the Answer, if the SDP does not contain "a=cs-
	mechanisms SHOULD be interpreted by the passive endpoint so that the		correlation" attribute line, the Offerer should take that as an
	circuit-switched bearer establishment is related to the ongoing		indication that the other party does not support or is not willing to
	session, even if the other correlation mechanisms fail.		use the procedures defined in the document for this session, and MUST
			revert to normal processing of SDP.
	If, after negotiating one or more correlation mechanisms in the SDP		When receiving the Answer, the Offerer MUST first determine whether
	offer/answer exchange, an endpoint receives a circuit-switched call		it becomes the active or passive party, as described in Section
	with no correlation information present, the endpoint has two		Section 5.3.1.
	choices: it can either treat the call as unrelated, or treat the call
	as related to the ongoing session in the IP domain.
	An endpoint may for example specify a time window after SDP offer/		If the Offerer becomes the active party, it
	answer exchange during which received calls are treated as correlated
	even if the signaling in the circuit-switched domain does not carry
	any correlation information. In this case, there is a chance that
	the call is erroneously treated as related to the ongoing session.
	An endpoint may also choose to always treat an incoming call as		o MUST extract the E.164 address from the "c=" line and MUST
	unrelated if the signaling in the circuit-switched domain does not		establish a circuit-switched bearer to that address.
	carry any correlation information. In this case, there is a chance
	that the call is erroneously treated as unrelated.
	Since, in these cases, no correlation information can be deduced from		o if the SDP Answer contained a value for the "uuie" sub-field, MUST
	the signaling, it is up to the implementation to decide how to		send the User-User Information element according to the rules
	behave. One option is also to let the user decide whether to accept		defined for the circuit-switched technology used, and set the
	the call as related, or to treat the call as unrelated.		value of the Information Element to that received in the SDP
			Answer,
	5.4. Considerations for Usage of Existing SDP		o if the SDP Answer contained a value for the "dtmf" sub-field, MUST
			send those DTMF digits according to the circuit-switched
			technology used.
	5.4.1. Originator of the Session		If the Offerer becomes the passive party, it
	According to SDP [RFC4566], the origin line in SDP has the following		o MUST be prepared to receive a circuit-switched bearer,
	syntax:
	o=<username> <sess-id> <sess-version> <nettype> <addrtype>		o if the Answer contained a value for the "dtmf" sub-field, MUST be
	<unicast-address>		prepared to receive and collect DTMF digits once the circuit-
			switched bearer is set up. The Offerer SHOULD compare the
			received DTMF digits to the value of the "dtmf" sub-field. If the
			received DTMF digits match the value of the "dtmf" sub-field in
			the "cs-correlation" attribute, the call SHOULD be treated as
			correlated to the ongoing session.
	Of interest here are the <nettype> and <addrtype> fields, which		o if the Answer contained a value for the "uuie" sub-field, MUST be
	indicate the type of network and type of address, respectively.		prepared to receive a User-User Information element once the
	Typically, this field carries the IP address of the originator of the		circuit-switched bearer is set up. The Offerer SHOULD compare the
	session. Even if the SDP was used to negotiate an audio or video		received UUI to the value of the "uuie" sub-field. If the value
	media stream transported over a circuit-switched bearer, the		of the received UUI matches the value of the "uuie" sub-field, the
	originator is using SDP over an IP bearer. Therefore, <nettype> and		call SHOULD be treated as correlated to the ongoing session.
	<addrtype> fields in the "o=" line should be populated with the IP
	address identifying the source of the signaling.
	5.4.2. Contact information		5.5.4. Modifying the session
	SDP [RFC4566] defines the "p=" line which may include the phone		If, at a later time, one of the parties wishes to modify the session,
	number of the person reponsible for the conference. Even though this		e.g., by adding new media stream, or by changing properties used on
	line can carry a phone number, it is not suited for the purpose of		an existing stream, it may do so via the mechanisms defined for An
	defining a connection address for the media. Therefore, we have		Offer/Answer Model with SDP [RFC3264].
	selected to define the PSTN specific connection addresses in the "c="
	line.
	5.5. Formal Syntax		If either party removes the circuit-switched media from the session
			(by setting the port number to zero), it MUST terminate the circuit-
			switched bearer using whatever mechanism is appropriate for the
			technology in question.
			5.6. Formal Syntax
	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.
	skipping to change at page 21, line 38		skipping to change at page 24, line 38
	;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
	6. Example		6. Example
	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. The SDP offer is show in		stream over a circuit-switched bearer. Alice generates a SDP Offer
	Figure 4. The endpoint describes a PSTN circuit-switched bearer in		which is show in Figure 4. The Offer describes a PSTN circuit-
	the "m=" and "c=" line where it also indicates its E.164 number.		switched bearer in the "m=" and "c=" line where it also indicates its
	Additionally, it expresses that it can initiate the circuit-switched		E.164 number in the international format. Additionally, Alice
	connection or be the recipient of it. The SDP offer also includes a		expresses that she can initiate the circuit-switched bearer or be the
	correlation identifier that this endpoint will be inserting the User-		recipient of it in the "a=setup" attribute line. The SDP Offer also
	User Information Element of the PSTN call setup if eventually this		includes a correlation identifiers that this endpoint will be
	endpoint initiates the PSTN call.		inserting the Calling Party Number and/or User-User Information
			Element of 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=jdoe 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 +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:callerid:+15551234 uuie:2890W284hAT452612908awudfjang908
	Figure 4: SDP offer (1)		Figure 4: SDP offer (1)
	7. IANA Considerations		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.
			The "c=" line contains Bob's E.164 number in international format.
			In the "a=setup" line Bob indicates that he is willing to become the
			active endpoint when establishing the PSTN call, and he also includes
			the "a=cs-correlation" attribute line containing the values he is
			going to include in the Calling Party Number and User-User IE of the
			PSTN call establishment.
			v=0
			o=- 2890973824 2890987289 IN IP4 192.0.2.7
			s=
			t=0 0
			m=audio 9 PSTN -
			c=PSTN E164 +15554321
			a=setup:active
			a=connection:new
			a=cs-correlation:callerid:+15554321 uuie:2127W49uThi455916adjfhtow9619361
			Figure 5: SDP Answer with circuit-switched media
			When Alice receives the Answer, she examines that Bob is willing to
			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
			the "cs-correlation" attribute, and waits for a circuit-switched
			bearer establishment.
			Bob initiates a circuit-switched bearer using whatever circuit-
			switched technology is available for him. The called party number is
			set to Alice's number, and calling party number is set to Bob's own
			number. Bob also sets the User-User Information Element value to the
			on contained in the SDP Answer.
			When Alice receives the circuit-switched bearer establishment, she
			examines the UUIE and the calling party number, and by comparing
			those received during O/A exchange determines that the call is
			related to the SDP session.
			It may also be that neither the UUIE nor the calling party number is
			received by the called party, or the format of the calling party
			number is changed by the PSTN. Implementations may still accept such
			call establishment attempts as being related to the session that was
			established in the IP network. As it cannot be guaranteed that the
			values used for correlation are always passed intact through the
			network, they should be treated as additional hints that the circuit-
			switched bearer is actually related to the session.
			7. Security Considerations
			This document provides an extension on top of RFC 4566 [RFC4566], and
			RFC 3264 [RFC3264]. As such, the security considerations of those
			documents apply.
			This memo provides mechanisms to agree on a correlation identifier or
			identifiers that are used to evaluate whether an incoming circuit-
			switched bearer is related to an ongoing session in the IP domain.
			If an attacker replicates the correlation identifer and establishes a
			call within the time window the receiving endpoint is expecting a
			call, the attacker may be able to hijack the circuit-switched bearer.
			These types of attacks are not specific to the mechanisms presented
			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
			revealing sensitive information as they would on any other phone
			call. Furthermore, users are advised that mechanisms that may be in
			use in the IP domain for securing the media, like Secure RTP (SRTP)
			[RFC3711], are not available in the CS domain.
			8. 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		8.1. Registration of new cs-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
	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
	This attribute is subject to the charset attribute		This attribute is subject to the charset attribute
	Description: This attribute provides the Correlation Identifier		Description: This attribute provides the Correlation Identifier
	used in PSTN signaling		used in PSTN signaling
	Specification: RFC XXXX		Specification: RFC XXXX
	7.2. Registration of a new "nettype" value		The IANA is requested the create a subregistry for 'cs-correlation'
			attribute under the Session Description Protocol (SDP) Parameters
			registry. The initial values for the subregistry are presented in
			the following, and IANA is requested to add them into its database:
			Value of 'cs-correlation' attribute Reference Description
			----------------------------------- --------- ----------- callerid
			RFC XXXX Caller ID uuie RFC XXXX User-User Information Element dtmf
			RFC XXXX Dual-tone Multifrequency
			Note for the RFC Editor: 'RFC XXXX' above should be replaced by a
			reference to the RFC number of this draft.
			As per the terminology in [RFC2434], the registration policy for new
			values of 'cs-correlation' parameter is 'Specification Required'.
			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]
	7.3. Registration of new "addrtype" values		8.3. Registration of new "addrtype" values
	This memo provides instructions to IANA to register a new "addrtype"		This memo provides instructions to IANA to register a new "addrtype"
	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
	---- ------------------ ---------		---- ------------------ ---------
	addrtype E164 [RFCxxxx]		addrtype E164 [RFCxxxx]
	- [RFCxxxx]		- [RFCxxxx]
	7.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 [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
	-------------- --------------------------- ---------		-------------- --------------------------- ---------
	proto PSTN [RFCxxxx]		proto PSTN [RFCxxxx]
	8. Security Considerations
	This document provides an extension on top of RFC 4566 [RFC4566], and
	RFC 3264 [RFC3264]. As such, the security considerations of those
	documents apply.
	This memo provides mechanisms to agree on a correlation identifier or
	identifiers that are used to evaluate whether an incoming circuit-
	switched call is related to an ongoing session in the IP domain. If
	an attacker replicates the correlation identifer and establishes a
	call within the time window the receiving endpoint is expecting a
	call, the attacker may be able to hijack the circuit-switched call.
	These types of attacks are not specific to the mechanisms presented
	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
	revealing sensitive information as they would on any other phone
	call. Furthermore, users are advised that mechanisms that may be in
	use in the IP domain for securing the media, like Secure RTP (SRTP)
	[RFC3711], are not available in the CS domain.
	9. Acknowledgments		9. Acknowledgments
	The authors want to thank Flemming Andreasen, Thomas Belling, John		The authors want to thank Flemming Andreasen, Thomas Belling, John
	Elwell, Jari Mutikainen, Miikka Poikselka, Jonathan Rosenberg,		Elwell, Jari Mutikainen, Miikka Poikselka, Jonathan Rosenberg,
	Ingemar Johansson, Christer Holmberg, and Alf Heidermark for		Ingemar Johansson, Christer Holmberg, and Alf Heidermark for
	providing their insight and comments on this document.		providing 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.
			[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
			IANA Considerations Section in RFCs", BCP 26, RFC 2434,
			October 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.
	[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 2002.		June 2002.
	[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.
	[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		[RFC5939] Andreasen, F., "Session Description Protocol (SDP)
			Capability Negotiation", RFC 5939, September 2010.
	[3GPP.24.008]		10.2. Informative References
	3GPP, "Mobile radio interface Layer 3 specification; Core
	network protocols; Stage 3", 3GPP TS 24.008 3.20.0,
	December 2005.
	[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.
	skipping to change at page 25, line 31		skipping to change at page 29, line 50
	Video Conferences with Minimal Control", STD 65, RFC 3551,		Video Conferences with Minimal Control", STD 65, RFC 3551,
	July 2003.		July 2003.
	[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.		[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
	Norrman, "The Secure Real-time Transport Protocol (SRTP)",		Norrman, "The Secure Real-time Transport Protocol (SRTP)",
	RFC 3711, March 2004.		RFC 3711, March 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]
			3GPP, "Mobile radio interface Layer 3 specification; Core
			network protocols; Stage 3", 3GPP TS 24.008 3.20.0,
			December 2005.
	URIs		URIs
	[1] <http://www.iana.org/assignments/sdp-parameters>		[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
End of changes. 80 change blocks.
	269 lines changed or deleted		491 lines changed or added
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/