idnits 2.17.1 draft-ietf-mmusic-connectivity-precon-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 20. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 757. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 768. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 775. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 781. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Line 449 has weird spacing: '...ypes of preco...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 23, 2008) is 5937 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFCxxxx' is mentioned on line 616, but not defined ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 4960 (Obsoleted by RFC 9260) == Outdated reference: A later version (-19) exists of draft-ietf-mmusic-ice-16 == Outdated reference: A later version (-16) exists of draft-ietf-mmusic-ice-tcp-03 == Outdated reference: A later version (-18) exists of draft-ietf-behave-rfc3489bis-06 Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MMUSIC Working Group F. Andreasen 3 Internet-Draft Cisco Systems, Inc. 4 Intended status: Standards Track G. Camarillo 5 Expires: July 26, 2008 Ericsson 6 D. Oran 7 D. Wing 8 Cisco Systems, Inc. 9 January 23, 2008 11 Connectivity Preconditions for Session Description Protocol Media 12 Streams 13 draft-ietf-mmusic-connectivity-precon-04.txt 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on July 26, 2008. 40 Copyright Notice 42 Copyright (C) The IETF Trust (2008). 44 Abstract 46 This document defines a new connectivity precondition for the Session 47 Description Protocol (SDP) precondition framework. A connectivity 48 precondition can be used to delay session establishment or 49 modification until media stream connectivity has been successfully 50 verified. The method of verification may vary depending on the type 51 of transport used for the media. For unreliable datagram transports 52 such as UDP, verification involves probing the stream with data or 53 control packets. For reliable connection-oriented transports such as 54 TCP, verification can be achieved simply by successful connection 55 establishment or by probing the connection with data or control 56 packets, depending on the situation. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 3. Connectivity Precondition Definition . . . . . . . . . . . . . 3 63 3.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 3.2. Operational Semantics . . . . . . . . . . . . . . . . . . 4 65 3.3. Status Type . . . . . . . . . . . . . . . . . . . . . . . 4 66 3.4. Direction Tag . . . . . . . . . . . . . . . . . . . . . . 5 67 3.5. Precondition Strength . . . . . . . . . . . . . . . . . . 5 68 4. Verifying Connectivity . . . . . . . . . . . . . . . . . . . . 6 69 4.1. Media Stream to Dialog Correlation . . . . . . . . . . . . 6 70 4.2. Explicit Connectivity Verification Mechanisms . . . . . . 7 71 4.3. Verifying Connectivity for Connection-Oriented 72 Transports . . . . . . . . . . . . . . . . . . . . . . . . 9 73 5. Connectivity and Other Precondition Types . . . . . . . . . . 9 74 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 75 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 76 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 77 9. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 15 78 9.1. Changes since -03 . . . . . . . . . . . . . . . . . . . . 15 79 9.2. Changes since -02 . . . . . . . . . . . . . . . . . . . . 15 80 9.3. Changes since -01 . . . . . . . . . . . . . . . . . . . . 15 81 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 82 10.1. Normative References . . . . . . . . . . . . . . . . . . . 15 83 10.2. Informative References . . . . . . . . . . . . . . . . . . 16 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 85 Intellectual Property and Copyright Statements . . . . . . . . . . 18 87 1. Introduction 89 The concept of a Session Description Protocol (SDP) [RFC4566] 90 precondition in the Session Initiation Protocol (SIP) [RFC3261] is 91 defined in [RFC3312] (updated by [RFC4032]). A precondition is a 92 condition that has to be satisfied for a given media stream in order 93 for session establishment or modification to proceed. When the 94 precondition is not met, session progress is delayed until the 95 precondition is satisfied or the session establishment fails. For 96 example, [RFC3312] defines the Quality of Service precondition, which 97 is used to ensure availability of network resources prior to 98 establishing a session (i.e., prior to starting alerting the callee). 100 SIP sessions are typically established in order to setup one or more 101 media streams. Even though a media stream may be negotiated 102 successfully through an SDP offer-answer exchange, the actual media 103 stream itself may fail. For example, when there is one or more 104 Network Address Translators (NATs) or firewalls in the media path, 105 the media stream may not be received by the far end. In cases where 106 the media is carried over a connection-oriented transport such as TCP 107 [RFC0793], the connection-establishment procedures may fail. The 108 connectivity precondition defined in this document ensures that 109 session progress is delayed until media stream connectivity has been 110 verified. 112 The connectivity precondition type defined in this document follows 113 the guidelines provided in [RFC4032] to extend the SIP preconditions 114 framework. 116 2. Terminology 118 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 119 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 120 document are to be interpreted as described in [RFC2119]. 122 3. Connectivity Precondition Definition 124 3.1. Syntax 126 The connectivity precondition type is defined by the string "conn" 127 and hence we modify the grammar found in [RFC3312] as follows: 129 precondition-type = "conn" | "qos" | token 131 This precondition tag is registered with the IANA in Section 8. 133 3.2. Operational Semantics 135 According to [RFC4032], documents defining new precondition types 136 need to describe the behavior of UAs (User Agents) from the moment 137 session establishment is suspended due to a set of preconditions, 138 until it is resumed when these preconditions are met. An entity that 139 wishes to delay session establishment or modification until media 140 stream connectivity has been established uses this precondition-type 141 in an offer. When a mandatory connectivity precondition is received 142 in an offer, session establishment or modification is delayed until 143 the connectivity precondition has been met (i.e., until media stream 144 connectivity has been established in the desired direction or 145 directions). The delay of session establishment defined here implies 146 that alerting of the called party does not occur until the 147 precondition has been satisfied. 149 Packets may be both sent and received on the media streams in 150 question. However, such packets SHOULD be limited to packets that 151 are necessary to verify connectivity between the two endpoints 152 involved on the media stream. That is, the underlying media stream 153 SHOULD NOT be cut through. For example, STUN packets 154 [I-D.ietf-behave-rfc3489bis], RTP [RFC3550] No-Op 155 [I-D.ietf-avt-rtp-no-op] packets and their corresponding RTCP 156 reports, as well as TCP SYN and ACK packets can be exchanged on media 157 streams that support them as a way of verifying connectivity. 159 Some media streams are described by a single 'm' line but, 160 nevertheless, involve multiple addresses. For example, [RFC5109] 161 specifies how to send FEC (Forward Error Correction) information as a 162 separate stream (the address for the FEC stream is provided in an 163 'a=fmtp' line). When a media stream consists of multiple destination 164 addresses, connectivity to all of them MUST be verified in order for 165 the precondition to be met. In the case of RTP-based media streams, 166 RTCP connectivity MAY be verified, but it is not a requirement. 168 3.3. Status Type 170 [RFC3312] defines support for two kinds of status types, namely 171 segmented and end-to-end. The connectivity precondition-type defined 172 here MUST be used with the end-to-end status type; use of the 173 segmented status type is undefined. 175 3.4. Direction Tag 177 The direction attributes defined in [RFC3312] are interpreted as 178 follows: 180 o send: the party that generated the session description is sending 181 packets on the media stream to the other party, and the other 182 party has received at least one of those packets. That is, there 183 is connectivity in the forward (sending) direction. 185 o recv: the other party is sending packets on the media stream to 186 the party that generated the session description, and this party 187 has received at least one of those packets. That is, there is 188 connectivity in the backwards (receiving) direction. 190 o sendrecv: both the send and recv conditions hold. 192 Note that a "send" connectivity precondition from the offerer's point 193 of view corresponds to a "recv" connectivity precondition from the 194 answerer's point of view, and vice versa. If media stream 195 connectivity in both directions is required before session 196 establishment or modification continues, the desired status needs to 197 be set to "sendrecv". 199 3.5. Precondition Strength 201 Connectivity preconditions may have a strength-tag of either 202 "mandatory" or "optional". 204 When a mandatory connectivity precondition is offered and the 205 answerer cannot satisfy the connectivity precondition (e.g., because 206 the offer does not include parameters that enable connectivity to be 207 verified without media cut through) the offer MUST be rejected as 208 described in [RFC3312]. 210 When an optional connectivity precondition is offered, the answerer 211 MUST generate its answer SDP as soon as possible. Since session 212 progress is not delayed in this case, it is not known whether the 213 associated media streams will have connectivity. If the answerer 214 wants to delay session progress until connectivity has been verified, 215 the answerer MUST increase the strength of the connectivity 216 precondition by using a strength-tag of "mandatory" in the answer. 218 Note that use of a "mandatory" precondition requires the presence of 219 a SIP "Require" header with the option tag "precondition". Any SIP 220 UA that does not support a mandatory precondition will reject such 221 requests. To get around this issue, an optional connectivity 222 precondition and the SIP "Supported" header with the option tag 223 "precondition" can be used instead. 225 Offers with connectivity preconditions in re-INVITEs or UPDATEs 226 follow the rules given in Section 6 of [RFC3312]. That is: 228 "Both user agents SHOULD continue using the old session parameters 229 until all the mandatory preconditions are met. At that moment, 230 the user agents can begin using the new session parameters." 232 4. Verifying Connectivity 234 Media stream connectivity is ascertained by use of a connectivity 235 verification mechanism between the media endpoints. A connectivity 236 verification mechanism may be an explicit mechanism, such as ICE 237 [I-D.ietf-mmusic-ice] or ICE TCP [I-D.ietf-mmusic-ice-tcp], or it may 238 be an implicit mechanism, such as TCP. Explicit mechanisms provide 239 specifications for when connectivity between two endpoints using an 240 offer/answer exchange is ascertained, whereas implicit mechanisms do 241 not. The verification mechanism is negotiated as part of the normal 242 offer/answer exchange, however it is not identified explicitly. More 243 than one mechanism may be negotiated, but the offerer and answerer 244 need not use the same. The following rules guide which connectivity 245 verification mechanism to use: 247 1. if an explicit connectivity verification mechanism (e.g., ICE) is 248 negotiated, the precondition is met when the mechanism verifies 249 connectivity successfully, otherwise 251 2. if a connection-oriented transport (e.g., TCP) is negotiated, the 252 precondition is met when the connection is established. 254 3. in other cases, an implicit verification mechanism may be 255 provided by the transport itself or the media stream data using 256 the transport (e.g., RTP No-Op) 258 4. if none of the above apply, connectivity cannot be verified 259 reliably and the connectivity precondition will never be 260 satisfied if requested. 262 This document does not mandate any particular connectivity 263 verification mechanism; however, in the following, we provide 264 additional considerations for verification mechanisms. 266 4.1. Media Stream to Dialog Correlation 268 SIP and SDP do not provide any inherent capabilities for associating 269 an incoming media stream packet with a particular dialog. Thus, when 270 an offerer is trying to ascertain connectivity, and an incoming media 271 stream packet is received, the offerer may not know which dialog had 272 its "recv" connectivity verified. Explicit connectivity verification 273 mechanisms therefore typically provide a means to correlate the media 274 stream, whose connectivity is being verified, with a particular SIP 275 dialog. However, some connectivity verification mechanisms may not 276 provide such a correlation. In the absence of a dialog-to-media- 277 stream correlation mechanism (e.g., ICE), a UAS (User Agent Server) 278 MUST NOT require the offerer to confirm a connectivity precondition. 280 4.2. Explicit Connectivity Verification Mechanisms 282 Explicit connectivity verification mechanisms typically use probe 283 traffic with some sort of feedback to inform the sender whether 284 reception was successful. Below we provide two examples of such 285 mechanisms, and how they are used with connectivity preconditions: 287 Interactive Connectivity Establishment (ICE) [I-D.ietf-mmusic-ice] 288 provides one or more candidate addresses in signaling between the 289 offerer and the answerer and then uses STUN Binding Requests to 290 determine which pairs of candidate addresses have connectivity. Each 291 STUN Binding Request contains a password which is communicated in the 292 SDP as well; this enables correlation between STUN Binding Requests 293 and candidate addresses for a particular media stream. It also 294 provides correlation with a particular SIP dialog. 296 ICE implementations may be either Full or Lite (see 297 [I-D.ietf-mmusic-ice]). Full implementations generate and respond to 298 STUN Binding Requests, whereas Lite implementations only respond to 299 them. With ICE, one side is a controlling agent, and the other side 300 is a controlled agent. A Full implementation can take on either 301 role, whereas a Lite implementation can only be a controlled agent. 302 The controlling agent decides which valid candidate to use and 303 informs the controlled agent of it by identifying the pair as the 304 nominated pair. This leads to the following connectivity 305 precondition rules: 307 o A Full implementation ascertains both "send" and "recv" 308 connectivity when it operates as a STUN client and has sent a STUN 309 Binding Request that resulted in a successful check for all the 310 components of the media stream (as defined further in ICE). 312 o A Full or a Lite implementation ascertains "recv" connectivity 313 when it operates as a STUN server and has received a STUN Binding 314 Request that resulted in a successful response for all the 315 components of the media stream (as defined further in ICE). 317 o A Lite implementation ascertains "send" and "recv" connectivity 318 when the controlling agent has informed it of the nominated pair 319 for all the components of the media stream. 321 A simpler and slightly more delay-prone alternative to the above 322 rules is for all ICE implementations to ascertain "send" and "recv" 323 connectivity for a media stream when the ICE state for that media 324 stream has moved to Completed. 326 Note that there is never a need for the answerer to request 327 confirmation of the connectivity precondition when using ICE: the 328 answerer can determine the status locally. Also note, that when ICE 329 is used to verify connectivity preconditions, the precondition is not 330 satisfied until connectivity has been verified for all the component 331 transport addresses used by the media stream. For example, with an 332 RTP-based media stream where RTCP is not suppressed, connectivity 333 MUST be ascertained for both RTP and RTCP; this is a tightening of 334 the general operational semantics provided in Section 3.2, which is 335 imposed by ICE. Finally, it should be noted, that although 336 connectivity has been ascertained, a new offer/answer exchange may be 337 required before media can flow (per ICE). 339 RTP No-Op [I-D.ietf-avt-rtp-no-op] enables the sender of an RTP No-Op 340 payload to verify send connectivity by examining the RTCP report(s) 341 being returned. In particular, the source SSRC in the RTCP report 342 block is used for correlation. The RTCP report block also contains 343 the SSRC of the sender of the report and the SSRC of incoming RTP 344 No-Op packets identifies the sender of the RTP packet. Thus, once 345 send connectivity has been ascertained, receipt of an RTP No-Op 346 packet from the same SSRC provides the necessary correlation to 347 determine receive connectivity. Alternatively, the duality of send 348 and receive preconditions can be exploited, with one side confirming 349 when his send precondition is satisfied, which in turn implies the 350 other sides recv precondition is satisfied. 352 The above are merely examples of explicit connectivity verification 353 mechanisms. Other techniques can be used as well. It is however 354 RECOMMENDED that ICE be supported by entities that support 355 connectivity preconditions. Use of ICE has the benefit of working 356 for all media streams (not just RTP) as well as facilitate NAT and 357 firewall traversal, which may otherwise interfere with connectivity. 358 Furthermore, the ICE recommendation provides a baseline to ensure 359 that all entities that require probe traffic to support the 360 connectivity preconditions have a common way of ascertaining 361 connectivity. 363 4.3. Verifying Connectivity for Connection-Oriented Transports 365 Connection-oriented transport protocols generally provide an implicit 366 connectivity verification mechanism. Connection establishment 367 involves sending traffic in both directions thereby verifying 368 connectivity at the transport protocol level. When a three-way (or 369 more) handshake for connection establishment succeeds, bi-directional 370 communication is confirmed and both the "send" and "recv" 371 preconditions are satisfied whether requested or not. In the case of 372 TCP for example, once the TCP three-way handshake has completed (SYN, 373 SYN-ACK, ACK), the TCP connection is established and data can be sent 374 and received by either party (i.e., both a send and a receive 375 connectivity precondition has been satisfied). SCTP [RFC4960] 376 connections have similar semantics as TCP and SHOULD be treated the 377 same. 379 When a connection-oriented transport is part of an offer, it may be 380 passive, active, or active/passive [RFC4145]. When it is passive, 381 the offerer expects the answerer to initiate the connection 382 establishment, and when it is active, the offerer wants to initiate 383 the connection establishment. When it is active/passive, the 384 answerer decides. As noted earlier, lack of a media-stream-to-dialog 385 correlation mechanism can make it difficult to guarantee with whom 386 connectivity has been ascertained. When the offerer takes on the 387 passive role, the offerer will not necessarily know which SIP dialog 388 originated an incoming connection request. If the offerer instead is 389 active, this problem is avoided. 391 5. Connectivity and Other Precondition Types 393 The role of a connectivity precondition is to ascertain media stream 394 connectivity before establishing or modifying a session. The 395 underlying intent is for the two parties to be able to exchange media 396 packets successfully. Connectivity by itself however may not fully 397 satisfy this. Quality of Service for example may be required for the 398 media stream; this can be addressed by use of the "qos" precondition 399 defined in [RFC3312]. Similarly, succesful security parameter 400 negotiation may be another prequisite; this can be addressed by use 401 of the "sec" precondition defined in [RFC5027]. 403 6. Examples 405 The first example uses the connectivity precondition with TCP in the 406 context of a session involving a wireless access medium. Both UAs 407 use a radio access network that does not allow them to send any data 408 (not even a TCP SYN) until a radio bearer has been setup for the 409 connection. Figure 1 shows the message flow of this example (the 410 required PRACK transaction has been omitted for clarity): 412 A B 413 | INVITE | 414 | a=curr:conn e2e none | 415 | a=des:conn mandatory e2e sendrecv | 416 | a=setup:holdconn | 417 |----------------------------------->| 418 | | 419 | 183 Session Progress | 420 | a=curr:conn e2e none | 421 | a=des:conn mandatory e2e sendrecv | 422 | a=setup:holdconn | 423 |<-----------------------------------| 424 | | 425 | UPDATE | 426 | a=curr:conn e2e none | 427 | a=des:conn mandatory e2e sendrecv | 428 A's radio | a=setup:actpass | 429 bearer is +----------------------------------->| 430 up | | 431 | 200 OK | 432 | a=curr:conn e2e none | 433 | a=des:conn mandatory e2e sendrecv | 434 | a=setup:active | 435 |<-----------------------------------| 436 | | 437 | | 438 | | 439 | | B's radio 440 |<---TCP Connection Establishment--->+ bearer is up 441 | | B sends TCP SYN 442 | | 443 | | 444 | 180 Ringing | TCP connection 445 |<-----------------------------------+ is up 446 | | B alerts the user 447 | | 449 Figure 1: Message flow with two types of preconditions 451 A sends an INVITE requesting connection-establishment preconditions. 452 The setup attribute in the offer is set to holdconn [RFC4145] because 453 A cannot send or receive any data before setting up a radio bearer 454 for the connection. 456 B agrees to use the connectivity precondition by sending a 183 457 (Session Progress) response. The setup attribute in the answer is 458 also set to holdconn because B, like A, cannot send or receive any 459 data before setting up a radio bearer for the connection. 461 When A's radio bearer is ready, A sends an UPDATE to B with a setup 462 attribute with a value of actpass. This attribute indicates that A 463 can perform an active or a passive TCP open. A is letting B choose 464 which endpoint will initiate the connection. 466 Since B's radio bearer is not ready yet, B chooses to be the one 467 initiating the connection and indicates so with a setup attribute 468 with a value of active. At a later point, when B's radio bearer is 469 ready, B initiates the TCP connection towards A. 471 Once the TCP connection is established successfully, B knows the 472 "sendrecv" precondition is satisfied, and B proceeds with the session 473 (i.e., alerts the Callee), and sends a 180 (Ringing) response. 475 The second example shows a basic SIP session establishment using SDP 476 connectivity preconditions and RTP No-Op (the required PRACK 477 transaction and some SDP details have been omitted for clarity). The 478 message flow for this scenario is shown in Figure 2 below. 480 A B 482 | | 483 |-------------(1) INVITE SDP1--------------->| 484 | | 485 |<------(2) 183 Session Progress SDP2--------| 486 | | 487 |<~~~~~ Connectivity check to A ~~~~~~~~~~~~~| 488 |~~~~~ Connectivity to A OK ~~~~~~~~~~~~~~~~>| 489 | | 490 |~~~~~ Connectivity check to B ~~~~~~~~~~~~~>| 491 |<~~~~ Connectivity to B OK ~~~~~~~~~~~~~~~~~| 492 | | 493 |-------------(3) UPDATE SDP3--------------->| 494 | | 495 |<--------(4) 200 OK (UPDATE) SDP4-----------| 496 | | 497 |<-------------(5) 180 Ringing---------------| 498 | | 499 | | 501 Figure 2: Connectivity precondition with RTP No-Op 503 SDP1: A includes a mandatory end-to-end connectivity precondition 504 with a desired status of "sendrecv"; this will ensure media stream 505 connectivity in both directions before continuing with the session 506 setup. Since media stream connectivity in either direction is 507 unknown at this point, the current status is set to "none". A's 508 local status table (see [RFC3312]) for the connectivity precondition 509 is as follows: 511 Direction | Current | Desired Strength | Confirm 512 -----------+----------+------------------+---------- 513 send | no | mandatory | no 514 recv | no | mandatory | no 516 and the resulting offer SDP is: 518 m=audio 20000 RTP/AVP 0 96 519 c=IN IP4 192.0.2.1 520 a=rtpmap:96 no-op/8000 521 a=curr:conn e2e none 522 a=des:conn mandatory e2e sendrecv 524 SDP2: When B receives the offer, B sees the mandatory sendrecv 525 connectivity precondition. B can ascertain connectivity to A ("send" 526 from B's point of view) by use of the RTP No-Op, however B wants A to 527 inform it about connectivity in the other direction ("recv" from B's 528 point of view). B's local status table therefore looks as follows: 530 Direction | Current | Desired Strength | Confirm 531 -----------+----------+------------------+---------- 532 send | no | mandatory | no 533 recv | no | mandatory | no 535 Since B wants to ask A for confirmation about the "recv" (from B's 536 point of view) connectivity precondition, the resulting answer SDP 537 becomes: 539 m=audio 30000 RTP/AVP 0 96 540 a=rtpmap:96 no-op/8000 541 c=IN IP4 192.0.2.4 542 a=curr:conn e2e none 543 a=des:conn mandatory e2e sendrecv 544 a=conf:conn e2e recv 546 Meanwhile, B performs a successful send connectivity check to A by 547 sending an RTP No-Op packet to A and receiving a corresponding RTCP 548 report. B's local status table is updated as follows: 550 Direction | Current | Desired Strength | Confirm 551 -----------+----------+------------------+---------- 552 send | yes | mandatory | no 553 recv | no | mandatory | no 555 Since the "recv" connectivity precondition (from B's point of view) 556 is still not satisfied, session establishment remains suspended. 558 SDP3: When A receives the answer SDP, A notes that confirmation was 559 requested for B's "recv" connectivity precondition, which is the 560 "send" precondition from A's point of view. A performs a successful 561 send connectivity check to B by sending an RTP No-Op packet to B and 562 receiving a corresponding RTCP report, and A's local status table 563 becomes: 565 Direction | Current | Desired Strength | Confirm 566 -----------+----------+------------------+---------- 567 send | yes | mandatory | yes 568 recv | no | mandatory | no 570 Since B asked for confirmation about the "send" connectivity (from 571 A's point of view), A now sends an UPDATE (5) to B to confirm the 572 connectivity from A to B: 574 m=audio 20000 RTP/AVP 0 96 575 a=rtpmap:96 no-op/8000 576 c=IN IP4 192.0.2.1 577 a=curr:conn e2e send 578 a=des:conn mandatory e2e sendrecv 580 B has both send and recv connectivity confirmed at this point and the 581 session can continue. 583 7. Security Considerations 585 In addition to the general security considerations for preconditions 586 provided in [RFC3312], the following security issues, which are 587 specific to connectivity preconditions, should be considered. 589 Connectivity preconditions rely on mechanisms beyond SDP such as 590 TCP[RFC0793] connection establishment, RTP No-Op 591 [I-D.ietf-avt-rtp-no-op], or STUN [I-D.ietf-behave-rfc3489bis] to 592 establish and verify connectivity between an offerer and an answerer. 593 An attacker that prevents those mechanism from succeeding can prevent 594 media sessions from being established and hence it is RECOMMENDED 595 that such mechanisms are adequately secured by message authentication 596 and integrity protection. Also, the mechanisms SHOULD consider how 597 to prevent denial of service attacks. Similarly, an attacker that 598 can forge packets for these mechanisms can enable sessions to be 599 established when there in fact is no media connectivity, which may 600 lead to a poor user experience. Authentication and integrity 601 protection of such mechanisms can prevent this type of attacks and 602 hence use of it is RECOMMENDED. 604 It is also strongly RECOMMENDED that integrity protection be applied 605 to the SDP session descriptions. S/MIME [RFC3853] provides such end- 606 to-end integrity protection, as described in [RFC3261]. 608 8. IANA Considerations 610 IANA is hereby requested to register a new precondition type under 611 the Precondition Types used with SIP subregistry, which is located 612 under the Session Initiation Protocol (SIP) Parameters registry. 614 Precondition-Type Description Reference 615 ----------------- ----------------------------------- --------- 616 conn Connectivity precondition [RFCxxxx] 618 [Note to the RFC Editor: replace RFCxxxx with the number assigned to 619 this RFC.] 621 9. Change Log 623 9.1. Changes since -03 625 Minor fixes here and there. 627 9.2. Changes since -02 629 Connectivity preconditions are now mechanism agnostic. Clarified 630 when and how to use ICE, RTP No-Op, and connection establishment 631 procedures to check connectivity. Clarified relation with other 632 precondition types. 634 9.3. Changes since -01 636 There are no changes since the previous version of the document. 638 10. References 640 10.1. Normative References 642 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 643 Requirement Levels", BCP 14, RFC 2119, March 1997. 645 [RFC5109] Li, A., "RTP Payload Format for Generic Forward Error 646 Correction", RFC 5109, December 2007. 648 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 649 A., Peterson, J., Sparks, R., Handley, M., and E. 650 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 651 June 2002. 653 [RFC3312] Camarillo, G., Marshall, W., and J. Rosenberg, 654 "Integration of Resource Management and Session Initiation 655 Protocol (SIP)", RFC 3312, October 2002. 657 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 658 Jacobson, "RTP: A Transport Protocol for Real-Time 659 Applications", STD 64, RFC 3550, July 2003. 661 [RFC3853] Peterson, J., "S/MIME Advanced Encryption Standard (AES) 662 Requirement for the Session Initiation Protocol (SIP)", 663 RFC 3853, July 2004. 665 [RFC4032] Camarillo, G. and P. Kyzivat, "Update to the Session 666 Initiation Protocol (SIP) Preconditions Framework", 667 RFC 4032, March 2005. 669 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 670 Description Protocol", RFC 4566, July 2006. 672 10.2. Informative References 674 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 675 RFC 793, September 1981. 677 [RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in 678 the Session Description Protocol (SDP)", RFC 4145, 679 September 2005. 681 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", 682 RFC 4960, September 2007. 684 [RFC5027] Andreasen, F. and D. Wing, "Security Preconditions for 685 Session Description Protocol (SDP) Media Streams", 686 RFC 5027, October 2007. 688 [I-D.ietf-avt-rtp-no-op] 689 Andreasen, F., "A No-Op Payload Format for RTP", 690 draft-ietf-avt-rtp-no-op-04 (work in progress), May 2007. 692 [I-D.ietf-mmusic-ice] 693 Rosenberg, J., "Interactive Connectivity Establishment 694 (ICE): A Protocol for Network Address Translator (NAT) 695 Traversal for Offer/Answer Protocols", 696 draft-ietf-mmusic-ice-16 (work in progress), June 2007. 698 [I-D.ietf-mmusic-ice-tcp] 699 Rosenberg, J., "TCP Candidates with Interactive 700 Connectivity Establishment (ICE", 701 draft-ietf-mmusic-ice-tcp-03 (work in progress), 702 March 2007. 704 [I-D.ietf-behave-rfc3489bis] 705 Rosenberg, J., "Session Traversal Utilities for (NAT) 706 (STUN)", draft-ietf-behave-rfc3489bis-06 (work in 707 progress), March 2007. 709 Authors' Addresses 711 Flemming Andreasen 712 Cisco Systems, Inc. 713 499 Thornall Street, 8th Floor 714 Edison, NJ 08837 715 USA 717 Email: fandreas@cisco.com 719 Gonzalo Camarillo 720 Ericsson 721 Hirsalantie 11 722 Jorvas 02420 723 Finland 725 Email: Gonzalo.Camarillo@ericsson.com 727 David Oran 728 Cisco Systems, Inc. 729 7 Ladyslipper Lane 730 Acton, MA 01720 731 USA 733 Email: oran@cisco.com 735 Dan Wing 736 Cisco Systems, Inc. 737 170 West Tasman Drive 738 San Jose, CA 94301 739 USA 741 Email: dwing@cisco.com 743 Full Copyright Statement 745 Copyright (C) The IETF Trust (2008). 747 This document is subject to the rights, licenses and restrictions 748 contained in BCP 78, and except as set forth therein, the authors 749 retain all their rights. 751 This document and the information contained herein are provided on an 752 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 753 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 754 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 755 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 756 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 757 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 759 Intellectual Property 761 The IETF takes no position regarding the validity or scope of any 762 Intellectual Property Rights or other rights that might be claimed to 763 pertain to the implementation or use of the technology described in 764 this document or the extent to which any license under such rights 765 might or might not be available; nor does it represent that it has 766 made any independent effort to identify any such rights. Information 767 on the procedures with respect to rights in RFC documents can be 768 found in BCP 78 and BCP 79. 770 Copies of IPR disclosures made to the IETF Secretariat and any 771 assurances of licenses to be made available, or the result of an 772 attempt made to obtain a general license or permission for the use of 773 such proprietary rights by implementers or users of this 774 specification can be obtained from the IETF on-line IPR repository at 775 http://www.ietf.org/ipr. 777 The IETF invites any interested party to bring to its attention any 778 copyrights, patents or patent applications, or other proprietary 779 rights that may cover technology that may be required to implement 780 this standard. Please address the information to the IETF at 781 ietf-ipr@ietf.org. 783 Acknowledgment 785 Funding for the RFC Editor function is provided by the IETF 786 Administrative Support Activity (IASA).