< draft-ietf-mmusic-sdp-cs-11.txt | draft-ietf-mmusic-sdp-cs-13.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: November 15, 2012 Nokia | Expires: April 24, 2013 Nokia | |||
May 14, 2012 | October 21, 2012 | |||
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-11 | draft-ietf-mmusic-sdp-cs-13 | |||
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 November 15, 2012. | This Internet-Draft will expire on April 24, 2013. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2012 IETF Trust and the persons identified as the | Copyright (c) 2012 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 19 | skipping to change at page 3, line 19 | |||
3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 6 | 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 6 | |||
4. Overview of Operation . . . . . . . . . . . . . . . . . . . . 7 | 4. Overview of Operation . . . . . . . . . . . . . . . . . . . . 7 | |||
4.1. Example Call Flow . . . . . . . . . . . . . . . . . . . . 7 | 4.1. Example Call Flow . . . . . . . . . . . . . . . . . . . . 7 | |||
5. Protocol Description . . . . . . . . . . . . . . . . . . . . . 9 | 5. Protocol Description . . . . . . . . . . . . . . . . . . . . . 9 | |||
5.1. Level of Compliance . . . . . . . . . . . . . . . . . . . 9 | 5.1. Level of Compliance . . . . . . . . . . . . . . . . . . . 9 | |||
5.2. Extensions to SDP . . . . . . . . . . . . . . . . . . . . 9 | 5.2. Extensions to SDP . . . . . . . . . . . . . . . . . . . . 9 | |||
5.2.1. Connection Data . . . . . . . . . . . . . . . . . . . 9 | 5.2.1. Connection Data . . . . . . . . . . . . . . . . . . . 9 | |||
5.2.2. Media Descriptions . . . . . . . . . . . . . . . . . . 10 | 5.2.2. Media Descriptions . . . . . . . . . . . . . . . . . . 10 | |||
5.2.3. Correlating the PSTN Circuit-Switched Bearer with | 5.2.3. Correlating the PSTN Circuit-Switched Bearer with | |||
SDP . . . . . . . . . . . . . . . . . . . . . . . . . 12 | SDP . . . . . . . . . . . . . . . . . . . . . . . . . 12 | |||
5.2.3.1. The "cs-correlation" attribute . . . . . . . . . . 12 | 5.2.3.1. The "cs-correlation" attribute . . . . . . . . . . 13 | |||
5.2.3.2. Caller-ID Correlation Mechanism . . . . . . . . . 13 | 5.2.3.2. Caller-ID Correlation Mechanism . . . . . . . . . 13 | |||
5.2.3.3. User-User Information Element Correlation | 5.2.3.3. User-User Information Element Correlation | |||
Mechanism . . . . . . . . . . . . . . . . . . . . 14 | Mechanism . . . . . . . . . . . . . . . . . . . . 14 | |||
5.2.3.4. DTMF Correlation Mechanism . . . . . . . . . . . . 16 | 5.2.3.4. DTMF Correlation Mechanism . . . . . . . . . . . . 16 | |||
5.2.3.5. Extensions to correlation mechanisms . . . . . . . 17 | ||||
5.3. Negotiating the correlation mechanisms . . . . . . . . . . 17 | 5.3. Negotiating the correlation mechanisms . . . . . . . . . . 17 | |||
5.3.1. Determining the Direction of the Circuit-Switched | 5.3.1. Determining the Direction of the Circuit-Switched | |||
Bearer Setup . . . . . . . . . . . . . . . . . . . . . 17 | Bearer Setup . . . . . . . . . . . . . . . . . . . . . 17 | |||
5.3.2. Populating the cs-correlation attribute . . . . . . . 18 | 5.3.2. Populating the cs-correlation attribute . . . . . . . 18 | |||
5.3.3. Considerations on successful correlation . . . . . . . 18 | 5.3.3. Considerations on successful correlation . . . . . . . 19 | |||
5.4. Considerations for Usage of Existing SDP . . . . . . . . . 19 | 5.4. Considerations for Usage of Existing SDP . . . . . . . . . 19 | |||
5.4.1. Originator of the Session . . . . . . . . . . . . . . 19 | 5.4.1. Originator of the Session . . . . . . . . . . . . . . 20 | |||
5.4.2. Contact information . . . . . . . . . . . . . . . . . 19 | 5.4.2. Contact information . . . . . . . . . . . . . . . . . 20 | |||
5.5. Considerations for Usage of Third Party Call Control | 5.5. Considerations for Usage of Third Party Call Control | |||
(3PCC) . . . . . . . . . . . . . . . . . . . . . . . . . . 19 | (3PCC) . . . . . . . . . . . . . . . . . . . . . . . . . . 20 | |||
5.6. Offer/Answer mode extensions . . . . . . . . . . . . . . . 20 | 5.6. Offer/Answer mode extensions . . . . . . . . . . . . . . . 21 | |||
5.6.1. Generating the Initial Offer . . . . . . . . . . . . . 20 | 5.6.1. Generating the Initial Offer . . . . . . . . . . . . . 21 | |||
5.6.2. Generating the Answer . . . . . . . . . . . . . . . . 22 | 5.6.2. Generating the Answer . . . . . . . . . . . . . . . . 23 | |||
5.6.3. Offerer processing the Answer . . . . . . . . . . . . 25 | 5.6.3. Offerer processing the Answer . . . . . . . . . . . . 25 | |||
5.6.4. Modifying the session . . . . . . . . . . . . . . . . 26 | 5.6.4. Modifying the session . . . . . . . . . . . . . . . . 27 | |||
5.7. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . 26 | 5.7. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . 27 | |||
6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 | 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 | |||
6.1. Single PSTN audio stream . . . . . . . . . . . . . . . . . 28 | 6.1. Single PSTN audio stream . . . . . . . . . . . . . . . . . 29 | |||
6.2. Advanced SDP example: Circuit-Switched Audio and Video | 6.2. Advanced SDP example: Circuit-Switched Audio and Video | |||
Streams . . . . . . . . . . . . . . . . . . . . . . . . . 30 | Streams . . . . . . . . . . . . . . . . . . . . . . . . . 31 | |||
7. Security Considerations . . . . . . . . . . . . . . . . . . . 31 | 7. Security Considerations . . . . . . . . . . . . . . . . . . . 32 | |||
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 | 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 | |||
8.1. Registration of new cs-correlation SDP attribute . . . . . 32 | 8.1. Registration of new cs-correlation SDP attribute . . . . . 33 | |||
8.2. Registration of a new "nettype" value . . . . . . . . . . 32 | 8.2. Registration of a new "nettype" value . . . . . . . . . . 34 | |||
8.3. Registration of new "addrtype" values . . . . . . . . . . 33 | 8.3. Registration of new "addrtype" values . . . . . . . . . . 34 | |||
8.4. Registration of a new "proto" value . . . . . . . . . . . 33 | 8.4. Registration of a new "proto" value . . . . . . . . . . . 34 | |||
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 33 | 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 35 | |||
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33 | 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35 | |||
10.1. Normative References . . . . . . . . . . . . . . . . . . . 33 | 10.1. Normative References . . . . . . . . . . . . . . . . . . . 35 | |||
10.2. Informative References . . . . . . . . . . . . . . . . . . 34 | 10.2. Informative References . . . . . . . . . . . . . . . . . . 36 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 37 | |||
1. Introduction | 1. Introduction | |||
The Session Description Protocol (SDP) [RFC4566] is intended for | The Session Description Protocol (SDP) [RFC4566] is intended for | |||
describing multimedia sessions for the purposes of session | describing multimedia sessions for the purposes of session | |||
announcement, session invitation, and other forms of multimedia | announcement, session invitation, and other forms of multimedia | |||
session initiation. SDP is most commonly used for describing media | session initiation. SDP is most commonly used for describing media | |||
streams that are transported over the Real-Time Transport Protocol | streams that are transported over the Real-Time Transport Protocol | |||
(RTP) [RFC3550], using the profiles for audio and video media defined | (RTP) [RFC3550], using the profiles for audio and video media defined | |||
in RTP Profile for Audio and Video Conferences with Minimal Control | in RTP Profile for Audio and Video Conferences with Minimal Control | |||
skipping to change at page 6, line 26 | skipping to change at page 6, 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 8 and Section 7 contain the IANA and Security | SDP. Section 7 and Section 8 contain the Security and IANA | |||
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", "NOT RECOMMENDED", "MAY", and | "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | |||
"OPTIONAL" in this document are to be interpreted as described in BCP | "OPTIONAL" in this document are to be interpreted as described in BCP | |||
14, RFC 2119 [RFC2119] and indicate requirement levels for compliant | 14, RFC 2119 [RFC2119] and indicate requirement levels for compliant | |||
implementations. | implementations. | |||
skipping to change at page 7, line 32 | skipping to change at page 7, line 32 | |||
video stream. | video stream. | |||
REQ-7: It MUST be possible for endpoints to not advertise the list | REQ-7: It MUST be possible for endpoints to not advertise the list | |||
of available codecs for circuit-switched audio or video | of available codecs for circuit-switched audio or video | |||
streams. | streams. | |||
4. Overview of Operation | 4. Overview of Operation | |||
The mechanism defined in this memo extends SDP and allows describing | The mechanism defined in this memo extends SDP and allows describing | |||
an audio or video media stream established over a circuit-switched | an audio or video media stream established over a circuit-switched | |||
bearer. New tokens are registered in the "c=" and "m=" lines to be | bearer. A new network type ("PSTN") and a new protocol type ("PSTN") | |||
able to describe a media stream over a circuit-switched bearer. | are defined for the "c=" and "m=" lines to be able to describe a | |||
These SDP extensions are described in Section 5.2. Since circuit- | media stream over a circuit-switched bearer. These SDP extensions | |||
switched bearers are connection-oriented media streams, the mechanism | are described in Section 5.2. Since circuit-switched bearers are | |||
re-uses the connection-oriented extensions defined in RFC 4145 | connection-oriented media streams, the mechanism re-uses the | |||
[RFC4145] to negotiate the active and passive sides of a connection | connection-oriented extensions defined in RFC 4145 [RFC4145] to | |||
setup. This is further described in Section 5.3.1. | negotiate the active and passive sides of a connection setup. This | |||
is further described in Section 5.3.1. | ||||
4.1. Example Call Flow | 4.1. Example Call Flow | |||
Consider the example presented in Figure 1. In this example, Alice | Consider the example presented in Figure 1. In this example, Alice | |||
is located in an environment where she has access to both IP and | is located in an environment where she has access to both IP and | |||
circuit-switched bearers for communicating with other endpoints. | circuit-switched bearers for communicating with other endpoints. | |||
Alice decides that the circuit-switched bearer offers a better | Alice decides that the circuit-switched bearer offers a better | |||
perceived quality of service for voice, and issues an SDP Offer | perceived quality of service for voice, and issues an SDP Offer | |||
containing the description of an audio media stream over circuit- | containing the description of an audio media stream over circuit- | |||
switched bearer. | switched bearer. | |||
skipping to change at page 9, line 40 | skipping to change at page 9, line 40 | |||
At the moment, the only network type defined is "IN", which indicates | At the moment, the only network type defined is "IN", which indicates | |||
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 to be used within the context of a "PSTN" network type. The | |||
connection address contains an international E.164 number represented | "E164" address type indicates that the connection address contains an | |||
according to the ITU-T E.164 [ITU.E164.1991] recommendation. | E.164 number represented according to the ITU-T E.164 [ITU.E164.1991] | |||
recommendation. | ||||
It is a common convention that an international E.164 number contains | It is a common convention that an international E.164 number contains | |||
a leading '+' sign. For consistency's sake, we also require the | a leading '+' sign. For consistency's sake, we also require the | |||
E.164 telephone is prepended with a '+', even if that is not | E.164 telephone is prepended with a '+', even if that is not | |||
necessary for routing of the call in the PSTN network. | 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 | Please note that this "E164" and "-" address type defined in this | |||
omitted without being set to a "-" since this would violate basic | memo are exclusively defined to be used in conjunction with the | |||
syntax of SDP [RFC4566]. | "PSTN" network type. Usages of "E164" or "-" address types in | |||
conjunction with other network types may exist elsewhere. | ||||
This memo exclusively uses the international representation of E.164 | ||||
numbers, i.e., those initiated with a '+' sign. The syntax (see | ||||
Section 5.7) refers to the representation of a 'global-number' | ||||
construction already specified in RFC 3966 [RFC3966]. This | ||||
representation requires the presence of the '+' sign. Additionally, | ||||
this representation allows for the presence of one or more 'visual- | ||||
separator' constructions. Implementations confirming to this | ||||
specification and using the "E164" address type together with the | ||||
"PSTN" network type MUST only use international E.164, i.e., those | ||||
starting with a '+' sign and SHOULD NOT use visual-separators. | ||||
Note that <addrtype> and/or <connection-address> MUST NOT be | ||||
omitted when unknown since this would violate basic syntax of SDP | ||||
[RFC4566]. In such cases, they MUST be set to a "-". | ||||
The following are examples of the extension to the connection data | The following are examples of the extension to the connection data | |||
line: | line: | |||
c=PSTN E164 +35891234567 | c=PSTN E164 +35891234567 | |||
c=PSTN - - | c=PSTN - - | |||
When the <addrtype> is PSTN, the connection address is defined as | When the <addrtype> is PSTN, the connection address is defined as | |||
follows: | follows: | |||
skipping to change at page 12, line 44 | skipping to change at page 13, line 13 | |||
more mechanisms simultaneously. | more mechanisms simultaneously. | |||
5.2.3.1. The "cs-correlation" attribute | 5.2.3.1. The "cs-correlation" attribute | |||
In order to provide support for the correlation mechanisms, we define | In order to provide support for the correlation mechanisms, we define | |||
a new SDP attribute called "cs-correlation". This "cs-correlation" | a new SDP attribute called "cs-correlation". This "cs-correlation" | |||
attribute can include any of the "callerid", "uuie", or "dtmf" | attribute can include any of the "callerid", "uuie", or "dtmf" | |||
subfields, which specify additional information required by the | subfields, 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, see Section 5.2.3.5 fore more details. There | |||
MUST be at most one "cs-correlation" attribute per media description. | ||||
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: <correlation-mechanisms> | a=cs-correlation: <correlation-mechanisms> | |||
correlation-mechanisms = corr-mech *(SP corr-mech) | correlation-mechanisms = corr-mech *(SP corr-mech) | |||
corr-mech = caller-id-mech / uuie-mech / | corr-mech = caller-id-mech / uuie-mech / | |||
dfmt-mech / ext-mech | dfmt-mech / ext-mech | |||
caller-id-mech = "callerid" [":" caller-id-value] | caller-id-mech = "callerid" [":" caller-id-value] | |||
uuie-mech = "uuie" [":" uuie-value] | uuie-mech = "uuie" [":" uuie-value] | |||
skipping to change at page 14, line 49 | skipping to change at page 15, line 16 | |||
Element (UUIE) identifier is composed of a first octet identifying | Element (UUIE) identifier is composed of a first octet identifying | |||
this as a User-User Information Element, a second octet containing | this as a User-User Information Element, a second octet containing | |||
the Length of the user-user contents, a third octet containing a | the Length of the user-user contents, a third octet containing a | |||
Protocol Discriminator, and a value of up to 32 or 128 octets | Protocol Discriminator, and a value of up to 32 or 128 octets | |||
(depending on network settings) containing the actual User | (depending on network settings) containing the actual User | |||
Information (see Figure 4-36 in ITU-T Q.931). The first two octets | Information (see Figure 4-36 in ITU-T Q.931). The first two octets | |||
of the UUIE MUST NOT be used for correlation, only the octets | of the UUIE MUST NOT be used for correlation, only the octets | |||
carrying the Protocol Discriminator and the User Information value | carrying the Protocol Discriminator and the User Information value | |||
are input to the creation of the value of the "uuie" subfield in the | are input to the creation of the value of the "uuie" subfield in the | |||
"cs-correlation" attribute. Therefore, the value of the "uuie" | "cs-correlation" attribute. Therefore, the value of the "uuie" | |||
subfield in the "cs-correlation" attribute MUST start with the the | subfield in the "cs-correlation" attribute MUST start with the | |||
value starting at the Protocol Discriminator octet, followed by the | Protocol Discriminator octet, followed by the User Information | |||
User Information octets. The value of the Protocol Discriminator | octets. The value of the Protocol Discriminator octet is not | |||
octet is not specified in this document; it is expected that | specified in this document; it is expected that organizations using | |||
organizations using this technology will allocate a suitable value | this technology will allocate a suitable value for the Protocol | |||
for the Protocol Discriminator. | Discriminator. | |||
Once the binary value of the "uuie" subfield in the "cs-correlation" | Once the binary value of the "uuie" subfield in the "cs-correlation" | |||
attribute is created, it MUST be encoded in hexadecimal before it is | attribute is created, it MUST be encoded in hexadecimal before it is | |||
inserted in SDP. Each octet of binary data to be represented in the | inserted in SDP. Each octet of binary data to be represented in the | |||
hexadecimal encoding MUST be mapped to two hexadecimal digits | hexadecimal encoding MUST be mapped to two hexadecimal digits | |||
(represented by ASCII characters 0-9, A-F and a-f), each representing | (represented by ASCII characters 0-9 and A-F, each representing four | |||
four bits within the octet. The four bits appearing first in the | bits within the octet. The four bits appearing first in the binary | |||
binary data MUST be mapped to the first hexadecimal digit and the | data MUST be mapped to the first hexadecimal digit and the four | |||
four subsequent bits in the binary data MUST be mapped to the second | subsequent bits in the binary data MUST be mapped to the second | |||
hexadecimal digit. When mapping 4 bits to a hexadecimal digit, the | hexadecimal digit. When mapping 4 bits to a hexadecimal digit, the | |||
bit appearing first in the binary data shall be most significant. | bit appearing first in the binary data SHALL be most significant. | |||
Thus, the resulting hexadecimal encoded value needs to have an even | Thus, the resulting hexadecimal encoded value needs to have an even | |||
number of hexadecimal digits, and MUST be considered invalid if it | number of hexadecimal digits, and MUST be considered invalid if it | |||
has an odd number. | has an odd number. | |||
Note that the encoding of the "uuie" subfield of the "cs- | Note that the encoding of the "uuie" subfield of the "cs- | |||
correlation" attribute is largely inspired by the encoding of the | correlation" attribute is largely inspired by the encoding of the | |||
same value in the User-to-User header field in SIP, according to | same value in the User-to-User header field in SIP, according to | |||
the document A Mechanism for Transporting User to User Call | the document A Mechanism for Transporting User to User Call | |||
Control Information in SIP [I-D.ietf-cuss-sip-uui]. | Control Information in SIP [I-D.ietf-cuss-sip-uui]. | |||
As an example, an endpoint willing to send a UUIE containing a | As an example, an endpoint willing to send a UUIE containing a | |||
protocol discriminator with the hexadecimal value of %x56 and an | protocol discriminator with the hexadecimal value of %x56 and an | |||
hexadecimal User Information value of %xa390f3d2b7310023 would | hexadecimal User Information value of %xA390F3D2B7310023 would | |||
include a "cs-correlation" attribute line as follows: | include a "cs-correlation" attribute line as follows: | |||
a=cs-correlation:uuie:56a390f3d2b7310023 | a=cs-correlation:uuie:56A390F3D2B7310023 | |||
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 an 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 | |||
User-User information available end to end in the PSTN. On the other | User-User information available end to end in the PSTN. On the other | |||
hand, the generation of the User-User Information Element is | hand, the generation of the User-User Information Element is | |||
skipping to change at page 17, line 7 | skipping to change at page 17, line 22 | |||
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.2.3.5. Extensions to correlation mechanisms | ||||
New values for the "cs-correlation" attribute may be specified. The | ||||
registration policy for new values is "Specification Required", see | ||||
Section 8. Any such specification MUST include a description of how | ||||
SDP Offer/Answer mechanism is used to negotiate the use of the new | ||||
values, taking into account how endpoints determine which side will | ||||
become active or passive (see Section 5.3 for more details). | ||||
If, during the Offer/Answer negotiation, either endpoint encounters | ||||
an unknown value in the "cs-correlation" attribute, it MUST consider | ||||
that mechanism as unsupported, and MUST NOT include that value in | ||||
subsequent 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. In | are non-exclusive, and can be used independently of each other. In | |||
order to know how to populate the "a=cs-correlation" attribute, the | order to know how to populate the "cs-correlation" attribute, the | |||
endpoints need to agree which endpoint will become the active party, | endpoints need to agree which endpoint will become the active party, | |||
i.e. the one that will set up the circuit-switched bearer. | i.e. the one that will set up the circuit-switched bearer. | |||
5.3.1. Determining the Direction of the Circuit-Switched Bearer Setup | 5.3.1. Determining the Direction of the Circuit-Switched Bearer Setup | |||
In order to avoid a situation where both endpoints attempt to | In order to avoid a situation where both endpoints attempt to | |||
initiate a connection simultaneously, the direction in which the | initiate a connection simultaneously, the direction in which the | |||
circuit-switched bearer is set up should be negotiated during the | circuit-switched bearer is set up MUST 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 | |||
connection establishment of circuit-switched bearers. This | connection establishment of circuit-switched bearers. This | |||
specification uses the concepts specified in RFC 4145 [RFC4145] for | specification uses the concepts specified in RFC 4145 [RFC4145] for | |||
agreeing on the direction of establishment of a circuit-switched | agreeing on the direction of establishment of a circuit-switched | |||
bearer. | bearer. | |||
skipping to change at page 17, line 50 | skipping to change at page 18, line 30 | |||
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 bearer after the Offer/Answer process. The passive party is | switched bearer after the Offer/Answer exchange. The passive party | |||
the one receiving the circuit-switched bearer. Either party may | is 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 in Section 5.6. | Offer/Answer exchange using the procedures described in Section 5.6. | |||
5.3.2. Populating the cs-correlation attribute | 5.3.2. Populating the cs-correlation attribute | |||
By defining values for the subfields in the "a=cs-correlation" | By defining values for the subfields in the "a=cs-correlation" | |||
attribute, the endpoint indicates that it is willing to become the | attribute, the endpoint indicates that it is willing to become the | |||
active party, and that it can use those values in the Calling party | active party, and that it can use those values in the Calling party | |||
number, User-User Information Element, or as DTMF tones during the | number, User-User Information Element, or as DTMF tones during the | |||
circuit-switched bearer setup. | circuit-switched bearer setup. | |||
skipping to change at page 20, line 27 | skipping to change at page 21, line 9 | |||
Note that this may result in the recipient of the initial Offer in | Note that this may result in the recipient of the initial Offer in | |||
rejecting the Offer if the recipient of the Offer is not aware of | rejecting the Offer if the recipient of the Offer is not aware of | |||
its own E.164 number, and thus concluding that it will not be | its own E.164 number, and thus concluding that it will not be | |||
possible to establish a circuit-switched bearer since neither | possible to establish a circuit-switched bearer since neither | |||
party is aware of their E.164 number. | party is aware of their E.164 number. | |||
5.6. Offer/Answer mode extensions | 5.6. Offer/Answer mode extensions | |||
In this section, we define extensions to the Offer/Answer model | In this section, we define extensions to the Offer/Answer model | |||
defined in The Offer/Answer Model in SDP [RFC3264] and extended in | defined in The Offer/Answer Model in SDP [RFC3264] to allow for PSTN | |||
the SDP Capability Negotiation [RFC5939] to allow for PSTN addresses | addresses to be used with the Offer/Answer model. | |||
to be used with the Offer/Answer model. | ||||
5.6.1. Generating the Initial Offer | 5.6.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 international E.164 number | <connection-address> field to its own international E.164 number | |||
(with a leading "+"). If the endpoint is not aware of its own E.164 | (with a leading "+"). If the endpoint is not aware of its own E.164 | |||
skipping to change at page 21, line 11 | skipping to change at page 21, line 40 | |||
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. | |||
For dynamic payload types, the endpoint MUST define the set of valid | For dynamic payload types, the endpoint MUST define the set of valid | |||
encoding names and related parameters using the "a=rtpmap" attribute | encoding names and related parameters using the "a=rtpmap" attribute | |||
line. See Section 6 of SDP [RFC4566] for details. | line. See Section 6 of SDP [RFC4566] for details. | |||
When generating the Offer, if the Offerer supports any of the | When generating the Offer, if the Offerer supports any of the | |||
correlation mechanisms defined in this memo, it MUST include an | correlation mechanisms defined in this memo, it MUST include an | |||
attribute line "a=cs-correlation" in the SDP offer. The "a=cs- | attribute line "a=cs-correlation" in the SDP offer. The Offerer MUST | |||
correlation" line contains an enumeration of the correlation | NOT include more than one "cs-correlation" attribute per media | |||
mechanisms supported by the Offerer, in the format of subfields. | decription. The "a=cs-correlation" line contains an enumeration of | |||
the correlation mechanisms supported by the Offerer, in the format of | ||||
subfields. | ||||
The current list of subfields include "callerid", "uuie" and "dtmf" | The current list of subfields 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" subfields and MUST | MUST add the "callerid", "uuie", and/or "dtmf" subfields and MUST | |||
specify values for those subfields. | specify values for those subfields. | |||
skipping to change at page 21, line 50 | skipping to change at page 22, line 33 | |||
a=cs-correlation:uuie dtmf | a=cs-correlation:uuie dtmf | |||
a=setup:passive | a=setup:passive | |||
If, on the other hand, the Offerer is willing to use the User-User | If, on the other hand, the Offerer is willing to use the User-User | |||
Information element and the DTMF correlation mechanisms, and is able | Information element and the DTMF correlation mechanisms, and is able | |||
to become the active or passive side, it includes to following lines | to become the active or passive side, it includes to following lines | |||
to the SDP: | to the SDP: | |||
a=cs-correlation:uuie:56a390f3d2b7310023 dtmf:14D*3 | a=cs-correlation:uuie:56A390F3D2B7310023 dtmf:14D*3 | |||
a=setup:actpass | a=setup:actpass | |||
The negotiation of the value of the 'setup' attribute takes place as | The negotiation of the value of the 'setup' attribute takes place as | |||
defined in Section 4.1 of TCP-Based Media Transport in the SDP | defined in Section 4.1 of TCP-Based Media Transport in the SDP | |||
[RFC4145]. | [RFC4145]. | |||
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 international E.164 number, it MUST | If an Offerer does not know its international E.164 number, it MUST | |||
set the 'a=setup' attribute to the value 'active'. If the Offerer | set the 'a=setup' attribute to the value 'active'. If the Offerer | |||
knows its international E.164 number, it MUST set the value to either | knows its international E.164 number, it SHOULD set the value to | |||
'actpass' or 'passive'. | either '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. For the initial | circuit-switched bearer is to be established or not. For the initial | |||
Offer, the Offerer MUST use value 'new'. | Offer, the Offerer MUST use value 'new'. | |||
5.6.2. Generating the Answer | 5.6.2. Generating the Answer | |||
skipping to change at page 23, line 21 | skipping to change at page 24, line 4 | |||
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 international E.164 number, the | due to the Answerer not knowing its international E.164 number, 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 on the Answer. If the Answerer is aware of its | number to zero on the Answer. If the Answerer is aware of its | |||
international E.164 number, it MUST include the "a=setup" attribute | international E.164 number, it MUST include the "a=setup" attribute | |||
in the Answer and set it to value "passive" or "holdconn". | in the Answer and set it to value "passive" or "holdconn". The | |||
Answerer MUST also include its E.164 number on the "c=" line. | ||||
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. | |||
skipping to change at page 23, line 45 | skipping to change at page 24, line 29 | |||
international E.164 number in the "c=" line, the Answerer SHOULD | international E.164 number in the "c=" line, the Answerer SHOULD | |||
become the active party. If the Offer does not include an E.164 | become the active party. If the Offer does not include an E.164 | |||
number, and if the Answerer is aware of its international E.164 | number, and if the Answerer is aware of its international E.164 | |||
number, it MUST become the passive party. If the Offer does not | number, it MUST become the passive party. If the Offer does not | |||
include an E.164 number in the "c=" line and the Answerer is not | include an E.164 number in the "c=" line and the Answerer is not | |||
aware of its E.164 number, it MUST reject the circuit-switched media | aware of its E.164 number, it MUST reject the circuit-switched media | |||
by setting the port number to zero in the Answer. | by setting the port number to zero in the Answer. | |||
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 and is willing to use. | |||
NOT add any mechanisms which were not included in the offer. | The Answerer MUST NOT add any mechanisms which were not included in | |||
the offer. If there are more than one "cs-correlation" attributes | ||||
per media description in the Offer, the Answerer MUST discard all but | ||||
the first for any media description. Also, the Answerer MUST discard | ||||
all unknown "cs-correlation" attribute values. | ||||
If the Answerer becomes the active party, it MUST add any of the | If the Answerer becomes the active party, it MUST add any of the | |||
"callerid", "uuie" or "dtmf" subfield values. | "callerid", "uuie" or "dtmf" subfield values. | |||
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" subfields. | the "callerid", "uuie" and/or "dtmf" subfields. | |||
After generating and sending the Answer, if the Answerer became the | After generating and sending the Answer, if the Answerer became the | |||
active party, it | active party, it | |||
o MUST extract the E.164 number from the "c=" line of the Offer and | o MUST extract the E.164 number from the "c=" line of the Offer and | |||
MUST establish a circuit-switched bearer to that address. | MUST establish a circuit-switched bearer to that address. | |||
o if the SDP Answer contained a value for the "callerid" subfield, | o if the SDP Answer contained a value for the "callerid" subfield, | |||
must set the Calling Party Number Information Element to that | MUST set the Calling Party Number Information Element to that | |||
number, | number, | |||
o if the SDP Answer contained a value for the "uuie" subfield, MUST | o if the SDP Answer contained a value for the "uuie" subfield, MUST | |||
send the User-User Information element according to the rules | send the User-User Information element according to the rules | |||
defined for the circuit-switched technology used, and set the | defined for the circuit-switched technology used, and set the | |||
value of the Information Element to that received in the SDP | value of the Information Element to that received in the SDP | |||
Offer, | Offer, | |||
o if the SDP Answer contained a value for the "dtmf" subfield, MUST | o if the SDP Answer contained a value for the "dtmf" subfield, MUST | |||
send those DTMF digits according to the circuit-switched | send those DTMF digits according to the circuit-switched | |||
skipping to change at page 25, line 5 | skipping to change at page 25, line 38 | |||
correlation" attribute, the call SHOULD be treated as correlated | correlation" attribute, the call SHOULD be treated as correlated | |||
to the ongoing session. | to the ongoing session. | |||
o if the Offer contained a value for the "uuie" subfield, MUST be | o if the Offer contained a value for the "uuie" subfield, MUST be | |||
prepared to receive a User-User Information element once the | prepared to receive a User-User Information element once the | |||
circuit-switched bearer is set up. The Answerer MUST compare the | circuit-switched bearer is set up. The Answerer MUST compare the | |||
received UUI to the value of the "uuie" subfield. If the value of | received UUI to the value of the "uuie" subfield. If the value of | |||
the received UUI matches the value of the "uuie" subfield, the | the received UUI matches the value of the "uuie" subfield, the | |||
call SHOULD be treated as correlated to the ongoing session. | call SHOULD be treated as correlated to the ongoing session. | |||
If the Answerer becomes the active party, generates an SDP answer, | ||||
and then it finds out that the circuit-switched call cannot be | ||||
established, then the Answerer MUST create a new SDP offer where | ||||
circuit-switched stream is removed from the session (actually, by | ||||
setting the corresponding port in the m= line to zero) and send it to | ||||
its counter part. This is to synchronize both parties (and potential | ||||
intermediaries) on the state of the session. | ||||
5.6.3. Offerer processing the Answer | 5.6.3. Offerer processing the Answer | |||
When receiving the Answer, if the SDP does not contain "a=cs- | When receiving the Answer, if the SDP does not contain "a=cs- | |||
correlation" attribute line, the Offerer should take that as an | correlation" attribute line, the Offerer should take that as an | |||
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 | |||
skipping to change at page 25, line 36 | skipping to change at page 26, line 28 | |||
Answer, | Answer, | |||
o if the SDP Answer contained a value for the "dtmf" subfield, MUST | o if the SDP Answer contained a value for the "dtmf" subfield, MUST | |||
send those DTMF digits according to the circuit-switched | send those DTMF digits according to the circuit-switched | |||
technology used. | technology used. | |||
If the Offerer becomes the passive party, it | If the Offerer becomes the passive party, it | |||
o MUST be prepared to receive a circuit-switched bearer, | o MUST be prepared to receive a circuit-switched bearer, | |||
o Note that it if delivery of the Answer is delayed for some reason, | ||||
the circuit-switched call attempt may arrive at the Offerer before | ||||
the Answer has been processed. In this case, since the | ||||
correlation mechanisms are negotiated as part of the Offer/Answer | ||||
exchange, the Answerer cannot know whether or not the incoming | ||||
circuit-switched call attempt is correlated with the session being | ||||
negotiated, the Offerer SHOULD answer the circuit-switched call | ||||
attempt only after it has received and processed the Answer. | ||||
o if the Answer contained a value for the "dtmf" subfield, MUST be | o if the Answer contained a value for the "dtmf" subfield, MUST be | |||
prepared to receive and collect DTMF digits once the circuit- | prepared to receive and collect DTMF digits once the circuit- | |||
switched bearer is set up. The Offerer SHOULD compare the | switched bearer is set up. The Offerer SHOULD compare the | |||
received DTMF digits to the value of the "dtmf" subfield. If the | received DTMF digits to the value of the "dtmf" subfield. If the | |||
received DTMF digits match the value of the "dtmf" subfield in the | received DTMF digits match the value of the "dtmf" subfield in the | |||
"cs-correlation" attribute, the call SHOULD be treated as | "cs-correlation" attribute, the call SHOULD be treated as | |||
correlated to the ongoing session. | correlated to the ongoing session. | |||
o if the Answer contained a value for the "uuie" subfield, MUST be | o if the Answer contained a value for the "uuie" subfield, MUST be | |||
prepared to receive a User-User Information element once the | prepared to receive a User-User Information element once the | |||
skipping to change at page 26, line 34 | skipping to change at page 27, line 34 | |||
exchange where it MUST set the "a=connection" attribute to 'new'". | exchange where it MUST set the "a=connection" attribute to 'new'". | |||
If the media types are different (for example, a different codec will | If the media types are different (for example, a different codec will | |||
be used for the circuit-switched bearer), the media descriptions for | be used for the circuit-switched bearer), the media descriptions for | |||
terminating the existing bearer and the new bearer can be in the same | terminating the existing bearer and the new bearer can be in the same | |||
Offer. | Offer. | |||
5.7. Formal Syntax | 5.7. 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] and the | |||
Implementations according to this specification MUST be compliant | tel URI [RFC3966] grammars. Implementations according to this | |||
with this syntax. | specification MUST be compliant with this syntax. | |||
Figure 2 shows the formal syntax of the extensions defined in this | Figure 2 shows the formal syntax of the extensions defined in this | |||
memo. | memo. | |||
; extension to the connection field originally specified | ; extension to the connection field originally specified | |||
; in RFC 4566 | ; in 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 /= global-number / "-" | |||
e164-address = "+" 1*15DIGIT | ; global-number specified in RFC 3966 | |||
; 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 / | corr-mech = caller-id-mech / uuie-mech / | |||
dtmf-mech / ext-mech | dtmf-mech / ext-mech | |||
caller-id-mech = "callerid" [":" caller-id-value] | caller-id-mech = "callerid" [":" caller-id-value] | |||
caller-id-value = "+" 1*15DIGIT | caller-id-value = "+" 1*15DIGIT | |||
uuie-mech = "uuie" [":" uuie-value] | uuie-mech = "uuie" [":" uuie-value] | |||
uuie-value = 1*130(HEXDIG / %x61-66) | uuie-value = 1*65(HEXDIG HEXDIG) | |||
;0-9, A-F, and a-f | ;This represents up to 130 HEXDIG (65 octets) | |||
;HEXDIG defined in RFC5234 | ;HEXDIG defined in RFC5234 | |||
dtmf-mech = "dtmf" [":" dtmf-value] | ;HEXDIG defined as 0-9, A-F | |||
dtmf-value = 1*32(DIGIT / %x41-44 / %x23 / %x2A ) | dtmf-mech = "dtmf" [":" dtmf-value] | |||
;0-9, A-D, '#' and '*' | dtmf-value = 1*32(DIGIT / %x41-44 / %x23 / %x2A ) | |||
ext-mech = ext-mech-name[":" ext-mech-value] | ;0-9, A-D, '#' and '*' | |||
ext-mech-name = token | ext-mech = ext-mech-name[":" ext-mech-value] | |||
ext-mech-value = token | ext-mech-name = token | |||
; token is specified in RFC4566 | ext-mech-value = token | |||
; token is specified in RFC4566 | ||||
Figure 2: Syntax of the SDP extensions | Figure 2: Syntax of the SDP extensions | |||
6. Examples | 6. Examples | |||
In the examples below, where an SDP line is too long to be displayed | In the examples below, where an SDP line is too long to be displayed | |||
as a single line, a braking character "\" indicates continuation in | as a single line, a breaking character "\" indicates continuation in | |||
the following line. Note that this is character is included for | the following line. Note that this character is included for display | |||
displaying purposes. Implementation MUST write a single line without | purposes only. Implementation MUST write a single line without | |||
brakes. | breaks. | |||
6.1. Single PSTN audio stream | 6.1. Single PSTN audio stream | |||
Alice Bob | Alice Bob | |||
| | | | | | |||
| (1) SDP Offer (PSTN audio) | | | (1) SDP Offer (PSTN audio) | | |||
|--------------------------------->| | |--------------------------------->| | |||
| | | | | | |||
| (2) SDP Answer (PSTN audio) | | | (2) SDP Answer (PSTN audio) | | |||
|<---------------------------------| | |<---------------------------------| | |||
skipping to change at page 28, line 25 | skipping to change at page 29, line 25 | |||
| 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 shown in Figure 4. The Offer describes a PSTN circuit- | |||
switched bearer in the "m=" and "c=" line where it also indicates its | switched bearer in the "m=" and "c=" line where it also indicates its | |||
international E.164 number format. Additionally, Alice expresses | international E.164 number format. Additionally, Alice expresses | |||
that she can initiate the circuit-switched bearer or be the recipient | that she can initiate the circuit-switched bearer or be the recipient | |||
of it in the "a=setup" attribute line. The SDP Offer also includes a | of it in the "a=setup" attribute line. The SDP Offer also includes | |||
correlation identifiers that this endpoint will be inserting the | correlation identifiers that this endpoint will insert in the Calling | |||
Calling Party Number and/or User-User Information Element of the PSTN | Party Number and/or User-User Information Element of the PSTN call | |||
call setup if eventually this endpoint initiates the PSTN call. | setup if eventually this endpoint initiates the PSTN call. | |||
v=0 | v=0 | |||
o=jdoe 2890844526 2890842807 IN IP4 192.0.2.5 | o=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 +35891234567 | c=PSTN E164 +35891234567 | |||
a=setup:actpass | a=setup:actpass | |||
a=connection:new | a=connection:new | |||
a=cs-correlation:callerid:+15551234 \ | a=cs-correlation:callerid:+15551234 \ | |||
uuie:56a390f3d2b7310023 | uuie:56A390F3D2B7310023 | |||
Figure 4: SDP offer (1) | Figure 4: SDP offer (1) | |||
Bob generates a SDP Answer (Figure 5), describing a PSTN audio media | Bob generates a SDP Answer (Figure 5), describing a PSTN audio media | |||
on port 9 without information on the media sub-type on the "m=" line. | on port 9 without information on the media sub-type on the "m=" line. | |||
The "c=" line contains Bob's international E.164 number. In the | The "c=" line contains Bob's international E.164 number. In the | |||
"a=setup" line Bob indicates that he is willing to become the active | "a=setup" line Bob indicates that he is willing to become the active | |||
endpoint when establishing the PSTN call, and he also includes the | endpoint when establishing the PSTN call, and he also includes the | |||
"a=cs-correlation" attribute line containing the values he is going | "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 | to include in the Calling Party Number and User-User IE of the PSTN | |||
skipping to change at page 29, line 16 | skipping to change at page 30, line 16 | |||
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 +35897654321 | c=PSTN E164 +35897654321 | |||
a=setup:active | a=setup:active | |||
a=connection:new | a=connection:new | |||
a=cs-correlation:callerid:+15554321 \ | a=cs-correlation:callerid:+15554321 \ | |||
uuie:56a390f3d2b7310023 | uuie:56A390F3D2B7310023 | |||
Figure 5: SDP Answer with circuit-switched media | Figure 5: SDP Answer with circuit-switched media | |||
When Alice receives the Answer, she examines that Bob is willing to | When Alice receives the Answer, she examines that Bob is willing to | |||
become the active endpoint when setting up the PSTN call. Alice | become the active endpoint when setting up the PSTN call. Alice | |||
temporarily stores Bob's E.164 number and the User-User IE value of | temporarily stores Bob's E.164 number and the User-User IE value of | |||
the "cs-correlation" attribute, and waits for a circuit-switched | the "cs-correlation" attribute, and waits for a circuit-switched | |||
bearer establishment. | bearer establishment. | |||
Bob initiates a circuit-switched bearer using whatever circuit- | Bob initiates a circuit-switched bearer using whatever circuit- | |||
switched technology is available for him. The called party number is | 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 | 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 | number. Bob also sets the User-User Information Element value to the | |||
on contained in the SDP Answer. | one contained in the SDP Answer. | |||
When Alice receives the circuit-switched bearer establishment, she | When Alice receives the circuit-switched bearer establishment, she | |||
examines the UUIE and the calling party number, and by comparing | examines the UUIE and the calling party number, and by comparing | |||
those received during O/A exchange determines that the call is | those received during O/A exchange determines that the call is | |||
related to the SDP session. | related to the SDP session. | |||
It may also be that neither the UUIE nor the calling party number is | 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 | received by the called party, or the format of the calling party | |||
number is changed by the PSTN. Implementations may still accept such | number is changed by the PSTN. Implementations may still accept such | |||
call establishment attempts as being related to the session that was | call establishment attempts as being related to the session that was | |||
skipping to change at page 32, line 6 | skipping to change at page 33, line 6 | |||
calling line identification into account if possible, by restricting | calling line identification into account if possible, by restricting | |||
the inclusion of the phone number in SDP "c=" line if the caller has | the inclusion of the phone number in SDP "c=" line if the caller has | |||
chosen to use CLIR. If this is not possible, implementations may | chosen to use CLIR. If this is not possible, implementations may | |||
present a prompt informing the user that their phone number may be | present a prompt informing the user that their phone number may be | |||
transmitted to the other party. | transmitted to the other party. | |||
Similarly as with IP addresses, if there is a desire the protect the | Similarly as with IP addresses, if there is a desire the protect the | |||
SDP containing phone numbers carried in SIP, implementers are adviced | SDP containing phone numbers carried in SIP, implementers are adviced | |||
to follow the security mechanisms defined in [RFC3261]. | to follow the security mechanisms defined in [RFC3261]. | |||
It is possible that an attacker creates a circuit-switched session | ||||
whereby the attacked endpoint should dial a circuit-switched number, | ||||
perhaps even a premium-rate telephone number. To mitigate the | ||||
consequences of this attack, endpoints MUST authenticate and trust | ||||
remote endpoints users who try to remain passive in the circuit- | ||||
switched connection establishment. It is RECOMMENDED that endpoints | ||||
have local policies precluding the active establishment of circuit | ||||
switched connections to certain numbers (e.g., international, | ||||
premium, long distance). Additionally, it is strongly RECOMMENDED | ||||
that the end user is asked for consent prior to the endpoint | ||||
initiating a circuit-switched connection. | ||||
8. IANA Considerations | 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. | |||
8.1. Registration of new cs-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 | |||
skipping to change at page 32, line 28 | skipping to change at page 33, line 40 | |||
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 | |||
The IANA is requested the create a subregistry for 'cs-correlation' | The IANA is requested to create a subregistry for 'cs-correlation' | |||
attribute under the Session Description Protocol (SDP) Parameters | attribute under the Session Description Protocol (SDP) Parameters | |||
registry. The initial values for the subregistry are presented in | registry. The initial values for the subregistry are presented in | |||
the following, and IANA is requested to add them into its database: | the following, and IANA is requested to add them into its database: | |||
Value of 'cs-correlation' attribute Reference Description | Value of 'cs-correlation' attribute Reference Description | |||
----------------------------------- --------- ----------- callerid | ----------------------------------- --------- ----------- callerid | |||
RFC XXXX Caller ID uuie RFC XXXX User-User Information Element dtmf | RFC XXXX Caller ID uuie RFC XXXX User-User Information Element dtmf | |||
RFC XXXX Dual-tone Multifrequency | RFC XXXX Dual-tone Multifrequency | |||
Note for the RFC Editor: 'RFC XXXX' above should be replaced by a | Note for the RFC Editor: 'RFC XXXX' above should be replaced by a | |||
reference to the RFC number of this draft. | reference to the RFC number of this draft. | |||
As per the terminology in [RFC2434], the registration policy for new | As per the terminology in [RFC5226], the registration policy for new | |||
values of 'cs-correlation' parameter is 'Specification Required'. | values of 'cs-correlation' parameter is 'Specification Required'. | |||
8.2. Registration of a new "nettype" value | 8.2. Registration of a new "nettype" value | |||
This memo provides instructions to IANA to register a new "nettype" | This memo provides instructions to IANA to register a new "nettype" | |||
in the Session Description Protocol Parameters registry [1]. The | in the Session Description Protocol Parameters registry [1]. The | |||
registration data, according to RFC 4566 [RFC4566] follows. | registration data, according to RFC 4566 [RFC4566] follows. | |||
Type SDP Name Reference | Type SDP Name Reference | |||
---- ------------------ --------- | ---- ------------------ --------- | |||
skipping to change at page 33, line 20 | skipping to change at page 34, line 30 | |||
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] | |||
Note: RFC XXXX uses the "E164" and "-" addrtypes in conjunction with | ||||
the "PSTN" nettype. Please refer to the relevant RFC for a | ||||
description of that representation. | ||||
8.4. Registration of a new "proto" value | 8.4. Registration of a new "proto" value | |||
This memo provides instructions to IANA to register a new "proto" in | This memo provides instructions to IANA to register a new "proto" in | |||
the Session Description Protocol Parameters registry [1]. The | the Session Description Protocol Parameters registry [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] | |||
The related "fmt" namespace re-uses the conventions and payload type | ||||
number defined for RTP/AVP. In this document, the RTP audio and | ||||
video media types, when applied to PSTN circuit-switched bearers, | ||||
represent merely on audio or video codec. | ||||
9. Acknowledgments | 9. Acknowledgments | |||
The authors want to thank Paul Kyzivat, Flemming Andreasen, Thomas | The authors want to thank Paul Kyzivat, Flemming Andreasen, Thomas | |||
Belling, John Elwell, Jari Mutikainen, Miikka Poikselka, Jonathan | Belling, John Elwell, Jari Mutikainen, Miikka Poikselka, Jonathan | |||
Rosenberg, Ingemar Johansson, Christer Holmberg, and Alf Heidermark | Rosenberg, Ingemar Johansson, Christer Holmberg, Alf Heidermark, Tom | |||
for providing their insight and comments on this document. | Taylor, Thomas Belling, Keith Drage, and Andrew Allen 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 | |||
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. | |||
[RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", | ||||
RFC 3966, December 2004. | ||||
[RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in | [RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in | |||
the Session Description Protocol (SDP)", RFC 4145, | the Session Description Protocol (SDP)", RFC 4145, | |||
September 2005. | September 2005. | |||
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session | [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session | |||
Description Protocol", RFC 4566, July 2006. | Description Protocol", RFC 4566, July 2006. | |||
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an | ||||
IANA Considerations Section in RFCs", BCP 26, RFC 5226, | ||||
May 2008. | ||||
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax | [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax | |||
Specifications: ABNF", STD 68, RFC 5234, January 2008. | Specifications: ABNF", STD 68, RFC 5234, January 2008. | |||
[RFC5939] Andreasen, F., "Session Description Protocol (SDP) | ||||
Capability Negotiation", RFC 5939, September 2010. | ||||
10.2. Informative References | 10.2. Informative References | |||
[I-D.ietf-cuss-sip-uui] | [I-D.ietf-cuss-sip-uui] | |||
Johnston, A. and J. Rafferty, "A Mechanism for | Johnston, A. and J. Rafferty, "A Mechanism for | |||
Transporting User to User Call Control Information in | Transporting User to User Call Control Information in | |||
SIP", draft-ietf-cuss-sip-uui-06 (work in progress), | SIP", draft-ietf-cuss-sip-uui-07 (work in progress), | |||
May 2012. | July 2012. | |||
[ITU.E164.1991] | [ITU.E164.1991] | |||
International Telecommunications Union, "The International | International Telecommunications Union, "The International | |||
Public Telecommunication Numbering Plan", ITU- | Public Telecommunication Numbering Plan", ITU- | |||
T Recommendation E.164, 1991. | T Recommendation E.164, 1991. | |||
[ITU.Q931.1998] | [ITU.Q931.1998] | |||
"Digital Subscriber Signalling System No. 1 (DSS 1) - ISDN | "Digital Subscriber Signalling System No. 1 (DSS 1) - ISDN | |||
User - Network Interface Layer 3 Specification for Basic | User - Network Interface Layer 3 Specification for Basic | |||
Call Control", ISO Standard 9594-1, May 1998. | Call Control", ISO Standard 9594-1, May 1998. | |||
End of changes. 55 change blocks. | ||||
126 lines changed or deleted | 210 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/ |