draft-ietf-mmusic-sdp-cs-08.txt   draft-ietf-mmusic-sdp-cs-09.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: April 15, 2012 Nokia Expires: May 3, 2012 Nokia
October 13, 2011 October 31, 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 Switched Video Media Streams Over Circuit-Switched Bearers In The Public Switched
Telephone Network (PSTN) Telephone Network (PSTN)
draft-ietf-mmusic-sdp-cs-08 draft-ietf-mmusic-sdp-cs-09
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 April 15, 2012. This Internet-Draft will expire on May 3, 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 20 skipping to change at page 3, line 20
4. Overview of Operation . . . . . . . . . . . . . . . . . . . . 6 4. Overview of Operation . . . . . . . . . . . . . . . . . . . . 6
4.1. Example Call Flow . . . . . . . . . . . . . . . . . . . . 6 4.1. Example Call Flow . . . . . . . . . . . . . . . . . . . . 6
5. Protocol Description . . . . . . . . . . . . . . . . . . . . . 8 5. Protocol Description . . . . . . . . . . . . . . . . . . . . . 8
5.1. Level of Compliance . . . . . . . . . . . . . . . . . . . 8 5.1. Level of Compliance . . . . . . . . . . . . . . . . . . . 8
5.2. Extensions to SDP . . . . . . . . . . . . . . . . . . . . 8 5.2. Extensions to SDP . . . . . . . . . . . . . . . . . . . . 8
5.2.1. Connection Data . . . . . . . . . . . . . . . . . . . 8 5.2.1. Connection Data . . . . . . . . . . . . . . . . . . . 8
5.2.2. Media Descriptions . . . . . . . . . . . . . . . . . . 9 5.2.2. Media Descriptions . . . . . . . . . . . . . . . . . . 9
5.2.3. Correlating the PSTN Circuit-Switched Bearer with 5.2.3. Correlating the PSTN Circuit-Switched Bearer with
SDP . . . . . . . . . . . . . . . . . . . . . . . . . 10 SDP . . . . . . . . . . . . . . . . . . . . . . . . . 10
5.2.3.1. The "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 . . . . . . . . . 12
5.2.3.3. User-User Information Element Correlation 5.2.3.3. User-User Information Element Correlation
Mechanism . . . . . . . . . . . . . . . . . . . . 12 Mechanism . . . . . . . . . . . . . . . . . . . . 13
5.2.3.4. DTMF Correlation Mechanism . . . . . . . . . . . . 13 5.2.3.4. DTMF Correlation Mechanism . . . . . . . . . . . . 14
5.3. Negotiating the correlation mechanisms . . . . . . . . . . 14 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 . . . . . . . . . . . . . . . . . . . . . 14 Bearer Setup . . . . . . . . . . . . . . . . . . . . . 15
5.3.2. Populating the cs-correlation attribute . . . . . . . 15 5.3.2. Populating the cs-correlation attribute . . . . . . . 16
5.3.3. Considerations on successful correlation . . . . . . . 16 5.3.3. Considerations on successful correlation . . . . . . . 16
5.4. Considerations for Usage of Existing SDP . . . . . . . . . 16 5.4. Considerations for Usage of Existing SDP . . . . . . . . . 17
5.4.1. Originator of the Session . . . . . . . . . . . . . . 16 5.4.1. Originator of the Session . . . . . . . . . . . . . . 17
5.4.2. Contact information . . . . . . . . . . . . . . . . . 17 5.4.2. Contact information . . . . . . . . . . . . . . . . . 17
5.5. Offer/Answer mode extensions . . . . . . . . . . . . . . . 17 5.5. Offer/Answer mode extensions . . . . . . . . . . . . . . . 18
5.5.1. Generating the Initial Offer . . . . . . . . . . . . . 17 5.5.1. Generating the Initial Offer . . . . . . . . . . . . . 18
5.5.2. Generating the Answer . . . . . . . . . . . . . . . . 19 5.5.2. Generating the Answer . . . . . . . . . . . . . . . . 20
5.5.3. Offerer processing the Answer . . . . . . . . . . . . 22 5.5.3. Offerer processing the Answer . . . . . . . . . . . . 22
5.5.4. Modifying the session . . . . . . . . . . . . . . . . 23 5.5.4. Modifying the session . . . . . . . . . . . . . . . . 23
5.6. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . 23 5.6. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . 24
6. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 6. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
7. Security Considerations . . . . . . . . . . . . . . . . . . . 26 7. Security Considerations . . . . . . . . . . . . . . . . . . . 26
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
8.1. Registration of new cs-correlation SDP attribute . . . . . 27 8.1. Registration of new cs-correlation SDP attribute . . . . . 27
8.2. Registration of a new "nettype" value . . . . . . . . . . 27 8.2. Registration of a new "nettype" value . . . . . . . . . . 28
8.3. Registration of new "addrtype" values . . . . . . . . . . 28 8.3. Registration of new "addrtype" values . . . . . . . . . . 28
8.4. Registration of a new "proto" value . . . . . . . . . . . 28 8.4. Registration of a new "proto" value . . . . . . . . . . . 28
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
10.1. Normative References . . . . . . . . . . . . . . . . . . . 28 10.1. Normative References . . . . . . . . . . . . . . . . . . . 29
10.2. Informative References . . . . . . . . . . . . . . . . . . 29 10.2. Informative References . . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30 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
skipping to change at page 8, line 41 skipping to change at page 8, line 41
Internet network type. The address types "IP4" and "IP6" indicate Internet network type. The address types "IP4" and "IP6" indicate
the type of IP addresses. the type of IP addresses.
This memo defines a new network type for describing a circuit- This memo defines a new network type for describing a circuit-
switched bearer network type in the PSTN. The mnemonic "PSTN" is switched bearer network type in the PSTN. The mnemonic "PSTN" is
used for this network type. used for this network type.
For the address type, we initially consider the possibility of For the address type, we initially consider the possibility of
describing E.164 telephone numbers. We define a new "E164" address describing E.164 telephone numbers. We define a new "E164" address
type. When used, the "E164" address type indicates that the type. When used, the "E164" address type indicates that the
connection address contains a telephone number represented according connection address contains an international E.164 number represented
to the ITU-T E.164 [ITU.E164.1991] recommendation. according to the ITU-T E.164 [ITU.E164.1991] recommendation.
It is a common convention that an international E.164 number contains
a leading '+' sign. For consistency's sake, we also require the
E.164 telephone is prepended with a '+', even if that is not
necessary for routing of the call in the PSTN network.
There are cases, though, when the endpoint is merely aware of a There are cases, though, when the endpoint is merely aware of a
circuit-switched bearer, without having further information about the circuit-switched bearer, without having further information about the
address type or the E.164 number allocated to it. In these cases a address type or the E.164 number allocated to it. In these cases a
dash "-" is used to indicate an unknown address type or connection dash "-" is used to indicate an unknown address type or connection
address. This makes the connection data line be according to the SDP address. This makes the connection data line be according to the SDP
syntax. syntax.
Note that <addrtype> and/or <connection-address> should not be Note that <addrtype> and/or <connection-address> should not be
omitted without being set to a "-" since this would violate basic omitted without being set to a "-" since this would violate basic
syntax of SDP [RFC4566]. syntax of SDP [RFC4566].
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 +15551234 c=PSTN E164 +35891234567
c=PSTN - - c=PSTN - -
When the <addrtype> is PSTN, the connection address is defined as
follows:
o an international E.164 number
When the <addrtype> is "-", the connection address is defined as
follows:
o the value "-", signifying that the address is unknown
o any syntactically valid value, which is to be ignored
5.2.2. Media Descriptions 5.2.2. Media Descriptions
According to SDP [RFC4566], the media descriptions line in SDP has According to SDP [RFC4566], the media descriptions line in SDP has
the following syntax: the following syntax:
m=<media> <port> <proto> <fmt> ... m=<media> <port> <proto> <fmt> ...
The <media> sub-field carries the media type. For establishing an The <media> sub-field 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.
skipping to change at page 11, line 28 skipping to change at page 11, line 42
a new SDP attribute called "cs-correlation". This "cs-correlation" a new SDP attribute called "cs-correlation". This "cs-correlation"
attribute can include any of the "callerid", "uuie", or "dtmf" sub- attribute can include any of the "callerid", "uuie", or "dtmf" sub-
fields, which specify additional information required by the fields, which specify additional information required by the
Caller-ID, User to User Information, or DTMF correlation mechanisms, Caller-ID, User to User Information, or DTMF correlation mechanisms,
respectively. 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: <correlation-mechanisms>
uuie:<uuie-value> | correlation-mechanisms = corr-mech *(SP corr-mech)
dtmf:<dtmf-value> | corr-mech = caller-id-mech / uuie-mech /
*[extension-name:<extension-value>] dfmt-mech / ext-mech
caller-id-mech = "callerid" [":" caller-id-value]
uuie-mech = "uuie" [":" uuie-value]
dtmf-mech = "dtmf" [":" dtmf-value]
ext-mech = <ext-mech-name>[":"<ext-mech-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.6. 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 as an international E.164 number in SDP,
availability of the Calling Party Number information element in the followed by the availability of the Calling Party Number information
call setup signaling of the circuit switched connection. If both element in the call setup signaling of the circuit switched
pieces of information match, the circuit-switched bearer is connection. If both pieces of information match, the circuit-
correlated to the session described in SDP. switched bearer is correlated to the session described in SDP.
Example of inclusion of E.164 number in the "cs-correlation" Example of inclusion of an international E.164 number in the "cs-
attribute is: correlation" attribute is:
a=cs-correlation:callerid:+15551234 a=cs-correlation:callerid:+35891234567
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 international E.164 number of the
the parameter. party inserting the parameter.
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:
o The endpoint might not be aware of its own E.164 number, in which o The endpoint might not be aware of its own E.164 number, in which
case it cannot populate the SDP appropriately. case it cannot populate the SDP appropriately.
o 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 to restrictions of the network operator or caller restriction due to
privacy. privacy.
o 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. To mitigate this problem implementations
international format and the other might only contain the should consider only some of the rightmost digits from the E.164
significant national digits. To mitigate this problem number for correlation. For example, the numbers +358-9-123-4567
implementations should consider only some of the rightmost digits and 09-123-4567 could be considered as the same number. This is
from the E.164 number for correlation. For example, the numbers also the behavior of some cellular phones, which correlate the
+358-1-555-12345 and 01-555-12345 could be considered as the same incoming calling party with a number stored in the phone book, for
number. This is also the behavior of some cellular phones, which the purpose of displaying the caller's name.
correlate the incoming calling party with a number stored in the
phone book, for the purpose of displaying 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 [TS.24.008], among others. The User-User Information 3GPP TS 24.008 [TS.24.008], among others. The User-User Information
Element has a maximum size of 35 or 131 octets, depending on the Element has a maximum size of 35 or 131 octets, depending on the
actual message of the PSTN protocol where it is included. actual message of the PSTN protocol where it is included.
skipping to change at page 13, line 11 skipping to change at page 13, line 28
SDP answer, in a "cs-correlation:uuie" attribute. When the SDP SDP answer, in a "cs-correlation:uuie" attribute. When the SDP
Offer/Answer exchange is completed, each endpoint has become aware of Offer/Answer exchange is completed, each endpoint has become aware of
the value that will be used in the User-User Information Element of the value that will be used in the User-User Information Element of
the call setup message of the PSTN protocol. The endpoint that the call setup message of the PSTN protocol. The endpoint that
initiates the call setup attempt includes this value in the User-User initiates the call setup attempt includes this value in the User-User
Information Element. The recipient of the call setup attempt can Information Element. The recipient of the call setup attempt can
extract the User-User Information Element and correlate it with the extract the User-User Information Element and correlate it with the
value previously received in the SDP. If both values match, then the value previously received in the SDP. If both values match, then the
call setup attempt corresponds to that indicated in the SDP. call setup attempt corresponds to that indicated in the SDP.
The first three octets of the User-User Information Element specified
in ITU-T Q.931 [ITU.Q931.1998] are the UUIE identifier, lenght of the
user-user contents, and a protocol discriminator, followed by the
actual User information. The first three octets of the UUIE MUST NOT
be used for correlation, only the octets carrying the User
information value are compared the value of the "cs-correlation:uuie"
attribute.
OPEN ISSUE: Need to confirm whether this is acceptable.
Note that, for correlation purposes, the value of the User-User Note that, for correlation purposes, the value of the User-User
Information Element is considered as a opaque string and only used Information Element is considered as a opaque string and only used
for correlation purposes. Typically call signaling protocols impose for correlation purposes. Typically call signaling protocols impose
requirements on the creation of User-User Information Element for requirements on the creation of User-User Information Element for
end-user protocol exchange. The details regarding the generation of end-user protocol exchange. The details regarding the generation of
the User-User Information Element are outside the scope of this the User-User Information Element are outside the scope of this
specification. specification.
Please note that there are no warranties that this correlation Please note that there are no warranties that this correlation
mechanism works. On one side, policy restrictions might not make the mechanism works. On one side, policy restrictions might not make the
skipping to change at page 17, line 40 skipping to change at page 18, line 19
the SDP Capability Negotiation [RFC5939] to allow for PSTN addresses the SDP Capability Negotiation [RFC5939] to allow for PSTN addresses
to be used with the Offer/Answer model. to be used with the Offer/Answer model.
5.5.1. Generating the Initial Offer 5.5.1. Generating the Initial Offer
The Offerer, wishing to use PSTN audio or video stream, MUST populate The Offerer, wishing to use PSTN audio or video stream, MUST populate
the "c=" and "m=" lines as follows. the "c=" and "m=" lines as follows.
The endpoint MUST set the <nettype> in the "c=" line to "PSTN", and The endpoint MUST set the <nettype> in the "c=" line to "PSTN", and
the <addrtype> to "E164". Furthermore, the endpoint SHOULD set the the <addrtype> to "E164". Furthermore, the endpoint SHOULD set the
<connection-address> field to its own E.164 number in the <connection-address> field to its own international E.164 number
international format (beginning with a "+"). If the endpoint is not (with a leading "+"). If the endpoint is not aware of its own E.164
aware of its own E.164 number, it MUST set the <connection-address> number, it MUST set the <connection-address> to "-".
to "-".
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, the <port> to "9" "audio" or "video", depending on the media type, the <port> to "9"
(the discard port), and the <proto> sub-field to "PSTN". (the discard port), and the <proto> sub-field to "PSTN".
The <fmt> sub-field carries the payload type number(s) the endpoint 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 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 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 wishes to use the GSM codec, it would add payload type number 3 in
the list of codecs. the list of codecs.
skipping to change at page 18, line 25 skipping to change at page 19, line 5
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 supports any of the correlation mechanisms defined in If the Offerer supports any of the correlation mechanisms defined in
this memo, and is willing to become the active party, the Offerer this memo, and is willing to become the active party, the Offerer
MUST add the "callerid", "uuie", and/or "dtmf" sub-fields and MUST MUST add the "callerid", "uuie", and/or "dtmf" sub-fields and MUST
specify values for those sub-fields. specify values for those sub-fields.
o the E.164 number as the value in the "callerid" sub-field, o the international 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/or 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 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 the "callerid", "uuie"
and/or "dtmf" sub-fields, but MUST NOT specify values for those sub- and/or "dtmf" sub-fields, but MUST NOT specify values for those sub-
fields. fields.
skipping to change at page 19, line 22 skipping to change at page 19, line 48
The Offerer states which role or roles it is willing to perform; and The Offerer states which role or roles it is willing to perform; and
the Answerer, taking the Offerer's willingness into consideration, the Answerer, taking the Offerer's willingness into consideration,
chooses which roles both endpoints will actually perform during the chooses which roles both endpoints will actually perform during the
circuit-switched bearer setup. circuit-switched bearer setup.
By 'active' endpoint, we refer to an endpoint that will establish the By 'active' endpoint, we refer to an endpoint that will establish the
circuit-switched bearer; and by 'passive' endpoint, we refer to an circuit-switched bearer; and by 'passive' endpoint, we refer to an
endpoint that will receive a circuit-switched bearer. endpoint that will receive a circuit-switched bearer.
If an Offerer does not know its E.164 address, it MUST set the If an Offerer does not know its international E.164 number, it MUST
'a=setup' attribute to the value 'active'. If the Offerer knows its set the 'a=setup' attribute to the value 'active'. If the Offerer
E.164 address, it MUST set the value to either 'actpass' or knows its international E.164 number, it MUST set the value to either
'passive'. 'actpass' or 'passive'.
Also 'holdconn' is a permissible value in the 'a=setup' attribute. Also 'holdconn' is a permissible value in the 'a=setup' attribute.
It indicates that the connection is not established for the time It indicates that the connection is not established for the time
being. being.
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. If there is no circuit-switched bearer is to be established or not. For the initial
circuit-switched bearer established between the endpoints, the Offer, the Offerer MUST use value 'new'.
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".
5.5.2. Generating the Answer 5.5.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 Section
6 of An Offer/Answer Model with the Session Description Protocol 6 of An Offer/Answer Model with the Session Description Protocol
(SDP) [RFC3264]. (SDP) [RFC3264].
skipping to change at page 20, line 22 skipping to change at page 20, line 44
switched media, it MAY set the respective payload numbers in the switched media, it MAY set the respective payload numbers in the
<fmt> sub-field in the answer. This behavior, however, is NOT <fmt> sub-field in the answer. This behavior, however, is NOT
RECOMMENDED. RECOMMENDED.
When receiving the Offer, the Answerer MUST determine whether it When receiving the Offer, the Answerer MUST determine whether it
becomes the active or passive party. becomes the active or passive party.
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, the Answerer needs to determine whether it become the active party, the Answerer needs to determine whether it
is able to become the passive party. If this is not possible e.g. is able to become the passive party. If this is not possible e.g.
due to the Answerer not knowing its E.164 address, the Answerer MUST due to the Answerer not knowing its international E.164 number, the
reject the circuit-switched media by setting the port number to zero Answerer MUST reject the circuit-switched media by setting the port
on the Answer. If the Answerer is aware of its E.164 number, it MUST number to zero on the Answer. If the Answerer is aware of its
include the "a=setup" attribute in the Answer and set it to value international E.164 number, it MUST include the "a=setup" attribute
"passive" or "holdconn". in the Answer and set it to value "passive" or "holdconn".
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 passive party, the Answerer MUST verify that the Offerer's become the passive party, the Answerer MUST verify that the Offerer's
E.164 number is included in the "c=" line of the Offer. If the E.164 number is included in the "c=" line of the Offer. If the
number is included, the Answerer MUST include the "a=setup" attribute number is included, the Answerer MUST include the "a=setup" attribute
in the Answer and set it to value "active" or "holdconn". If the in the Answer and set it to value "active" or "holdconn". If the
number is not included, call establishment is not possible, and the number is not included, call establishment is not possible, and the
Answerer MUST reject the circuit-switched media by setting the port Answerer MUST reject the circuit-switched media by setting the port
number to zero in the Answer. number to zero in the Answer.
If the SDP in the Offer indicates that the Offerer is able to become 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 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 which role it would like to take. If the Offer includes an
address in the "c=" line, the Answerer SHOULD become the active international E.164 number in the "c=" line, the Answerer SHOULD
party. If the Offer does not include an E.164 number, and if the become the active party. If the Offer does not include an E.164
Answerer is aware of its E.164 number, it MUST become the passive number, and if the Answerer is aware of its international E.164
party. If the Offer does not include an E.164 number in the "c=" number, it MUST become the passive party. If the Offer does not
line and the Answerer is not aware of its E.164 number, it MUST include an E.164 number in the "c=" line and the Answerer is not
reject the circuit-switched media by setting the port number to zero aware of its E.164 number, it MUST reject the circuit-switched media
in the Answer. by setting the port number to zero in the Answer.
The Answerer MUST select those correlation mechanisms from the Offer The Answerer MUST select those correlation mechanisms from the Offer
it supports, and include an "a=cs-correlation" attribute line in the it supports, and include an "a=cs-correlation" attribute line in the
Answer containing those mechanisms it supports. The Answerer MUST Answer containing those mechanisms it supports. The Answerer MUST
NOT add any mechanisms which were not included in the offer. NOT add any mechanisms which were not included in the offer.
If the Answerer becomes the active party, it MUST add parameter 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 NOT add values to If the Answerer becomes the passive party, it MUST NOT add values to
the "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 MUST extract the E.164 address 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" sub-field, o if the SDP Answer contained a value for the "callerid" sub-field,
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" sub-field, MUST o if the SDP Answer contained a value for the "uuie" sub-field, 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
value of the Information Element to that received in the SDP value of the Information Element to that received in the SDP
skipping to change at page 22, line 19 skipping to change at page 22, line 42
indication that the other party does not support or is not willing to 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 use the procedures defined in the document for this session, and MUST
revert to normal processing of SDP. revert to normal processing of SDP.
When receiving the Answer, the Offerer MUST first determine whether When receiving the Answer, the Offerer MUST first determine whether
it becomes the active or passive party, as described in Section it becomes the active or passive party, as described in Section
Section 5.3.1. Section 5.3.1.
If the Offerer becomes the active party, it If the Offerer becomes the active party, it
o MUST extract the E.164 address from the "c=" line and MUST o MUST extract the E.164 number from the "c=" line and MUST
establish a circuit-switched bearer to that address. establish a circuit-switched bearer to that address.
o if the SDP Answer contained a value for the "uuie" sub-field, MUST o if the SDP Answer contained a value for the "uuie" sub-field, 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
value of the Information Element to that received in the SDP value of the Information Element to that received in the SDP
Answer, Answer,
o if the SDP Answer contained a value for the "dtmf" sub-field, MUST o if the SDP Answer contained a value for the "dtmf" sub-field, MUST
send those DTMF digits according to the circuit-switched send those DTMF digits according to the circuit-switched
skipping to change at page 23, line 12 skipping to change at page 23, line 32
of the received UUI matches the value of the "uuie" sub-field, the of the received UUI matches the value of the "uuie" sub-field, the
call SHOULD be treated as correlated to the ongoing session. call SHOULD be treated as correlated to the ongoing session.
5.5.4. Modifying the session 5.5.4. Modifying the session
If, at a later time, one of the parties wishes to modify the session, If, at a later time, one of the parties wishes to modify the session,
e.g., by adding new media stream, or by changing properties used on e.g., by adding new media stream, or by changing properties used on
an existing stream, it may do so via the mechanisms defined for An an existing stream, it may do so via the mechanisms defined for An
Offer/Answer Model with SDP [RFC3264]. Offer/Answer Model with SDP [RFC3264].
If there is an existing circuit-switched bearer between the
endpoints, and the Offerer wants to reuse that the Offerer MUST set
the value of the "a=connection" attribute to 'existing'.
If either party removes the circuit-switched media from the session If either party removes the circuit-switched media from the session
(by setting the port number to zero), it MUST terminate the circuit- (by setting the port number to zero), it MUST terminate the circuit-
switched bearer using whatever mechanism is appropriate for the switched bearer using whatever mechanism is appropriate for the
technology in question. technology in question.
If either party wishes to drop and reestablish an existing call, that
party MUST first remove the circuit-switched media from the session
by setting the port number to zero, and then use another Offer/Answer
exchange where it MUST set the "a=connection" attribute to 'new'".
If the media types are different (for example, a different codec will
be used for the circuit-switched bearer), the media descriptions for
terminating the existing bearer and the new bearer can be in the same
Offer.
5.6. Formal Syntax 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.
; extension to the connection field originally specified ; extension to the connection field originally specified
; in RFC 4566 ; in RFC 4566
connection-field = [%x63 "=" nettype SP addrtype SP connection-field = [%x63 "=" nettype SP addrtype SP
connection-address CRLF] connection-address CRLF]
;nettype and addrtype are defined in RFC 4566 ;nettype and addrtype are defined in RFC 4566
connection-address /= e164-address / "-" connection-address /= e164-address / "-"
e164-address = ["+"] 1*15DIGIT e164-address = "+" 1*15DIGIT
; DIGIT is specified in RFC 5234 ; DIGIT is specified in RFC 5234
;subrules for correlation attribute ;subrules for correlation attribute
attribute /= cs-correlation-attr attribute /= cs-correlation-attr
; attribute defined in RFC 4566 ; attribute defined in RFC 4566
cs-correlation-attr= "cs-correlation:" corr-mechanisms cs-correlation-attr= "cs-correlation:" corr-mechanisms
corr-mechanisms = corr-mech *(SP corr-mech) corr-mechanisms = corr-mech *(SP corr-mech)
corr-mech = caller-id-mech / uuie-mech / dtmf-mech / ext-mech corr-mech = caller-id-mech / uuie-mech / dtmf-mech / ext-mech
caller-id-mech = "callerid" [":" caller-id-value] caller-id-mech = "callerid" [":" caller-id-value]
caller-id-value = ["+"] 1*DIGIT caller-id-value = "+" 1*15DIGIT
uuie-mech = "uuie" [":" uuie-value] uuie-mech = "uuie" [":" uuie-value]
uuie-value = 1*32(ALPHA/DIGIT) uuie-value = 1*32(ALPHA/DIGIT)
dtmf-mech = "dtmf" [":" dtmf-value] dtmf-mech = "dtmf" [":" dtmf-value]
dtmf-value = 1*32(DIGIT / %x41-44 / %x23 / %x2A ) dtmf-value = 1*32(DIGIT / %x41-44 / %x23 / %x2A )
;0-9, A-D, '#' and '*' ;0-9, A-D, '#' and '*'
ext-mech = 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
skipping to change at page 25, line 4 skipping to change at page 25, line 20
|--------------------------------->| |--------------------------------->|
| | | |
| (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 show in Figure 4. The Offer describes a PSTN circuit- which is show 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
E.164 number in the international format. Additionally, Alice international E.164 number format. Additionally, Alice expresses
expresses that she can initiate the circuit-switched bearer or be the that she can initiate the circuit-switched bearer or be the recipient
recipient of it in the "a=setup" attribute line. The SDP Offer also of it in the "a=setup" attribute line. The SDP Offer also includes a
includes a correlation identifiers that this endpoint will be correlation identifiers that this endpoint will be inserting the
inserting the Calling Party Number and/or User-User Information Calling Party Number and/or User-User Information Element of the PSTN
Element of the PSTN call setup if eventually this endpoint initiates call setup if eventually this endpoint initiates the PSTN call.
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 +35891234567
a=setup:actpass a=setup:actpass
a=connection:new a=connection:new
a=cs-correlation:callerid:+15551234 uuie:2890W284hAT452612908awudfjang908 a=cs-correlation:callerid:+15551234 uuie:2890W284hAT452612908awudfjang908
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 E.164 number in international format. The "c=" line contains Bob's international E.164 number. In the
In the "a=setup" line Bob indicates that he is willing to become the "a=setup" line Bob indicates that he is willing to become the active
active endpoint when establishing the PSTN call, and he also includes endpoint when establishing the PSTN call, and he also includes the
the "a=cs-correlation" attribute line containing the values he is "a=cs-correlation" attribute line containing the values he is going
going to include in the Calling Party Number and User-User IE of the to include in the Calling Party Number and User-User IE of the PSTN
PSTN call establishment. call 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 +15554321 c=PSTN E164 +35897654321
a=setup:active a=setup:active
a=connection:new a=connection:new
a=cs-correlation:callerid:+15554321 uuie:2127W49uThi455916adjfhtow9619361 a=cs-correlation:callerid:+15554321 uuie:2127W49uThi455916adjfhtow9619361
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
skipping to change at page 28, line 28 skipping to change at page 28, line 41
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]
9. Acknowledgments 9. Acknowledgments
The authors want to thank Flemming Andreasen, Thomas Belling, John The authors want to thank Paul Kyzivat, Flemming Andreasen, Thomas
Elwell, Jari Mutikainen, Miikka Poikselka, Jonathan Rosenberg, Belling, John Elwell, Jari Mutikainen, Miikka Poikselka, Jonathan
Ingemar Johansson, Christer Holmberg, and Alf Heidermark for Rosenberg, Ingemar Johansson, Christer Holmberg, and Alf Heidermark
providing their insight and comments on this document. for 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 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434, IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998. 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
 End of changes. 40 change blocks. 
99 lines changed or deleted 135 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/