draft-ietf-mmusic-sdp-cs-18.txt   draft-ietf-mmusic-sdp-cs-19.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: October 27, 2013 Nokia Expires: December 05, 2013 Nokia
April 25, 2013 June 03, 2013
Session Description Protocol (SDP) Extension For Setting Up Audio and Session Description Protocol (SDP) Extension For Setting Audio and Video
Video Media Streams Over Circuit-Switched Bearers In The Public Switched Media Streams Over Circuit-Switched Bearers In The Public Switched
Telephone Network (PSTN) Telephone Network (PSTN)
draft-ietf-mmusic-sdp-cs-18 draft-ietf-mmusic-sdp-cs-19
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 October 27, 2013. This Internet-Draft will expire on December 05, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 40 skipping to change at page 2, line 40
5.3.3. Considerations on correlations . . . . . . . . . . . 17 5.3.3. Considerations on correlations . . . . . . . . . . . 17
5.4. Considerations for Usage of Existing SDP . . . . . . . . 18 5.4. Considerations for Usage of Existing SDP . . . . . . . . 18
5.4.1. Originator of the Session . . . . . . . . . . . . . . 18 5.4.1. Originator of the Session . . . . . . . . . . . . . . 18
5.4.2. Contact information . . . . . . . . . . . . . . . . . 18 5.4.2. Contact information . . . . . . . . . . . . . . . . . 18
5.5. Considerations for Usage of Third Party Call Control 5.5. Considerations for Usage of Third Party Call Control
(3PCC) . . . . . . . . . . . . . . . . . . . . . . . . . 18 (3PCC) . . . . . . . . . . . . . . . . . . . . . . . . . 18
5.6. Offer/Answer mode extensions . . . . . . . . . . . . . . 19 5.6. Offer/Answer mode extensions . . . . . . . . . . . . . . 19
5.6.1. Generating the Initial Offer . . . . . . . . . . . . 19 5.6.1. Generating the Initial Offer . . . . . . . . . . . . 19
5.6.2. Generating the Answer . . . . . . . . . . . . . . . . 21 5.6.2. Generating the Answer . . . . . . . . . . . . . . . . 21
5.6.3. Offerer processing the Answer . . . . . . . . . . . . 24 5.6.3. Offerer processing the Answer . . . . . . . . . . . . 24
5.6.4. Modifying the session . . . . . . . . . . . . . . . . 25 5.6.4. Modifying the session . . . . . . . . . . . . . . . . 26
5.7. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . 26 5.7. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . 26
6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 27 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 27
6.1. Single PSTN audio stream . . . . . . . . . . . . . . . . 27 6.1. Single PSTN audio stream . . . . . . . . . . . . . . . . 27
6.2. Advanced SDP example: Circuit-Switched Audio and 6.2. Advanced SDP example: Circuit-Switched Audio and
Video Streams . . . . . . . . . . . . . . . . . . . . . . 29 Video Streams . . . . . . . . . . . . . . . . . . . . . . 29
7. Security Considerations . . . . . . . . . . . . . . . . . . . 30 7. Security Considerations . . . . . . . . . . . . . . . . . . . 31
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32
8.1. Registration of new cs-correlation SDP attribute . . . . 31 8.1. Registration of new cs-correlation SDP attribute . . . . 32
8.2. Registration of a new "nettype" value . . . . . . . . . . 32 8.2. Registration of a new "nettype" value . . . . . . . . . . 33
8.3. Registration of new "addrtype" values . . . . . . . . . . 32 8.3. Registration of new "addrtype" values . . . . . . . . . . 33
8.4. Registration of a new "proto" value . . . . . . . . . . . 33 8.4. Registration of a new "proto" value . . . . . . . . . . . 33
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 33 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 34
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 33 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 34
10.1. Normative References . . . . . . . . . . . . . . . . . . 33 10.1. Normative References . . . . . . . . . . . . . . . . . . 34
10.2. Informative References . . . . . . . . . . . . . . . . . 34 10.2. Informative References . . . . . . . . . . . . . . . . . 34
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36
1. Introduction 1. Introduction
The Session Description Protocol (SDP) [RFC4566] is intended for The Session Description Protocol (SDP) [RFC4566] is intended for
describing multimedia sessions for the purposes of session describing multimedia sessions for the purposes of session
announcement, session invitation, and other forms of multimedia announcement, session invitation, and other forms of multimedia
session initiation. SDP is most commonly used for describing media session initiation. SDP is most commonly used for describing media
streams that are transported over the Real-Time Transport Protocol streams that are transported over the Real-Time Transport Protocol
(RTP) [RFC3550], using the profiles for audio and video media defined (RTP) [RFC3550], using the profiles for audio and video media defined
in RTP Profile for Audio and Video Conferences with Minimal Control in RTP Profile for Audio and Video Conferences with Minimal Control
skipping to change at page 5, line 45 skipping to change at page 5, line 45
are defined for the "c=" and "m=" lines to be able to describe a are defined for the "c=" and "m=" lines to be able to describe a
media stream over a circuit-switched bearer. These SDP extensions media stream over a circuit-switched bearer. These SDP extensions
are described in Section 5.2. Since circuit-switched bearers are are described in Section 5.2. Since circuit-switched bearers are
connection-oriented media streams, the mechanism re-uses the connection-oriented media streams, the mechanism re-uses the
connection-oriented extensions defined in RFC 4145 [RFC4145] to connection-oriented extensions defined in RFC 4145 [RFC4145] to
negotiate the active and passive sides of a connection setup. This negotiate the active and passive sides of a connection setup. This
is further described in Section 5.3.1. 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,
is located in an environment where she has access to both IP and Endpoint A is located in an environment where it has access to both
circuit-switched bearers for communicating with other endpoints. IP and circuit-switched bearers for communicating with other
Alice decides that the circuit-switched bearer offers a better endpoints. Endpoint A decides that the circuit-switched bearer
perceived quality of service for voice, and issues an SDP Offer offers a better perceived quality of service for voice, and issues an
containing the description of an audio media stream over circuit- SDP Offer containing the description of an audio media stream over
switched bearer. circuit-switched bearer.
Alice Bob Endpoint A Endpoint B
| (1) SDP Offer (PSTN audio) | | (1) SDP Offer (PSTN audio) |
|----------------------------------->| |----------------------------------->|
| | | |
| (2) SDP Answer (PSTN audio) | | (2) SDP Answer (PSTN audio) |
|<-----------------------------------| |<-----------------------------------|
| | | |
| PSTN call setup | | PSTN call setup |
|<-----------------------------------| |<-----------------------------------|
| | | |
| | | |
|<===== media over PSTN bearer =====>| |<===== media over PSTN bearer =====>|
| | | |
Figure 1: Example Flow Figure 1: Example Flow
Bob receives the SDP offer and determines that he is located in an Endpoitn B receives the SDP offer and determines that it is located
environment where the IP based bearer is not suitable for real-time in an environment where the IP based bearer is not suitable for real-
audio media. However he also has PSTN circuit-switched bearer time audio media. However, Endpoint B also has PSTN circuit-switched
available for audio. Bob generates an SDP answer containing a bearer available for audio. Endpoint B generates an SDP answer
description of the audio media stream over a circuit-switched bearer. containing a description of the audio media stream over a circuit-
switched bearer.
During the offer-answer exchange Alice and Bob also agree the During the offer-answer exchange Endpoints A and B also agree the
direction in which the circuit-switched bearer should be established. direction in which the circuit-switched bearer should be established.
In this example, Bob becomes the active party, in other words, he In this example, Endpoint B becomes the active party, in other words,
establishes the circuit-switched call to the other endpoint. The it establishes the circuit-switched call to the other endpoint. The
Offer/Answer exchange contains identifiers or references that can be Offer/Answer exchange contains identifiers or references that can be
used on the circuit-switched network for addressing the other used on the circuit-switched network for addressing the other
endpoint, as well as information that is used to determine that the endpoint, as well as information that is used to determine that the
incoming circuit-switched bearer establishment is related to the incoming circuit-switched bearer establishment is related to the
ongoing session between Alice and Bob. ongoing session between the two endpoints.
Bob establishes a circuit-switched bearer towards Alice using Endpoint B establishes a circuit-switched bearer towards Endpoint A
whatever mechanisms are defined for the network type in question. using whatever mechanisms are defined for the network type in
When receiving the incoming circuit-switched connection attempt, question. When receiving the incoming circuit-switched connection
Alice is able to determine that the attempt is related to the session attempt, Endpoint A is able to determine that the attempt is related
she is just establishing with Bob. to the session it is just establishing with B.
Alice accepts the circuit-switched connection; the circuit-switched Endpoint A accepts the circuit-switched connection; the circuit-
bearer setup is completed. Bob and Alice can now use the circuit- switched bearer setup is completed. The two endpoints can now use
switched connection for two-way audio media. the circuit-switched connection for two-way audio media.
If, for some reason, Bob would like to reject the offered stream, he If, for some reason, Endpoint B would like to reject the offered
would set the port number of the specific stream to zero, as stream, it would set the port number of the specific stream to zero,
specified in RFC3264 [RFC3264]. Also, if Bob does not understand as specified in RFC3264 [RFC3264]. Also, if B does not understand
some of the SDP attributes specified in this document, he would some of the SDP attributes specified in this document, it would
ignore them, as specified in RFC4566 [RFC4566]. ignore them, as specified in RFC4566 [RFC4566].
5. Protocol Description 5. Protocol Description
5.1. Level of Compliance 5.1. Level of Compliance
Implementations according to this specification MUST implement the Implementations according to this specification MUST implement the
SDP extensions described in Section 5.2, and MUST implement the SDP extensions described in Section 5.2, and MUST implement the
considerations discussed in Section 5.3, Section 5.4 and Section 5.6. considerations discussed in Section 5.3, Section 5.4 and Section 5.6.
skipping to change at page 9, line 43 skipping to change at page 9, line 43
The <fmt> subfield is the media format description. In the classical The <fmt> subfield is the media format description. In the classical
usage of SDP to describe RTP-based media streams, when the <proto> usage of SDP to describe RTP-based media streams, when the <proto>
subfield is set to "RTP/AVP" or "RTP/SAVP", the <fmt> subfield subfield is set to "RTP/AVP" or "RTP/SAVP", the <fmt> subfield
contains the payload types as defined in the RTP audio profile contains the payload types as defined in the RTP audio profile
[RFC3551]. [RFC3551].
When "RTP/AVP" is used in the <proto> field, the <fmt> subfield When "RTP/AVP" is used in the <proto> field, the <fmt> subfield
contains the RTP payload type numbers. We use the <fmt> subfield to contains the RTP payload type numbers. We use the <fmt> subfield to
indicate the list of available codecs over the circuit-switched indicate the list of available codecs over the circuit-switched
bearer, by re-using the conventions and payload type numbers defined bearer, by re-using the conventions and payload type numbers defined
for RTP/AVP. The RTP audio and video media types, which, when for RTP/AVP. The RTP audio and video media types, when applied to
applied to PSTN circuit-switched bearers, represent merely an audio PSTN circuit-switched bearers, represent merely an audio or video
or video codec. If the endpoint is able to determine the list of codec. If the endpoint is able to determine the list of available
available codecs for circuit-switched media streams, it MUST use the codecs for circuit-switched media streams, it MUST use the
corresponding payload type numbers in the <fmt> subfield. corresponding payload type numbers in the <fmt> subfield.
In some cases, the endpoint is not able to determine the list of In some cases, the endpoint is not able to determine the list of
available codecs for circuit-switched media streams. In this case, available codecs for circuit-switched media streams. In this case,
in order to be syntactically compliant with SDP [RFC4566], the in order to be syntactically compliant with SDP [RFC4566], the
endpoint MUST include a single dash ("-") in the <fmt> subfield. endpoint MUST include a single dash ("-") in the <fmt> subfield.
As per RFC 4566 [RFC4566], the media format descriptions are listed As per RFC 4566 [RFC4566], the media format descriptions are listed
in priority order. in priority order.
skipping to change at page 14, line 12 skipping to change at page 14, line 12
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 the value of the User-User Information Element is
Information Element is considered as an opaque string and only used considered as an opaque string and only used for correlation
for correlation purposes. Typically call signaling protocols impose purposes. Typically call signaling protocols impose requirements on
requirements on the creation of User-User Information Element for the creation of User-User Information Element for end-user protocol
end-user protocol exchange. The details regarding the generation of exchange. The details regarding the generation of the User-User
the User-User Information Element are outside the scope of this Information Element are outside the scope of this specification.
specification.
Please note that there are no guarantees that this correlation Please note that there are no guarantees 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
controlled by the PSTN circuit-switched call protocol, which might controlled by the PSTN circuit-switched call protocol, which might
not offer enough freedom for generating different values from one not offer enough freedom for generating different values from one
endpoint to another one, or from one call to another in the same endpoint to another one, or from one call to another in the same
endpoint. This might result in the same value of the User-User endpoint. This might result in the same value of the User-User
Information Element for all calls. Information Element for all calls.
5.2.3.4. DTMF Correlation Mechanism 5.2.3.4. DTMF Correlation Mechanism
We introduce a third mechanism for correlating the circuit-switched We introduce a third mechanism for correlating the circuit-switched
bearer with the session described with SDP. This is based on bearer with the session described with SDP. This is based on
agreeing on a sequence of digits that are negotiated in the SDP Offer agreeing on a sequence of digits that are negotiated in the SDP Offer
/Answer exchange and sent as Dual Tone Multifrequency (DTMF) tones /Answer exchange and sent as Dual Tone Multifrequency (DTMF) ITU-T
over the circuit-switched bearer once this bearer is established. If Recommendation Q.23 [ITU.Q23.1988] tones over the circuit-switched
the DTMF digit sequence received through the circuit-switched bearer bearer once this bearer is established. If the DTMF digit sequence
matches the digit string negotiated in the SDP, the circuit-switched received through the circuit-switched bearer matches the digit string
bearer is correlated with the session described in the SDP. The negotiated in the SDP, the circuit-switched bearer is correlated with
mechanism is similar to many voice conferencing systems which require the session described in the SDP. The mechanism is similar to many
the user to enter a PIN code using DTMF tones in order to be accepted voice conferencing systems which require the user to enter a PIN code
in a voice conference. using DTMF tones in order to be accepted in a voice conference.
The mechanism works as follows: An endpoint selects a DTMF digit The mechanism works as follows: An endpoint selects a DTMF digit
sequence. The same sequence is included in the SDP offer or SDP sequence. The same sequence is included in the SDP offer or SDP
answer, in a "dtmf" subfield of the "cs-correlation" attribute. When answer, in a "dtmf" subfield of the "cs-correlation" attribute. When
the SDP Offer/Answer exchange is completed, each endpoint has become the SDP Offer/Answer exchange is completed, each endpoint has become
aware of the DTMF sequence that will be sent right after the circuit- aware of the DTMF sequence that will be sent right after the circuit-
switched bearer is set up. The endpoint that initiates the call switched bearer is set up. The endpoint that initiates the call
setup attempt sends the DTMF digits according to the procedures setup attempt sends the DTMF digits according to the procedures
defined for the circuit-switched bearer technology used. The defined for the circuit-switched bearer technology used. The
recipient (passive side of the bearer setup) of the call setup recipient (passive side of the bearer setup) of the call setup
skipping to change at page 20, line 5 skipping to change at page 19, line 50
The <fmt> subfield carries the payload type number(s) the endpoint is The <fmt> subfield carries the payload type number(s) the endpoint is
wishing to use. Payload type numbers in this case refer to the wishing to use. Payload type numbers in this case refer to the
codecs that the endpoint wishes to use on the PSTN media stream. For codecs that the endpoint wishes to use on the PSTN media stream. For
example, if the endpoint wishes to use the GSM codec, it would add example, if the endpoint wishes to use the GSM codec, it would add
payload type number 3 in the list of codecs. The list of payload payload type number 3 in the list of codecs. The list of payload
types MUST only contain those codecs the endpoint is able to use on types MUST only contain those codecs the endpoint is able to use on
the PSTN bearer. In case the endpoint is not aware of the codecs the PSTN bearer. In case the endpoint is not aware of the codecs
available for the circuit-switched media streams, it MUST include a available for the circuit-switched media streams, it MUST include a
dash ("-") in the <fmt> subfield. dash ("-") in the <fmt> subfield.
For dynamic payload types, the endpoint MUST define the set of valid The mapping table of static payload types numbers to payload types is
encoding names and related parameters using the "a=rtpmap" attribute initally specified in [RFC3551] and maintained by IANA. For dynamic
line. See Section 6 of SDP [RFC4566] for details. payload types, the endpoint MUST define the set of valid encoding
names and related parameters using the "a=rtpmap" attribute line.
See Section 6 of SDP [RFC4566] for details.
When generating the Offer, if the Offerer supports any of the 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 Offerer MUST attribute line "a=cs-correlation" in the SDP offer. The Offerer MUST
NOT include more than one "cs-correlation" attribute per media NOT include more than one "cs-correlation" attribute per media
decription. The "a=cs-correlation" line contains an enumeration of decription. The "a=cs-correlation" line contains an enumeration of
the correlation mechanisms supported by the Offerer, in the format of the correlation mechanisms supported by the Offerer, in the format of
subfields. subfields.
The current list of subfields include "callerid", "uuie" and "dtmf" The current list of subfields include "callerid", "uuie" and "dtmf"
skipping to change at page 21, line 25 skipping to change at page 21, line 25
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 SHOULD set the value to knows its international E.164 number, it SHOULD set the value to
either '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 should not be established for the
being. time 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
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 does not support or is not willing to use
media for the session, it MUST construct an Answer where the port circuit-switched media for the session, it MUST construct an Answer
number for such media stream(s) is set to zero, according to where the port number for such media stream(s) is set to zero,
Section 6 of An Offer/Answer Model with the Session Description according to Section 6 of An Offer/Answer Model with the Session
Protocol (SDP) [RFC3264]. If the Answerer is willing to use circuit- Description Protocol (SDP) [RFC3264]. If the Answerer is willing to
switched media for the session, it MUST ignore the received port use circuit-switched media for the session, it MUST ignore the
number (unless the port number is set to zero). received port number (unless the port number is set to zero).
If the Offer included a "-" as the payload type number, it indicates If the Offer included a "-" as the payload type number, it indicates
that the Offerer is not willing or able to define any specific that the Offerer is not willing or able to define any specific
payload type. Most often, a "-" is expected to be used instead of payload type. Most often, a "-" is expected to be used instead of
the payload type when the endpoint is not aware of or not willing to the payload type when the endpoint is not aware of or not willing to
define the codecs which will eventually be used on the circuit- define the codecs which will eventually be used on the circuit-
switched bearer. The circuit-switched signaling protocols have their switched bearer. The circuit-switched signaling protocols have their
own means of negotiating or indicating the codecs, therefore an own means of negotiating or indicating the codecs, therefore an
Answerer SHOULD accept such Offers, and SHOULD set the payload type Answerer SHOULD accept such Offers, and SHOULD set the payload type
to "-" also in the Answer. to "-" also in the Answer.
skipping to change at page 22, line 38 skipping to change at page 22, line 38
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". The in the Answer and set it to value "passive" or "holdconn". The
Answerer MUST also include its E.164 number on the "c=" line. 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, or the recipient of the Offer is not willing
to establish a connection the E.164 based on a priori knowledge of
cost, or other reasons, 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 determines which
which role it would like to take. If the Offer includes an role it will take. If the Offer includes an international E.164
international E.164 number in the "c=" line, the Answerer SHOULD number in the "c=" line, the Answerer SHOULD become the active party.
become the active party. If the Offer does not include an E.164 If the Answerer does not become the active party, and if the Answerer
number, and if the Answerer is aware of its international E.164 is aware of its E.164 number, it MUST become the passive party. If
number, it MUST become the passive party. If the Offer does not the Answerer does not become the active or the passive party, 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.
For each media description where the Offer includes a "a=cs- For each media description where the Offer includes a "a=cs-
correlation" attribute, the Answerer MUST select from the Offer those correlation" attribute, the Answerer MUST select from the Offer those
correlation mechanisms it supports, and include in the Answer one "a correlation mechanisms it supports, and include in the Answer one "a
=cs-correlation" attribute line containing those mechanisms it is =cs-correlation" attribute line containing those mechanisms it is
willing to use. The Answerer MUST only add one "a=cs-correlation" willing to use. The Answerer MUST only add one "a=cs-correlation"
attribute in those media descriptions where also the Offer included a attribute in those media descriptions where also the Offer included a
"a=cs-correlation" attribute. The Answerer MUST NOT add any "a=cs-correlation" attribute. The Answerer MUST NOT add any
mechanisms which were not included in the offer. If there are more mechanisms which were not included in the offer. If there are more
than one "cs-correlation" attributes per media description in the than one "cs-correlation" attributes per media description in the
skipping to change at page 23, line 47 skipping to change at page 24, line 4
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
technology used. technology used.
If, on the other hand, the Answerer became the passive party, it If, on the other hand, the Answerer became the passive party, it
o MUST be prepared to receive a circuit-switched bearer, o MUST be prepared to receive a circuit-switched bearer,
o if the Offer contained a value for the "callerid" subfield, MUST o if the Offer contained a value for the "callerid" subfield, MUST
compare that value to the Calling Party Number Information Element compare that value to the Calling Party Number Information Element
of the circuit-switched bearer, of the circuit-switched bearer. If the received Calling Party
Number Information Element matches the value of the "callerid"
subfield, the call SHOULD be treated as correlated to the ongoing
session.
o if the Offer contained a value for the "dtmf" subfield, MUST be o if the Offer 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 Answerer MUST compare the received switched bearer is set up. The Answerer MUST 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 "cs- DTMF digits match the value of the "dtmf" subfield in the "cs-
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
skipping to change at page 25, line 38 skipping to change at page 25, line 44
correlated to the ongoing session. correlated to the ongoing session.
o If the Answer contained a value for the "uuie" subfield, the o If the Answer contained a value for the "uuie" subfield, the
Offerer MUST be prepared to receive a User-User Information Offerer MUST be prepared to receive a User-User Information
element once the circuit-switched bearer is set up. The Offerer element once the circuit-switched bearer is set up. The Offerer
SHOULD compare the received UUI to the value of the "uuie" SHOULD compare the received UUI to the value of the "uuie"
subfield. If the value of the received UUI matches the value of subfield. If the value of the received UUI matches the value of
the "uuie" subfield, the call SHOULD be treated as correlated to the "uuie" subfield, the call SHOULD be treated as correlated to
the ongoing session. the ongoing session.
According the Offer/Answer Model with SDP [RFC3264], the Offerer
needs to be ready to receive media as soon as the Offer has been
sent. It may happen that the Answerer, if it became the active
party, will initiate a circuit-switched bearer setup which will
arrive at the Offerer before the Answer has arrived. However, the
Offerer needs to receive the Answer and examine the information about
the correlation mechanisms in order to successfully perform
correlation of the circuit-switched call to the session. Therefore,
if the Offerer receives an incoming circuit-switched call, it MUST
NOT accept the call before the Answer has been received. If no
Answer is received during an implementation specific time, the
Offerer MUST either modify the session according to [RFC3264] or
terminate it according to the session signaling procedures in
question (for terminating a SIP session, see Section 15 of
[RFC3261]).
5.6.4. Modifying the session 5.6.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 If there is an existing circuit-switched bearer between the
endpoints, and the Offerer wants to reuse that, the Offerer MUST set endpoints, and the Offerer wants to reuse that, the Offerer MUST set
the value of the "a=connection" attribute to 'existing'. the value of the "a=connection" attribute to 'existing'.
skipping to change at page 27, line 25 skipping to change at page 27, line 47
6. Examples 6. Examples
In the examples below, where an SDP line is too long to be displayed In the examples below, where an SDP line is too long to be displayed
as a single line, a breaking character "\" indicates continuation in as a single line, a breaking character "\" indicates continuation in
the following line. Note that this character is included for display the following line. Note that this character is included for display
purposes only. Implementations MUST write a single line without purposes only. Implementations MUST write a single line without
breaks. breaks.
6.1. Single PSTN audio stream 6.1. Single PSTN audio stream
Alice Bob Endpoint A Endpoint B
| | | |
| (1) SDP Offer (PSTN audio) | | (1) SDP Offer (PSTN audio) |
|--------------------------------->| |--------------------------------->|
| | | |
| (2) SDP Answer (PSTN audio) | | (2) SDP Answer (PSTN audio) |
|<---------------------------------| |<---------------------------------|
| | | |
| PSTN call setup | | PSTN call setup |
|<---------------------------------| |<---------------------------------|
| | | |
|<==== media over PSTN bearer ====>| |<==== media over PSTN bearer ====>|
| | | |
Figure 3: Basic flow Figure 3: Basic flow
Figure 3 shows a basic example that describes a single audio media Figure 3 shows a basic example that describes a single audio media
stream over a circuit-switched bearer. Alice generates a SDP Offer stream over a circuit-switched bearer. Endpoint A generates a SDP
which is shown in Figure 4. The Offer describes a PSTN circuit- Offer which is shown in Figure 4. The Offer describes a PSTN
switched bearer in the "m=" and "c=" line where it also indicates its circuit-switched bearer in the "m=" and "c=" line where it also
international E.164 number format. Additionally, Alice expresses indicates its international E.164 number format. Additionally,
that she can initiate the circuit-switched bearer or be the recipient Endpoint A expresses that it can initiate the circuit-switched bearer
of it in the "a=setup" attribute line. The SDP Offer also includes or be the recipient of it in the "a=setup" attribute line. The SDP
correlation identifiers that this endpoint will insert in the Calling Offer also includes correlation identifiers that this endpoint will
Party Number and/or User-User Information Element of the PSTN call insert in the Calling Party Number and/or User-User Information
setup if eventually this endpoint initiates the PSTN call. Element of the PSTN call setup if eventually this endpoint initiates
the PSTN call.
v=0 v=0
o=alice 2890844526 2890842807 IN IP4 192.0.2.5 o=alice 2890844526 2890842807 IN IP4 192.0.2.5
s= s=
t=0 0 t=0 0
m=audio 9 PSTN - m=audio 9 PSTN -
c=PSTN E164 +441134960123 c=PSTN E164 +441134960123
a=setup:actpass a=setup:actpass
a=connection:new a=connection:new
a=cs-correlation:callerid:+441134960123 \ a=cs-correlation:callerid:+441134960123 \
uuie:56A390F3D2B7310023 uuie:56A390F3D2B7310023
Figure 4: SDP offer (1) Figure 4: SDP offer (1)
Bob generates a SDP Answer (Figure 5), describing a PSTN audio media Endpoint B generates a SDP Answer (Figure 5), describing a PSTN audio
on port 9 without information on the media sub-type on the "m=" line. media on port 9 without information on the media sub-type on the "m="
The "c=" line contains Bob's international E.164 number. In the line. The "c=" line contains B's international E.164 number. In the
"a=setup" line Bob indicates that he is willing to become the active "a=setup" line Endpoint B indicates that it is willing to become the
endpoint when establishing the PSTN call, and he also includes the "a active endpoint when establishing the PSTN call, and it also includes
=cs-correlation" attribute line containing the values he is going to the "a=cs-correlation" attribute line containing the values it is
include in the Calling Party Number and User-User IE of the PSTN call going to include in the Calling Party Number and User-User IE of the
establishment. PSTN 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 +441134960124 c=PSTN E164 +441134960124
a=setup:active a=setup:active
a=connection:new a=connection:new
a=cs-correlation:callerid:+441134960124 \ a=cs-correlation:callerid:+441134960124 \
uuie:56A390F3D2B7310023 uuie:74B9027A869D7966A2
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 Endoint A receives the Answer, it examines that B is willing to
become the active endpoint when setting up the PSTN call. Alice become the active endpoint when setting up the PSTN call. Endoint A
temporarily stores Bob's E.164 number and the User-User IE value of temporarily stores B's E.164 number and the User-User IE value of the
the "cs-correlation" attribute, and waits for a circuit-switched "cs-correlation" attribute, and waits for a circuit-switched bearer
bearer establishment. establishment.
Bob initiates a circuit-switched bearer using whatever circuit- Endpoint B initiates a circuit-switched bearer using whatever
switched technology is available for him. The called party number is circuit-switched technology is available for it. The called party
set to Alice's number, and calling party number is set to Bob's own number is set to A's number, and calling party number is set to B's
number. Bob also sets the User-User Information Element value to the own number. Endpoint B also sets the User-User Information Element
one contained in the SDP Answer. value to the one contained in the SDP Answer.
When Alice receives the circuit-switched bearer establishment, she When Endpoint A receives the circuit-switched bearer establishment,
examines the UUIE and the calling party number, and by comparing it 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
established in the IP network. As it cannot be guaranteed that the established in the IP network. As it cannot be guaranteed that the
values used for correlation are always passed intact through the values used for correlation are always passed intact through the
network, they should be treated as additional hints that the circuit- network, they should be treated as additional hints that the circuit-
switched bearer is actually related to the session. switched bearer is actually related to the session.
6.2. Advanced SDP example: Circuit-Switched Audio and Video Streams 6.2. Advanced SDP example: Circuit-Switched Audio and Video Streams
Alice Bob Endpoint A Endpoint B
| | | |
| (1) SDP Offer (PSTN audio and video) | | (1) SDP Offer (PSTN audio and video) |
|------------------------------------------->| |------------------------------------------->|
| | | |
| (2) SDP Answer (PSTN audio) | | (2) SDP Answer (PSTN audio) |
|<-------------------------------------------| |<-------------------------------------------|
| | | |
| PSTN call setup | | PSTN call setup |
|<-------------------------------------------| |<-------------------------------------------|
| | | |
|<======== media over PSTN bearer ==========>| |<======== media over PSTN bearer ==========>|
| | | |
Figure 6: Circuit-Switched Audio and Video streams Figure 6: Circuit-Switched Audio and Video streams
Figure 6 shows an example of negotiating audio and video media Figure 6 shows an example of negotiating audio and video media
streams over circuit-switched bearers. streams over circuit-switched bearers.
v=0 v=0
o=alice 2890844526 2890842807 IN IP4 192.0.2.5 o=alice 2890844526 2890842807 IN IP4 192.0.2.5
s= s=
t=0 0 t=0 0
skipping to change at page 30, line 4 skipping to change at page 30, line 26
s= s=
t=0 0 t=0 0
a=setup:actpass a=setup:actpass
a=connection:new a=connection:new
c=PSTN E164 +441134960123 c=PSTN E164 +441134960123
m=audio 9 PSTN - m=audio 9 PSTN -
a=cs-correlation:dtmf:1234536 a=cs-correlation:dtmf:1234536
m=video 9 PSTN 34 m=video 9 PSTN 34
a=rtpmap:34 H263/90000 a=rtpmap:34 H263/90000
a=cs-correlation:callerid:+441134960123 a=cs-correlation:callerid:+441134960123
Figure 7: SDP offer with circuit-switched audio and video (1) Figure 7: SDP offer with circuit-switched audio and video (1)
Upon receiving the SDP offer described in Figure 7, Bob rejects the Upon receiving the SDP offer described in Figure 7, Endpoint B
video stream as his device does not currently support video, but rejects the video stream as the device does not currently support
accepts the circuit-switched audio stream. As Alice indicated that video, but accepts the circuit-switched audio stream. As Endoint A
she is able to become either the active, or passive party, Bob gets indicated that it is able to become either the active or passive
to select which role he would like to take. Since the Offer party, Endpoint B gets to select which role it would like to take.
contained the international E.164 number of Alice, Bob decides that Since the Offer contained the international E.164 number of Endpoint
he becomes the active party in setting up the circuit-switched A, Endpoint B decides that it becomes the active party in setting up
bearer. Bob includes a new value in the "dtmf" subfield of the "cs- the circuit-switched bearer. B includes a new value in the "dtmf"
correlation" attribute, which he is going to send as DTMF tones once subfield of the "cs-correlation" attribute, which it is going to send
the bearer setup is complete. The Answer is described in Figure 8 as DTMF tones once the bearer setup is complete. The Answer is
described in Figure 8
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
a=setup:active a=setup:active
a=connection:new a=connection:new
c=PSTN E164 +441134960124 c=PSTN E164 +441134960124
m=audio 9 PSTN - m=audio 9 PSTN -
a=cs-correlation:dtmf:654321 a=cs-correlation:dtmf:654321
skipping to change at page 32, line 18 skipping to change at page 32, line 42
The IANA is requested to create a subregistry for 'cs-correlation' The IANA is requested to create a subregistry for 'cs-correlation'
attribute under the Session Description Protocol (SDP) Parameters attribute under the Session Description Protocol (SDP) Parameters
registry. The initial values for the subregistry are presented in registry. The initial values for the subregistry are presented in
the following, and IANA is requested to add them into its database: the following, and IANA is requested to add them into its database:
Value of 'cs-correlation' attribute Reference Description Value of 'cs-correlation' attribute Reference Description
----------------------------------- --------- ----------- ----------------------------------- --------- -----------
callerid RFC XXXX Caller ID callerid RFC XXXX Caller ID
uuie RFC XXXX User-User uuie RFC XXXX User-User
Information Element Information Element
dtmf RFC XXXX Dual-tone Multifrequency dtmf RFC XXXX Dual-tone
Multifrequency
Note for the RFC Editor: 'RFC XXXX' above should be replaced by a Note for the RFC Editor: 'RFC XXXX' above should be replaced by a
reference to the RFC number of this draft. reference to the RFC number of this draft.
As per the terminology in [RFC5226], the registration policy for new As per the terminology in [RFC5226], the registration policy for new
values of 'cs-correlation' parameter is 'Specification Required'. values of 'cs-correlation' parameter is 'Specification Required'.
8.2. Registration of a new "nettype" value 8.2. Registration of a new "nettype" value
This memo provides instructions to IANA to register a new "nettype" This memo provides instructions to IANA to register a new "nettype"
skipping to change at page 33, line 41 skipping to change at page 34, line 17
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, Alf Heidermark, Tom Rosenberg, Ingemar Johansson, Christer Holmberg, Alf Heidermark, Tom
Taylor, Thomas Belling, Keith Drage, and Andrew Allen for providing Taylor, Thomas Belling, Keith Drage, and Andrew Allen for providing
their insight and comments on this document. their insight and comments on this document.
10. References 10. References
10.1. Normative References 10.1. Normative References
[ITU.Q931.1998]
, "Digital Subscriber Signalling System No. 1 (DSS 1) -
ISDN User - Network Interface Layer 3 Specification for
Basic Call Control", ISO Standard 9594-1, May 1998.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264, June with Session Description Protocol (SDP)", RFC 3264, June
2002. 2002.
[RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC
3966, December 2004. 3966, December 2004.
skipping to change at page 34, line 35 skipping to change at page 35, line 14
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-10 (work in progress), April SIP", draft-ietf-cuss-sip-uui-10 (work in progress), April
2013. 2013.
[ITU.E164.1991] [ITU.E164.1991]
International Telecommunications Union, "The International International Telecommunications Union, "The International
Public Telecommunication Numbering Plan", ITU-T Public Telecommunication Numbering Plan", ITU-T
Recommendation E.164, 1991. Recommendation E.164, 1991.
[ITU.Q931.1998] [ITU.Q23.1988]
, "Digital Subscriber Signalling System No. 1 (DSS 1) - International Telecommunications Union, "Technical
ISDN User - Network Interface Layer 3 Specification for features of push-button telephone sets ", ITU-T Technical
Basic Call Control", ISO Standard 9594-1, May 1998. Recommendation Q.23, 1988.
[RFC3108] Kumar, R. and M. Mostafa, "Conventions for the use of the [RFC3108] Kumar, R. and M. Mostafa, "Conventions for the use of the
Session Description Protocol (SDP) for ATM Bearer Session Description Protocol (SDP) for ATM Bearer
Connections", RFC 3108, May 2001. Connections", RFC 3108, May 2001.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002. June 2002.
 End of changes. 41 change blocks. 
180 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/