draft-ietf-mmusic-connectivity-precon-03.txt   draft-ietf-mmusic-connectivity-precon-04.txt 
MMUSIC Working Group F. Andreasen MMUSIC Working Group F. Andreasen
Internet-Draft Cisco Systems, Inc. Internet-Draft Cisco Systems, Inc.
Intended status: Standards Track G. Camarillo Intended status: Standards Track G. Camarillo
Expires: May 22, 2008 Ericsson Expires: July 26, 2008 Ericsson
D. Oran D. Oran
D. Wing D. Wing
Cisco Systems, Inc. Cisco Systems, Inc.
November 19, 2007 January 23, 2008
Connectivity Preconditions for Session Description Protocol Media Connectivity Preconditions for Session Description Protocol Media
Streams Streams
draft-ietf-mmusic-connectivity-precon-03.txt draft-ietf-mmusic-connectivity-precon-04.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 39 skipping to change at page 1, line 39
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."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 22, 2008. This Internet-Draft will expire on July 26, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
Abstract Abstract
This document defines a new connectivity precondition for the Session This document defines a new connectivity precondition for the Session
Description Protocol (SDP) precondition framework. A connectivity Description Protocol (SDP) precondition framework. A connectivity
precondition can be used to delay session establishment or precondition can be used to delay session establishment or
modification until media stream connectivity has been successfully modification until media stream connectivity has been successfully
verified. The method of verification may vary depending on the type verified. The method of verification may vary depending on the type
of transport used for the media. For unreliable datagram transports of transport used for the media. For unreliable datagram transports
such as UDP, verification involves probing the stream with data or such as UDP, verification involves probing the stream with data or
skipping to change at page 2, line 31 skipping to change at page 2, line 31
3.4. Direction Tag . . . . . . . . . . . . . . . . . . . . . . 5 3.4. Direction Tag . . . . . . . . . . . . . . . . . . . . . . 5
3.5. Precondition Strength . . . . . . . . . . . . . . . . . . 5 3.5. Precondition Strength . . . . . . . . . . . . . . . . . . 5
4. Verifying Connectivity . . . . . . . . . . . . . . . . . . . . 6 4. Verifying Connectivity . . . . . . . . . . . . . . . . . . . . 6
4.1. Media Stream to Dialog Correlation . . . . . . . . . . . . 6 4.1. Media Stream to Dialog Correlation . . . . . . . . . . . . 6
4.2. Explicit Connectivity Verification Mechanisms . . . . . . 7 4.2. Explicit Connectivity Verification Mechanisms . . . . . . 7
4.3. Verifying Connectivity for Connection-Oriented 4.3. Verifying Connectivity for Connection-Oriented
Transports . . . . . . . . . . . . . . . . . . . . . . . . 9 Transports . . . . . . . . . . . . . . . . . . . . . . . . 9
5. Connectivity and Other Precondition Types . . . . . . . . . . 9 5. Connectivity and Other Precondition Types . . . . . . . . . . 9
6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
9. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 15 9. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 15
9.1. Changes since -02 . . . . . . . . . . . . . . . . . . . . 15 9.1. Changes since -03 . . . . . . . . . . . . . . . . . . . . 15
9.2. Changes since -01 . . . . . . . . . . . . . . . . . . . . 15 9.2. Changes since -02 . . . . . . . . . . . . . . . . . . . . 15
9.3. Changes since -01 . . . . . . . . . . . . . . . . . . . . 15
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
10.1. Normative References . . . . . . . . . . . . . . . . . . . 15 10.1. Normative References . . . . . . . . . . . . . . . . . . . 15
10.2. Informative References . . . . . . . . . . . . . . . . . . 16 10.2. Informative References . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
Intellectual Property and Copyright Statements . . . . . . . . . . 18 Intellectual Property and Copyright Statements . . . . . . . . . . 18
1. Introduction 1. Introduction
The concept of a Session Description Protocol (SDP) [RFC4566] The concept of a Session Description Protocol (SDP) [RFC4566]
precondition in the Session Initiation Protocol (SIP) [RFC3261] is precondition in the Session Initiation Protocol (SIP) [RFC3261] is
skipping to change at page 4, line 13 skipping to change at page 4, line 13
and hence we modify the grammar found in [RFC3312] as follows: and hence we modify the grammar found in [RFC3312] as follows:
precondition-type = "conn" | "qos" | token precondition-type = "conn" | "qos" | token
This precondition tag is registered with the IANA in Section 8. This precondition tag is registered with the IANA in Section 8.
3.2. Operational Semantics 3.2. Operational Semantics
According to [RFC4032], documents defining new precondition types According to [RFC4032], documents defining new precondition types
need to describe the behavior of UAs (User Agents) from the moment need to describe the behavior of UAs (User Agents) from the moment
session establishment is suspended due to a set of preconditions session establishment is suspended due to a set of preconditions,
until is resumed when these preconditions are met. An entity that until it is resumed when these preconditions are met. An entity that
wishes to delay session establishment or modification until media wishes to delay session establishment or modification until media
stream connectivity has been established uses this precondition-type stream connectivity has been established uses this precondition-type
in an offer. When a mandatory connectivity precondition is received in an offer. When a mandatory connectivity precondition is received
in an offer, session establishment or modification is delayed until in an offer, session establishment or modification is delayed until
the connectivity precondition has been met (i.e., until media stream the connectivity precondition has been met (i.e., until media stream
connectivity has been established in the desired direction or connectivity has been established in the desired direction or
directions). The delay of session establishment defined here implies directions). The delay of session establishment defined here implies
that alerting of the called party does not occur until the that alerting of the called party does not occur until the
precondition has been satisfied. precondition has been satisfied.
skipping to change at page 4, line 36 skipping to change at page 4, line 36
question. However, such packets SHOULD be limited to packets that question. However, such packets SHOULD be limited to packets that
are necessary to verify connectivity between the two endpoints are necessary to verify connectivity between the two endpoints
involved on the media stream. That is, the underlying media stream involved on the media stream. That is, the underlying media stream
SHOULD NOT be cut through. For example, STUN packets SHOULD NOT be cut through. For example, STUN packets
[I-D.ietf-behave-rfc3489bis], RTP [RFC3550] No-Op [I-D.ietf-behave-rfc3489bis], RTP [RFC3550] No-Op
[I-D.ietf-avt-rtp-no-op] packets and their corresponding RTCP [I-D.ietf-avt-rtp-no-op] packets and their corresponding RTCP
reports, as well as TCP SYN and ACK packets can be exchanged on media reports, as well as TCP SYN and ACK packets can be exchanged on media
streams that support them as a way of verifying connectivity. streams that support them as a way of verifying connectivity.
Some media streams are described by a single 'm' line but, Some media streams are described by a single 'm' line but,
nevertheless, involve multiple addresses. For example, [RFC2733] nevertheless, involve multiple addresses. For example, [RFC5109]
specifies how to send FEC (Forward Error Correction) information as a specifies how to send FEC (Forward Error Correction) information as a
separate stream (the address for the FEC stream is provided in an separate stream (the address for the FEC stream is provided in an
'a=fmtp' line). When a media stream consists of multiple destination 'a=fmtp' line). When a media stream consists of multiple destination
addresses, connectivity to all of them MUST be verified in order for addresses, connectivity to all of them MUST be verified in order for
the precondition to be met. In the case of RTP-based media streams, the precondition to be met. In the case of RTP-based media streams,
RTCP connectivity MAY be verified, but it is not a requirement. RTCP connectivity MAY be verified, but it is not a requirement.
3.3. Status Type 3.3. Status Type
[RFC3312] defines support for two kinds of status types, namely [RFC3312] defines support for two kinds of status types, namely
skipping to change at page 6, line 18 skipping to change at page 6, line 18
"Both user agents SHOULD continue using the old session parameters "Both user agents SHOULD continue using the old session parameters
until all the mandatory preconditions are met. At that moment, until all the mandatory preconditions are met. At that moment,
the user agents can begin using the new session parameters." the user agents can begin using the new session parameters."
4. Verifying Connectivity 4. Verifying Connectivity
Media stream connectivity is ascertained by use of a connectivity Media stream connectivity is ascertained by use of a connectivity
verification mechanism between the media endpoints. A connectivity verification mechanism between the media endpoints. A connectivity
verification mechanism may be an explicit mechanism, such as ICE verification mechanism may be an explicit mechanism, such as ICE
[I-D.ietf-mmusic-ice], or it may be an implicit mechanism, such as [I-D.ietf-mmusic-ice] or ICE TCP [I-D.ietf-mmusic-ice-tcp], or it may
TCP. Explicit mechanisms provide specifications for when be an implicit mechanism, such as TCP. Explicit mechanisms provide
connectivity between two endpoints using an offer/answer exchange is specifications for when connectivity between two endpoints using an
ascertained, whereas implicit mechanisms do not. The verification offer/answer exchange is ascertained, whereas implicit mechanisms do
mechanism is negotiated as part of the normal offer/answer exchange, not. The verification mechanism is negotiated as part of the normal
however it is not identified explicitly. More than one mechanism may offer/answer exchange, however it is not identified explicitly. More
be negotiated, but the offerer and answerer need not use the same. than one mechanism may be negotiated, but the offerer and answerer
The following rules guide which connectivity verification mechanism need not use the same. The following rules guide which connectivity
to use: verification mechanism to use:
1. if an explicit connectivity verification mechanism (e.g., ICE) is 1. if an explicit connectivity verification mechanism (e.g., ICE) is
negotiated, the precondition is met when the mechanism verifies negotiated, the precondition is met when the mechanism verifies
connectivity successfully, otherwise connectivity successfully, otherwise
2. if a connection-oriented transport (e.g., TCP) is negotiated, the 2. if a connection-oriented transport (e.g., TCP) is negotiated, the
precondition is met when the connection is established. precondition is met when the connection is established.
3. in other cases, an implicit verification mechanism may be 3. in other cases, an implicit verification mechanism may be
provided by the transport itself or the media stream data using provided by the transport itself or the media stream data using
the transport (e.g., RTP no-op) the transport (e.g., RTP No-Op)
4. if none of the above apply, connectivity cannot be verified 4. if none of the above apply, connectivity cannot be verified
reliably and the connectivity precondition will never be reliably and the connectivity precondition will never be
satisfied if requested. satisfied if requested.
This document does not mandate any particular connectivity This document does not mandate any particular connectivity
verification mechanism; however, in the following, we provide verification mechanism; however, in the following, we provide
additional considerations for verification mechanisms. additional considerations for verification mechanisms.
4.1. Media Stream to Dialog Correlation 4.1. Media Stream to Dialog Correlation
SIP and SDP do not provide any inherent capabilities for an incoming SIP and SDP do not provide any inherent capabilities for associating
media stream packet with a particular dialog. Thus, when an offerer an incoming media stream packet with a particular dialog. Thus, when
is trying to ascertain connectivity, and an incoming media stream an offerer is trying to ascertain connectivity, and an incoming media
packet is received, the offerer may not know which dialog had its stream packet is received, the offerer may not know which dialog had
"recv" connectivity verified. Explicit connectivity verification its "recv" connectivity verified. Explicit connectivity verification
mechanisms therefore typically provide a means to correlate the media mechanisms therefore typically provide a means to correlate the media
stream, whose connectivity is being verified, with a particular SIP stream, whose connectivity is being verified, with a particular SIP
dialog. However, some connectivity verification mechanisms may not dialog. However, some connectivity verification mechanisms may not
provide such a correlation. Therefore, in the absence of a dialog- provide such a correlation. In the absence of a dialog-to-media-
to-media-stream correlation mechanism (e.g., ICE), a UAS (User Agent stream correlation mechanism (e.g., ICE), a UAS (User Agent Server)
Server) MUST NOT require the offerer to confirm a connectivity MUST NOT require the offerer to confirm a connectivity precondition.
precondition.
4.2. Explicit Connectivity Verification Mechanisms 4.2. Explicit Connectivity Verification Mechanisms
Explicit connectivity verification mechanisms typically use probe Explicit connectivity verification mechanisms typically use probe
traffic with some sort of feedback to inform the sender whether traffic with some sort of feedback to inform the sender whether
reception was successful. Below we provide two examples of such reception was successful. Below we provide two examples of such
mechanisms, and how they are used with connectivity preconditions: mechanisms, and how they are used with connectivity preconditions:
Interactive Connectivity Establishment (ICE) [I-D.ietf-mmusic-ice] Interactive Connectivity Establishment (ICE) [I-D.ietf-mmusic-ice]
provides one or more candidate addresses in signaling between the provides one or more candidate addresses in signaling between the
offerer and the answerer and then uses STUN Binding Requests to offerer and the answerer and then uses STUN Binding Requests to
determine which pairs of candidate addresses have connectivity. Each determine which pairs of candidate addresses have connectivity. Each
STUN Binding Request contains a password which is communicated in the STUN Binding Request contains a password which is communicated in the
SDP as well; this enables correlation between STUN Binding Requests SDP as well; this enables correlation between STUN Binding Requests
and candidate addresses for a particular media stream. This and candidate addresses for a particular media stream. It also
furthermore provides correlation with a particular SIP dialog. provides correlation with a particular SIP dialog.
ICE implementations may be either Full or Lite (see [I-D.ietf-mmusic- ICE implementations may be either Full or Lite (see
ice]). Full implementations generate and respond to STUN Binding [I-D.ietf-mmusic-ice]). Full implementations generate and respond to
Requests, whereas Lite implementations only respond to them. With STUN Binding Requests, whereas Lite implementations only respond to
ICE, one side is a controlling agent, and the other side is a them. With ICE, one side is a controlling agent, and the other side
controlled agent. A Full implementation can take on either role, is a controlled agent. A Full implementation can take on either
whereas a Lite implementation can only be a controlled agent. The role, whereas a Lite implementation can only be a controlled agent.
controlling agent decides which valid candidate to use and informs The controlling agent decides which valid candidate to use and
the controlled agent of it by identifying the pair as the nominated informs the controlled agent of it by identifying the pair as the
pair. This leads to the following connectivity precondition rules: nominated pair. This leads to the following connectivity
precondition rules:
o A Full implementation ascertains both "send" and "recv" o A Full implementation ascertains both "send" and "recv"
connectivity when it operates as a STUN client and has sent a STUN connectivity when it operates as a STUN client and has sent a STUN
Binding Request that resulted in a successful check for all the Binding Request that resulted in a successful check for all the
components of the media stream (as defined further in ICE). components of the media stream (as defined further in ICE).
o A Full or a Lite implementation ascertains "recv" connectivity o A Full or a Lite implementation ascertains "recv" connectivity
when it operates as a STUN server and has received a STUN Binding when it operates as a STUN server and has received a STUN Binding
Request that resulted in a successful response for all the Request that resulted in a successful response for all the
components of the media stream (as defined further in ICE). components of the media stream (as defined further in ICE).
o A Lite implementation ascertains "send" and "recv" connectivity o A Lite implementation ascertains "send" and "recv" connectivity
when the controlling agent has informed it of the nominated pair when the controlling agent has informed it of the nominated pair
for all the components of the media stream. for all the components of the media stream.
A simpler and slightly more delay-prone alternative to the above A simpler and slightly more delay-prone alternative to the above
rules is for all ICE implementations to ascertain "send" and "recv" rules is for all ICE implementations to ascertain "send" and "recv"
connectivity for a media stream when the ICE state for that media connectivity for a media stream when the ICE state for that media
stream has moved to Completed. stream has moved to Completed.
Note that there is never a need for the UAS to request confirmation Note that there is never a need for the answerer to request
of the connectivity precondition when using ICE: the answerer can confirmation of the connectivity precondition when using ICE: the
determine the status locally. Also note, that when ICE is used to answerer can determine the status locally. Also note, that when ICE
verify connectivity preconditions, the precondition is not satisfied is used to verify connectivity preconditions, the precondition is not
until connectivity has been verified for all the component transport satisfied until connectivity has been verified for all the component
addresses used by the media stream. For example, with an RTP-based transport addresses used by the media stream. For example, with an
media stream where RTCP is not suppressed, connectivity MUST be RTP-based media stream where RTCP is not suppressed, connectivity
ascertained for both RTP and RTCP; this is a tightening of the MUST be ascertained for both RTP and RTCP; this is a tightening of
general operational semantics provided in Section Section 3.2, which the general operational semantics provided in Section 3.2, which is
is imposed by ICE. Finally, it should be noted, that although imposed by ICE. Finally, it should be noted, that although
connectivity has been ascertained, a new offer/answer exchange may be connectivity has been ascertained, a new offer/answer exchange may be
required before media can flow (per ICE). required before media can flow (per ICE).
RTP no-op [I-D.ietf-avt-rtp-no-op] enables the sender of an RTP No-Op RTP No-Op [I-D.ietf-avt-rtp-no-op] enables the sender of an RTP No-Op
payload to verify send connectivity by examining the RTCP report(s) payload to verify send connectivity by examining the RTCP report(s)
being returned. In particular, the source SSRC in the RTCP report being returned. In particular, the source SSRC in the RTCP report
block is used for correlation. The RTCP report block also contains block is used for correlation. The RTCP report block also contains
the SSRC of the sender of the report and the SSRC of incoming RTP the SSRC of the sender of the report and the SSRC of incoming RTP
No-Op packets identifies the sender of the RTP packet. Thus, once No-Op packets identifies the sender of the RTP packet. Thus, once
send connectivity has been ascertained, receipt of an RTP No-Op send connectivity has been ascertained, receipt of an RTP No-Op
packet from the same SSRC provides the necessary correlation to packet from the same SSRC provides the necessary correlation to
determine receive connectivity. Alternatively, the duality of send determine receive connectivity. Alternatively, the duality of send
and receive preconditions can be exploited, with one side confirming and receive preconditions can be exploited, with one side confirming
when his send precondition is satisfied, which in turn implies the when his send precondition is satisfied, which in turn implies the
skipping to change at page 9, line 10 skipping to change at page 9, line 10
Furthermore, the ICE recommendation provides a baseline to ensure Furthermore, the ICE recommendation provides a baseline to ensure
that all entities that require probe traffic to support the that all entities that require probe traffic to support the
connectivity preconditions have a common way of ascertaining connectivity preconditions have a common way of ascertaining
connectivity. connectivity.
4.3. Verifying Connectivity for Connection-Oriented Transports 4.3. Verifying Connectivity for Connection-Oriented Transports
Connection-oriented transport protocols generally provide an implicit Connection-oriented transport protocols generally provide an implicit
connectivity verification mechanism. Connection establishment connectivity verification mechanism. Connection establishment
involves sending traffic in both directions thereby verifying involves sending traffic in both directions thereby verifying
connectivity at the transport protocol level. When the connection- connectivity at the transport protocol level. When a three-way (or
oriented protocol uses a three-way (or more) handshake for connection more) handshake for connection establishment succeeds, bi-directional
establishment, there is no difference between the "send" and "recv" communication is confirmed and both the "send" and "recv"
precondition. In the case of TCP for example, once the TCP three-way preconditions are satisfied whether requested or not. In the case of
handshake has completed (SYN, SYN-ACK, ACK), the TCP connection is TCP for example, once the TCP three-way handshake has completed (SYN,
established and data can be sent and received by either party (i.e., SYN-ACK, ACK), the TCP connection is established and data can be sent
both a send and a receive connectivity precondition has been and received by either party (i.e., both a send and a receive
satisfied). SCTP [RFC4960] connections have similar semantics as TCP connectivity precondition has been satisfied). SCTP [RFC4960]
and SHOULD be treated the same. connections have similar semantics as TCP and SHOULD be treated the
same.
When a connection-oriented transport is part of an offer, it may be When a connection-oriented transport is part of an offer, it may be
passive, active, or active/passive [RFC4145]. When it is passive, passive, active, or active/passive [RFC4145]. When it is passive,
the offerer expects the answerer to initiate the connection the offerer expects the answerer to initiate the connection
establishment, and when it is active, the offerer wants to initiate establishment, and when it is active, the offerer wants to initiate
the connection establishment. When it is active/passive, the the connection establishment. When it is active/passive, the
answerer decides. As noted earlier, lack of a media-stream-to-dialog answerer decides. As noted earlier, lack of a media-stream-to-dialog
correlation mechanism can make it difficult to guarantee with whom correlation mechanism can make it difficult to guarantee with whom
connectivity has been ascertained. When the offerer takes on the connectivity has been ascertained. When the offerer takes on the
passive role, the offerer will not necessarily know which SIP dialog passive role, the offerer will not necessarily know which SIP dialog
originated an incoming connection request. If the offerer instead is originated an incoming connection request. If the offerer instead is
active, this problem is avoided. active, this problem is avoided.
5. Connectivity and Other Precondition Types 5. Connectivity and Other Precondition Types
The role of a connectivity precondition is to ascertain media stream The role of a connectivity precondition is to ascertain media stream
connectivity before establishing or modifying a session. The connectivity before establishing or modifying a session. The
underlying intent is for the two parties to be able to exchange media underlying intent is for the two parties to be able to exchange media
packets successfully. Connectivity by itself however may not fully packets successfully. Connectivity by itself however may not fully
satisfy this. Quality of Service for example may be required for the satisfy this. Quality of Service for example may be required for the
media stream; this can be addressed by use of the "qos" preconditions media stream; this can be addressed by use of the "qos" precondition
defined in [RFC3312]. Similarly, succesful security parameter defined in [RFC3312]. Similarly, succesful security parameter
negotiation may be another prequisite to meeting this; this can be negotiation may be another prequisite; this can be addressed by use
addressed by use of the "sec" preconditions defined in [RFC5027]. of the "sec" precondition defined in [RFC5027].
6. Examples 6. Examples
The first example uses the connectivity precondition with TCP in the The first example uses the connectivity precondition with TCP in the
context of a session involving a wireless access medium. Both UAs context of a session involving a wireless access medium. Both UAs
use a radio access network that does not allow them to send any data use a radio access network that does not allow them to send any data
(not even a TCP SYN) until a radio bearer has been setup for the (not even a TCP SYN) until a radio bearer has been setup for the
connection. Figure 1 shows the message flow of this example (the connection. Figure 1 shows the message flow of this example (the
PRACK transaction has been omitted for clarity): required PRACK transaction has been omitted for clarity):
A B A B
| INVITE | | INVITE |
| a=curr:conn e2e none | | a=curr:conn e2e none |
| a=des:conn mandatory e2e sendrecv | | a=des:conn mandatory e2e sendrecv |
| a=setup:holdconn | | a=setup:holdconn |
|----------------------------------->| |----------------------------------->|
| | | |
| 183 Session Progress | | 183 Session Progress |
| a=curr:conn e2e none | | a=curr:conn e2e none |
skipping to change at page 11, line 17 skipping to change at page 11, line 18
When A's radio bearer is ready, A sends an UPDATE to B with a setup When A's radio bearer is ready, A sends an UPDATE to B with a setup
attribute with a value of actpass. This attribute indicates that A attribute with a value of actpass. This attribute indicates that A
can perform an active or a passive TCP open. A is letting B choose can perform an active or a passive TCP open. A is letting B choose
which endpoint will initiate the connection. which endpoint will initiate the connection.
Since B's radio bearer is not ready yet, B chooses to be the one Since B's radio bearer is not ready yet, B chooses to be the one
initiating the connection and indicates so with a setup attribute initiating the connection and indicates so with a setup attribute
with a value of active. At a later point, when B's radio bearer is with a value of active. At a later point, when B's radio bearer is
ready, B initiates the TCP connection towards A. ready, B initiates the TCP connection towards A.
Once the TCP connection is established successfully, B alerts the Once the TCP connection is established successfully, B knows the
callee and sends a 180 (Ringing) response. "sendrecv" precondition is satisfied, and B proceeds with the session
(i.e., alerts the Callee), and sends a 180 (Ringing) response.
The second example shows a basic SIP session establishment using SDP The second example shows a basic SIP session establishment using SDP
connectivity preconditions and RTP No-Op. Note that not all SDP connectivity preconditions and RTP No-Op (the required PRACK
details are provided in the following. The message flow for this transaction and some SDP details have been omitted for clarity). The
scenario is shown in Figure 2 below. message flow for this scenario is shown in Figure 2 below.
A B A B
| | | |
|-------------(1) INVITE SDP1--------------->| |-------------(1) INVITE SDP1--------------->|
| | | |
|<------(2) 183 Session Progress SDP2--------| |<------(2) 183 Session Progress SDP2--------|
| | | |
|<~~~~~ Connectivity check to A ~~~~~~~~~~~~~| |<~~~~~ Connectivity check to A ~~~~~~~~~~~~~|
| |
|----------------(3) PRACK------------------>|
| |
|~~~~~ Connectivity to A OK ~~~~~~~~~~~~~~~~>| |~~~~~ Connectivity to A OK ~~~~~~~~~~~~~~~~>|
| | | |
|<-----------(4) 200 OK (PRACK)--------------|
| |
|~~~~~ Connectivity check to B ~~~~~~~~~~~~~>| |~~~~~ Connectivity check to B ~~~~~~~~~~~~~>|
|<~~~~ Connectivity to B OK ~~~~~~~~~~~~~~~~~| |<~~~~ Connectivity to B OK ~~~~~~~~~~~~~~~~~|
| | | |
|-------------(5) UPDATE SDP3--------------->| |-------------(3) UPDATE SDP3--------------->|
| |
|<--------(6) 200 OK (UPDATE) SDP4-----------|
| | | |
|<-------------(7) 180 Ringing---------------| |<--------(4) 200 OK (UPDATE) SDP4-----------|
| | | |
|<-------------(5) 180 Ringing---------------|
| | | |
| | | |
Figure 2: Connectivity precondition with RTP no-op Figure 2: Connectivity precondition with RTP No-Op
SDP1: A includes a mandatory end-to-end connectivity precondition SDP1: A includes a mandatory end-to-end connectivity precondition
with a desired status of "sendrecv"; this will ensure media stream with a desired status of "sendrecv"; this will ensure media stream
connectivity in both directions before continuing with the session connectivity in both directions before continuing with the session
setup. Since media stream connectivity in either direction is setup. Since media stream connectivity in either direction is
unknown at this point, the current status is set to "none". A's unknown at this point, the current status is set to "none". A's
local status table (see [RFC3312]) for the connectivity precondition local status table (see [RFC3312]) for the connectivity precondition
is as follows: is as follows:
Direction | Current | Desired Strength | Confirm Direction | Current | Desired Strength | Confirm
skipping to change at page 13, line 33 skipping to change at page 13, line 24
point of view) connectivity precondition, the resulting answer SDP point of view) connectivity precondition, the resulting answer SDP
becomes: becomes:
m=audio 30000 RTP/AVP 0 96 m=audio 30000 RTP/AVP 0 96
a=rtpmap:96 no-op/8000 a=rtpmap:96 no-op/8000
c=IN IP4 192.0.2.4 c=IN IP4 192.0.2.4
a=curr:conn e2e none a=curr:conn e2e none
a=des:conn mandatory e2e sendrecv a=des:conn mandatory e2e sendrecv
a=conf:conn e2e recv a=conf:conn e2e recv
Meanwhile, B performs a connectivity check to A, which succeeds and Meanwhile, B performs a successful send connectivity check to A by
hence B's local status table is updated as follows: sending an RTP No-Op packet to A and receiving a corresponding RTCP
report. B's local status table is updated as follows:
Direction | Current | Desired Strength | Confirm Direction | Current | Desired Strength | Confirm
-----------+----------+------------------+---------- -----------+----------+------------------+----------
send | yes | mandatory | no send | yes | mandatory | no
recv | no | mandatory | no recv | no | mandatory | no
Since the "recv" connectivity precondition (from B's point of view) Since the "recv" connectivity precondition (from B's point of view)
is still not satisfied, session establishment remains suspended. is still not satisfied, session establishment remains suspended.
SDP3: When A receives the answer SDP, A notes that confirmation was SDP3: When A receives the answer SDP, A notes that confirmation was
requested for B's "recv" connectivity precondition, which is the requested for B's "recv" connectivity precondition, which is the
"send" precondition from A's point of view. A performs a "send" precondition from A's point of view. A performs a successful
connectivity check to B, which succeeds, and A's local status table send connectivity check to B by sending an RTP No-Op packet to B and
receiving a corresponding RTCP report, and A's local status table
becomes: becomes:
Direction | Current | Desired Strength | Confirm Direction | Current | Desired Strength | Confirm
-----------+----------+------------------+---------- -----------+----------+------------------+----------
send | yes | mandatory | yes send | yes | mandatory | yes
recv | no | mandatory | no recv | no | mandatory | no
Since B asked for confirmation about the "send" connectivity (from Since B asked for confirmation about the "send" connectivity (from
A's point of view), A now sends an UPDATE (5) to B to confirm the A's point of view), A now sends an UPDATE (5) to B to confirm the
connectivity from A to B: connectivity from A to B:
m=audio 20000 RTP/AVP 0 96 m=audio 20000 RTP/AVP 0 96
a=rtpmap:96 no-op/8000 a=rtpmap:96 no-op/8000
c=IN IP4 192.0.2.1 c=IN IP4 192.0.2.1
a=curr:conn e2e send a=curr:conn e2e send
a=des:conn mandatory e2e sendrecv a=des:conn mandatory e2e sendrecv
B has both send and recv connectivity confirmed at this point and the
session can continue.
7. Security Considerations 7. Security Considerations
In addition to the general security considerations for preconditions In addition to the general security considerations for preconditions
provided in [RFC3312], the following security issues, which are provided in [RFC3312], the following security issues, which are
specific to connectivity preconditions, should be considered. specific to connectivity preconditions, should be considered.
Connectivity preconditions rely on mechanisms beyond SDP such as Connectivity preconditions rely on mechanisms beyond SDP such as
TCP[RFC0793] connection establishment, RTP No-Op TCP[RFC0793] connection establishment, RTP No-Op
[I-D.ietf-avt-rtp-no-op], or STUN [I-D.ietf-behave-rfc3489bis] to [I-D.ietf-avt-rtp-no-op], or STUN [I-D.ietf-behave-rfc3489bis] to
establish and verify connectivity between an offerer and an answerer. establish and verify connectivity between an offerer and an answerer.
skipping to change at page 14, line 42 skipping to change at page 14, line 45
that such mechanisms are adequately secured by message authentication that such mechanisms are adequately secured by message authentication
and integrity protection. Also, the mechanisms SHOULD consider how and integrity protection. Also, the mechanisms SHOULD consider how
to prevent denial of service attacks. Similarly, an attacker that to prevent denial of service attacks. Similarly, an attacker that
can forge packets for these mechanisms can enable sessions to be can forge packets for these mechanisms can enable sessions to be
established when there in fact is no media connectivity, which may established when there in fact is no media connectivity, which may
lead to a poor user experience. Authentication and integrity lead to a poor user experience. Authentication and integrity
protection of such mechanisms can prevent this type of attacks and protection of such mechanisms can prevent this type of attacks and
hence use of it is RECOMMENDED. hence use of it is RECOMMENDED.
It is also strongly RECOMMENDED that integrity protection be applied It is also strongly RECOMMENDED that integrity protection be applied
to the SDP session descriptions. S/MIME [RFC3853] is the natural to the SDP session descriptions. S/MIME [RFC3853] provides such end-
choice to provide such end-to-end integrity protection, as described to-end integrity protection, as described in [RFC3261].
in [RFC3261].
8. IANA Considerations 8. IANA Considerations
IANA is hereby requested to register a new precondition type under IANA is hereby requested to register a new precondition type under
the Precondition Types used with SIP subregistry, which is located the Precondition Types used with SIP subregistry, which is located
under the Session Initiation Protocol (SIP) Parameters registry. under the Session Initiation Protocol (SIP) Parameters registry.
Precondition-Type Description Reference Precondition-Type Description Reference
----------------- ----------------------------------- --------- ----------------- ----------------------------------- ---------
conn Connectivity precondition [RFCxxxx] conn Connectivity precondition [RFCxxxx]
[Note to the RFC Editor: replace RFCxxxx with the number assigned to [Note to the RFC Editor: replace RFCxxxx with the number assigned to
this RFC.] this RFC.]
9. Change Log 9. Change Log
9.1. Changes since -02 9.1. Changes since -03
Minor fixes here and there.
9.2. Changes since -02
Connectivity preconditions are now mechanism agnostic. Clarified Connectivity preconditions are now mechanism agnostic. Clarified
when and how to use ICE, RTP no-op, and connection establishment when and how to use ICE, RTP No-Op, and connection establishment
procedures to check connectivity. Clarified relation with other procedures to check connectivity. Clarified relation with other
precondition types. precondition types.
9.2. Changes since -01 9.3. Changes since -01
There are no changes since the previous version of the document. There are no changes since the previous version of the 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.
[RFC2733] Rosenberg, J. and H. Schulzrinne, "An RTP Payload Format [RFC5109] Li, A., "RTP Payload Format for Generic Forward Error
for Generic Forward Error Correction", RFC 2733, Correction", RFC 5109, December 2007.
December 1999.
[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.
[RFC3312] Camarillo, G., Marshall, W., and J. Rosenberg, [RFC3312] Camarillo, G., Marshall, W., and J. Rosenberg,
"Integration of Resource Management and Session Initiation "Integration of Resource Management and Session Initiation
Protocol (SIP)", RFC 3312, October 2002. Protocol (SIP)", RFC 3312, October 2002.
skipping to change at page 16, line 40 skipping to change at page 16, line 48
RFC 5027, October 2007. RFC 5027, October 2007.
[I-D.ietf-avt-rtp-no-op] [I-D.ietf-avt-rtp-no-op]
Andreasen, F., "A No-Op Payload Format for RTP", Andreasen, F., "A No-Op Payload Format for RTP",
draft-ietf-avt-rtp-no-op-04 (work in progress), May 2007. draft-ietf-avt-rtp-no-op-04 (work in progress), May 2007.
[I-D.ietf-mmusic-ice] [I-D.ietf-mmusic-ice]
Rosenberg, J., "Interactive Connectivity Establishment Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT) (ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols", Traversal for Offer/Answer Protocols",
draft-ietf-mmusic-ice-19 (work in progress), October 2007. draft-ietf-mmusic-ice-16 (work in progress), June 2007.
[I-D.ietf-mmusic-ice-tcp] [I-D.ietf-mmusic-ice-tcp]
Rosenberg, J., "TCP Candidates with Interactive Rosenberg, J., "TCP Candidates with Interactive
Connectivity Establishment (ICE", Connectivity Establishment (ICE",
draft-ietf-mmusic-ice-tcp-04 (work in progress), draft-ietf-mmusic-ice-tcp-03 (work in progress),
July 2007. March 2007.
[I-D.ietf-behave-rfc3489bis] [I-D.ietf-behave-rfc3489bis]
Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, Rosenberg, J., "Session Traversal Utilities for (NAT)
"Session Traversal Utilities for (NAT) (STUN)", (STUN)", draft-ietf-behave-rfc3489bis-06 (work in
draft-ietf-behave-rfc3489bis-13 (work in progress), progress), March 2007.
November 2007.
Authors' Addresses Authors' Addresses
Flemming Andreasen Flemming Andreasen
Cisco Systems, Inc. Cisco Systems, Inc.
499 Thornall Street, 8th Floor 499 Thornall Street, 8th Floor
Edison, NJ 08837 Edison, NJ 08837
USA USA
Email: fandreas@cisco.com Email: fandreas@cisco.com
skipping to change at page 18, line 7 skipping to change at page 18, line 7
Dan Wing Dan Wing
Cisco Systems, Inc. Cisco Systems, Inc.
170 West Tasman Drive 170 West Tasman Drive
San Jose, CA 94301 San Jose, CA 94301
USA USA
Email: dwing@cisco.com Email: dwing@cisco.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
 End of changes. 41 change blocks. 
101 lines changed or deleted 104 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/