idnits 2.17.1 draft-singh-mmusic-mprtp-sdp-extension-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 : ---------------------------------------------------------------------------- == There are 8 instances of lines with non-RFC2606-compliant FQDNs in the document. -- 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 and authors Copyright Line does not match the current year -- The document date (September 30, 2014) is 3497 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-10) exists of draft-singh-avtcore-mprtp-09 ** Obsolete normative reference: RFC 5245 (Obsoleted by RFC 8445, RFC 8839) == Outdated reference: A later version (-02) exists of draft-ietf-mmusic-trickle-ice-01 -- Obsolete informational reference (is this intentional?): RFC 4566 (Obsoleted by RFC 8866) Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MMUSIC Working Group V. Singh 3 Internet-Draft J. Ott 4 Intended status: Experimental T. Karkkainen 5 Expires: April 3, 2015 Aalto University 6 R. Globisch 7 T. Schierl 8 Fraunhofer HHI 9 September 30, 2014 11 Multipath RTP (MPRTP) attribute in Session Description Protocol 12 draft-singh-mmusic-mprtp-sdp-extension-04 14 Abstract 16 Multipath RTP (MPRTP) is an extension to the Real-time Transport 17 Protocol (RTP) that allows multi-homed endpoints to take advantage of 18 the availability of multiple Internet paths between endpoints to send 19 /receive media packets. This document describes how to express the 20 interface advertisement and negotiation during session setup in SDP 21 (Session Description Protocol). 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on April 3, 2015. 40 Copyright Notice 42 Copyright (c) 2014 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 59 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. SDP Considerations . . . . . . . . . . . . . . . . . . . . . 3 61 2.1. MPRTP Interface Advertisement in SDP (out-of-band 62 signaling) . . . . . . . . . . . . . . . . . . . . . . . 4 63 2.1.1. "interface" attribute . . . . . . . . . . . . . . . . 4 64 2.1.2. Example . . . . . . . . . . . . . . . . . . . . . . . 5 65 2.2. MPRTP with ICE . . . . . . . . . . . . . . . . . . . . . 5 66 2.3. Offer/Answer . . . . . . . . . . . . . . . . . . . . . . 6 67 2.3.1. In-band Signaling Example . . . . . . . . . . . . . . 7 68 2.3.2. Out-of-band Signaling Example . . . . . . . . . . . . 7 69 2.3.2.1. Without ICE . . . . . . . . . . . . . . . . . . . 8 70 2.3.2.2. With ICE . . . . . . . . . . . . . . . . . . . . 8 71 2.4. Increased Throughput . . . . . . . . . . . . . . . . . . 10 72 2.5. Increased Reliability . . . . . . . . . . . . . . . . . . 10 73 2.6. Decoding dependency . . . . . . . . . . . . . . . . . . . 10 74 3. MPRTP in RTSP . . . . . . . . . . . . . . . . . . . . . . . . 10 75 3.1. Solution Overview without ICE . . . . . . . . . . . . . . 11 76 3.2. Solution Overview with ICE . . . . . . . . . . . . . . . 13 77 3.3. RTSP Extensions . . . . . . . . . . . . . . . . . . . . . 15 78 3.3.1. MPRTP Interface Transport Header Parameter . . . . . 15 79 3.3.2. MPRTP Feature Tag . . . . . . . . . . . . . . . . . . 16 80 3.3.3. Status Codes . . . . . . . . . . . . . . . . . . . . 16 81 3.3.4. New Reason for PLAY_NOTIFY . . . . . . . . . . . . . 16 82 3.3.5. Re-SETUP . . . . . . . . . . . . . . . . . . . . . . 17 83 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 84 4.1. SDP Attributes . . . . . . . . . . . . . . . . . . . . . 18 85 4.1.1. "mprtp" attribute . . . . . . . . . . . . . . . . . . 18 86 4.2. RTSP . . . . . . . . . . . . . . . . . . . . . . . . . . 18 87 4.2.1. RTSP Feature Tag . . . . . . . . . . . . . . . . . . 18 88 4.2.2. RTSP Transport Parameters . . . . . . . . . . . . . . 18 89 4.2.3. Notify-Reason value . . . . . . . . . . . . . . . . . 18 90 5. Security Considerations . . . . . . . . . . . . . . . . . . . 19 91 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 92 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 19 93 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 94 8.1. Normative References . . . . . . . . . . . . . . . . . . 19 95 8.2. Informative References . . . . . . . . . . . . . . . . . 20 96 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 21 97 A.1. Changes in draft-singh-mmusic-mprtp-sdp-extension-03 . . 21 98 A.2. Changes in draft-singh-mmusic-mprtp-sdp-extension-02 . . 21 99 A.3. Changes in draft-singh-mmusic-mprtp-sdp-extension-01 . . 21 100 A.4. Changes in draft-singh-mmusic-mprtp-sdp-extension-00 . . 21 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 103 1. Introduction 105 Multipath RTP (MPRTP) [I-D.singh-avtcore-mprtp] is an extension to 106 RTP [RFC3550] that allows splitting a single RTP stream into multiple 107 subflows, which are then transmitted over different Internet paths. 108 Multipath RTCP (MPRTCP) [I-D.singh-avtcore-mprtp] is an extension to 109 RTCP. It is used along with MPRTP to report per-path sender and 110 receiver characteristics. 112 A Multipath RTP session can be set up in many possible ways e.g., 113 during handshake, or upgraded mid-session. The capability exchange 114 may be done using out-of-band signaling (e.g., Session Description 115 Protocol (SDP) [RFC3264] in Session Initiation Protocol (SIP) 116 [RFC3261], Real-Time Streaming Protocol (RTSP) 117 [I-D.ietf-mmusic-rfc2326bis]) or using in-band signaling (e.g., in 118 RTCP [I-D.singh-avtcore-mprtp]). 120 This document defines an extension to the SDP attribute 'a=mprtp' 121 defined in the base MPRTP specification [I-D.singh-avtcore-mprtp]. 122 Using this extension an endpoint can advertise its multiple 123 interfaces. 125 1.1. Requirements Language 127 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 128 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 129 document are to be interpreted as described in [RFC2119]. 131 1.2. Terminology 133 The definitions for the words Endpoint, Interface, Path and Subflow 134 in this document are as per [I-D.singh-avtcore-mprtp]. 136 2. SDP Considerations 138 The base Multipath RTP specification [I-D.singh-avtcore-mprtp] 139 defines the 'a=mprtp' attribute to indicate support for MPRTP. In 140 the following section, we extend the 'a=mprtp' attribute to advertise 141 an endpoint's multiple interfaces in SDP instead of advertising the 142 interfaces in-band in RTCP [I-D.singh-avtcore-mprtp]. 144 2.1. MPRTP Interface Advertisement in SDP (out-of-band signaling) 146 If the endpoint is aware of its multiple interfaces and wants to use 147 them for MPRTP, it MAY use SDP to advertise these interfaces. 148 Alternatively, it MAY use in-band signaling to advertise its 149 interfaces, as defined in [I-D.singh-avtcore-mprtp]. The receiving 150 endpoint MUST use the same mechanism to respond to an interface 151 advertisement. In particular, if an endpoint receives an SDP 152 containing multiple MPRTP interfaces, then it MUST respond to the 153 offer in SDP with its set of MPRTP interfaces. 155 2.1.1. "interface" attribute 157 The interface attribute is an optional media-level attribute and is 158 used to advertise an endpoint's interface address. 160 The syntax of the interface attribute is defined using the following 161 Augmented BNF, as defined in [RFC5234]. The definitions of unicast- 162 address, port, token, SP, and CRLF are according to RFC4566 163 [RFC4566]. 165 mprtp-optional-parameter = mprtp-interface 166 ; other optional parameters may be added later 168 mprtp-interface = "interface" ":" counter SP unicast-address 169 ":" rtp_port 170 *(SP interface-description-extension) 172 counter = 1*DIGIT 173 rtp_port = port ;port from RFC4566 175 : specifies one unicast IP address, the RTP port 176 number of the endpoint (MPRTP [I-D.singh-avtcore-mprtp] uses RTP/RTCP 177 port multiplexing). The unicast address with lowest counter value 178 MUST match the connection address ('c=' line). Similarly, the RTP 179 and RTCP ports MUST match the RTP and RTCP ports in the associated 180 'm=' line. The counter SHOULD start at 1 and increment with each 181 additional interface. Multiple interface lines MUST be ordered in a 182 decreasing priority level as is the case with the Interface 183 Advertisement blocks in in-band signaling (See 184 [I-D.singh-avtcore-mprtp]). 186 : is taken from RFC4566 [RFC4566]. It is one of the 187 IP addresses of the endpoint and allows the use of IPv4 addresses, 188 IPv6 addresses and Fully Qualified Domain Names (FQDN). When 189 choosing IPv6 addresses the endpoint MUST perform the IPv6 address 190 prioritization and selection as proposed in 191 [I-D.keranen-mmusic-ice-address-selection]. 193 : is from RFC4566 [RFC4566]. It is the RTP port associated 194 with the unicast address and note that the RTP and RTCP ports are 195 multiplexed for MPRTP subflows according to [RFC5761]. 197 : is a monotonically increasing positive integer starting at 198 1. The counter MUST reset for each media line. The counter value 199 for an 'mprtp-interface' should remain the same for the session, 200 unless the priorities of the interfaces change. 202 [Editor's note: do we need a counter?] 204 The 'mprtp-interface' can be extended using the 'interface- 205 description-extension' parameter. An endpoint MUST ignore any 206 extensions it does not understand. 208 2.1.2. Example 210 The ABNF grammar is illustrated by means of an example: 212 v=0 213 o=alice 2890844526 2890844527 IN IP4 192.0.2.1 214 s= 215 c=IN IP4 192.0.2.1 216 t=0 0 217 m=video 49170 RTP/AVP 98 218 a=rtpmap:98 H264/90000 219 a=fmtp:98 profile-level-id=42A01E; 220 a=extmap:1 urn:ietf:params:rtp-hdrext:mprtp 221 a=rtcp-mux 222 a=mprtp interface:1 192.0.2.1:49170 ;primary interface 223 a=mprtp interface:2 198.51.100.1:51372 ;additional interface 225 2.2. MPRTP with ICE 227 If the endpoints intend to use ICE [RFC5245] for discovering 228 interfaces and running connectivity checks, the following two step 229 procedure MUST be followed: 231 1. Advertise ICE candidates: in the initial OFFER the endpoints 232 exchange candidates, as defined in ICE [RFC5245]. Thereafter the 233 endpoints run connectivity checks. 235 2. Advertise MPRTP interfaces: When a sufficient number of 236 connectivity checks succeed, the endpoint MUST send an updated 237 offer containing the interfaces that they want to use for MPRTP. 239 When an endpoint uses ICE's regular nomination [RFC5245] procedure, 240 it chooses the best ICE candidate as the default path. In the case 241 of an MPRTP endpoint, if the connectivity check of more than one ICE 242 candidate succeeded, then an MPRTP endpoint MAY advertise (some of) 243 these as MPRTP interfaces in an updated offer. 245 When an endpoint uses ICE's aggressive nomination [RFC5245] 246 procedure, the selected candidate may change as more ICE checks 247 complete. Instead of sending updated offers as additional ICE 248 candidates appear (transience), the endpoint MAY use in-band 249 signaling to advertise its interfaces, as defined in 250 [I-D.singh-avtcore-mprtp]. Additionally, it MAY send an updated 251 offer when the transience stabilizes. 253 If the default interface disappears and the paths used for MPRTP are 254 different from the one in the c= and m= lines then the 'mprtp 255 interface' with the lowest counter value should be promoted to the c= 256 and m= lines in the updated offer. 258 When a new interface appears, then the application/endpoint should 259 internally decide if it wishes to use it and sends an updated offer 260 with ICE candidates of the new interface. The receiving endpoint 261 responds to the offer with all its ICE candidates in the answer and 262 starts connectivity checks between all its candidates and the 263 offerer's new ICE candidate. Similarly, the initiating endpoint 264 starts connectivity checks between the new interface and all the 265 received ICE candidates in the answer. If the connectivity checks 266 succeed, the initiating endpoint MAY send an updated offer with the 267 new interface as an additional 'mprtp interface'. 269 [Editor's Note: should we also consider using trickle ICE for MPRTP? 270 Trickle ICE is introduced in: [I-D.ietf-mmusic-trickle-ice] and for 271 SIP in [I-D.ivov-mmusic-trickle-ice-sip].] 273 2.3. Offer/Answer 275 When SDP [RFC4566] is used to negotiate MPRTP interfaces (see 276 Section 2.1) following the offer/answer model [RFC3264], the 277 collection of "a=mprtp interface" attribute lines indicates the 278 interfaces the endpoint wishes to use for sending and/or receiving 279 media data. The SDP offer MUST include this attribute at the media 280 level. If the answerer wishes to also use SDP for advertising MPRTP 281 interfaces, it MUST also include its interfaces at the media-level 282 "a=mprtp interface" attribute in the answer. If the answer does not 283 contain an "a=mprtp interface" attribute, the offerer MUST use in- 284 band signaling [I-D.singh-avtcore-mprtp] for advertising interfaces. 286 When SDP is used in a declarative manner, the presence of an "a=mprtp 287 interface" attribute signals that the sender can send or receive 288 media data over multiple interfaces. The receiver SHOULD be capable 289 of streaming media to the multiple interfaces and be prepared to 290 receive media from multiple interfaces. 292 The following sections shows examples of SDP offer and answer for in- 293 band and out-of-band signaling. 295 2.3.1. In-band Signaling Example 297 The following offer/answer shows that both the endpoints are MPRTP 298 capable and SHOULD use in-band signaling for interfaces 299 advertisements. 301 Offer: 302 v=0 303 o=alice 2890844526 2890844527 IN IP4 192.0.2.1 304 s= 305 c=IN IP4 192.0.2.1 306 t=0 0 307 m=video 49170 RTP/AVP 98 308 a=rtpmap:98 H264/90000 309 a=fmtp:98 profile-level-id=42A01E; 310 a=rtcp-mux 311 a=mprtp 313 Answer: 314 v=0 315 o=bob 2890844528 2890844529 IN IP4 192.0.2.2 316 s= 317 c=IN IP4 192.0.2.2 318 t=0 0 319 m=video 4000 RTP/AVP 98 320 a=rtpmap:98 H264/90000 321 a=fmtp:98 profile-level-id=42A01E; 322 a=rtcp-mux 323 a=mprtp 325 The endpoint MAY now use in-band RTCP signaling to advertise its 326 multiple interfaces. Alternatively, it MAY make another offer with 327 the interfaces in SDP (out-of-band signaling). 329 2.3.2. Out-of-band Signaling Example 331 If multiple interfaces are included in an SDP offer then the MPRTP- 332 capable receiver MUST respond to the request with an SDP answer 333 containing one or more interfaces. If the SDP answer does not 334 contain "a=mprtp", the offerer can conclude that the endpoint does 335 not support MPRTP and continue the session using a single path. 337 2.3.2.1. Without ICE 339 In this example, the offerer advertises two interfaces and the 340 answerer responds with a single interface description. The endpoint 341 MAY use one or both paths depending on the end-to-end characteristics 342 of each path. 344 Offer: 345 v=0 346 o=alice 2890844526 2890844527 IN IP4 192.0.2.1 347 s= 348 c=IN IP4 192.0.2.1 349 t=0 0 350 m=video 49170 RTP/AVP 98 351 a=rtpmap:98 H264/90000 352 a=fmtp:98 profile-level-id=42A01E; 353 a=rtcp-mux 354 a=mprtp interface:1 192.0.2.1:49170 355 a=mprtp interface:2 198.51.100.1:51372 357 Answer: 358 v=0 359 o=bob 2890844528 2890844529 IN IP4 192.0.2.2 360 s= 361 c=IN IP4 192.0.2.2 362 t=0 0 363 m=video 4000 RTP/AVP 98 364 a=rtpmap:98 H264/90000 365 a=fmtp:98 profile-level-id=42A01E; 366 a=rtcp-mux 367 a=mprtp interface:1 192.0.2.2:4000 369 2.3.2.2. With ICE 371 In this example, the endpoint first sends its ICE candidates in the 372 initial offer and the other endpoint answers with its ICE candidates. 374 Initial offer (with ICE candidates): 376 Offer: 377 v=0 378 o=alice 2890844526 2890844527 IN IP4 192.0.2.1 379 s= 380 c=IN IP4 192.0.2.1 381 t=0 0 382 a=ice-pwd:asd88fgpdd777uzjYhagZg 383 a=ice-ufrag:8hhY 384 a=mprtp 385 m=video 49170 RTP/AVP 98 386 a=rtpmap:98 H264/90000 387 a=fmtp:98 profile-level-id=42A01E; 388 a=rtcp-mux 389 a=candidate:1 1 UDP 2130706431 192.0.2.1 49170 typ host 390 a=candidate:2 1 UDP 1694498815 198.51.100.1 51372 typ host 392 Answer: 393 v=0 394 o=bob 2890844528 2890844529 IN IP4 192.0.2.2 395 s= 396 c=IN IP4 192.0.2.2 397 t=0 0 398 a=ice-pwd:YH75Fviy6338Vbrhrlp8Yh 399 a=ice-ufrag:9uB6 400 a=mprtp 401 m=video 4000 RTP/AVP 98 402 a=rtpmap:98 H264/90000 403 a=fmtp:98 profile-level-id=42A01E; 404 a=rtcp-mux 405 a=candidate:1 1 UDP 2130706431 192.0.2.2 4000 typ host 407 Thereafter, each endpoint conducts ICE connectivity checks and when 408 sufficient number of connectivity checks succeed, the endpoint sends 409 an updated offer. In the updated offer, the endpoint advertises its 410 multiple interfaces for MPRTP. 412 Updated offer (with MPRTP interfaces): 414 Offer: 415 v=0 416 o=alice 2890844526 2890844527 IN IP4 192.0.2.1 417 s= 418 c=IN IP4 192.0.2.1 419 t=0 0 420 m=video 49170 RTP/AVP 98 421 a=rtpmap:98 H264/90000 422 a=fmtp:98 profile-level-id=42A01E; 423 a=rtcp-mux 424 a=candidate:1 1 UDP 2130706431 192.0.2.1 49170 typ host 425 a=candidate:2 1 UDP 1694498815 198.51.100.1 51372 typ host 426 a=mprtp interface:1 192.0.2.1:49170 427 a=mprtp interface:2 198.51.100.1:51372 429 Answer: 430 v=0 431 o=bob 2890844528 2890844529 IN IP4 192.0.2.2 432 s= 433 c=IN IP4 192.0.2.2 434 t=0 0 435 m=video 4000 RTP/AVP 98 436 a=rtpmap:98 H264/90000 437 a=fmtp:98 profile-level-id=42A01E; 438 a=rtcp-mux 439 a=candidate:1 1 UDP 2130706431 192.0.2.2 4000 typ host 440 a=mprtp interface:1 192.0.2.2:4000 442 2.4. Increased Throughput 444 The MPRTP layer MAY choose to augment paths to increase throughput. 445 If the desired media rate exceeds the current media rate, the 446 endpoints MUST renegotiate the application specific ("b=AS:xxx") 447 [RFC4566] bandwidth. 449 2.5. Increased Reliability 451 TBD 453 2.6. Decoding dependency 455 TBD 457 3. MPRTP in RTSP 459 Endpoints MUST use RTSP 2.0 [I-D.ietf-mmusic-rfc2326bis] for session 460 setup. Endpoints MUST multiplex RTP and RTCP on a single port 462 [RFC5761] and follow the recommendations made in Appendix C of 463 [I-D.ietf-mmusic-rfc2326bis]. 465 3.1. Solution Overview without ICE 467 1. The RTSP Server should include all of its interfaces via the SDP 468 attribute ("a=mprtp interface") in the RTSP DESCRIBE message. 470 2. The RTSP Client should include its multiple interfaces in the 471 RTSP SETUP message using the new attribute ("dest_mprtp_addr=") 472 in the Transport header. 474 3. The RTSP Server responds to the RTSP SETUP message with a 200 OK 475 containing its MPRTP interfaces (using the "src_mprtp_header=") 476 in the Transport header. After this, the RTSP Client can issue a 477 PLAY request. 479 4. If a new interface appears or an existing one disappear at the 480 RTSP Client during playback, it should send a new RTSP SETUP 481 message containing the updated interfaces ("dest_mprtp_addr") in 482 the Transport header. 484 5. If a new interface appears or an existing one disappears at the 485 RTSP Server during playback, the RTSP Server should send a 486 PLAY_NOTIFY message with a new Notify-Reason: "src-mprtp- 487 interface-update". The request must contain the updated 488 interfaces ("dest_mprtp_addr") in the "MPRTP-Interfaces" header. 490 6. Alternatively, the RTSP Server or Client may use the RTCP (in- 491 band) mechanism to advertise their interfaces. 493 The overview is illustrated by means of an example: 495 C->S: DESCRIBE rtsp://server.example.com/fizzle/foo RTSP/2.0 496 CSeq: 111 497 User-Agent: PhonyClient 1.3 498 Accept: application/sdp, application/example 499 Supported: setup.mprtp, setup.rtp.rtcp.mux 501 S->C: RTSP/2.0 200 OK 502 CSeq: 111 503 Date: 23 Jan 2011 15:35:06 GMT 504 Server: PhonyServer 1.3 505 Content-Type: application/sdp 506 Content-Length: 367 507 Supported: setup.mprtp, setup.rtp.rtcp.mux 509 v=0 510 o=mprtp-rtsp-server 2890844526 2890844527 IN IP4 192.0.2.1 511 s= 512 c=IN IP4 192.0.2.1 513 t=0 0 514 m=video 49170 RTP/AVP 98 515 a=rtpmap:98 H264/90000 516 a=fmtp:98 profile-level-id=42A01E; 517 a=extmap:1 urn:ietf:params:rtp-hdrext:mprtp 518 a=rtcp-mux 519 a=mprtp interface:1 192.0.2.1:49170 520 a=mprtp interface:2 198.51.100.1:51372 522 On receiving the response to the RTSP DESCRIBE message, the RTSP 523 Client sends an RTSP SETUP message containing its MPRTP interfaces in 524 the Transport header using the "dest_mprtp_addr=" attribute. The 525 RTSP Server responds with a 200 OK containing both the RTSP Client's 526 and the RTSP Server's MPRTP interfaces. 528 C->S: SETUP rtsp://server.example.com/fizzle/foo/audio RTSP/2.0 529 CSeq: 112 530 Transport: RTP/AVPF/UDP; unicast; dest_mprtp_addr=" 531 1 192.0.2.2 4000"; RTCP-mux, 532 RTP/AVP/UDP; unicast; dest_addr=":6970"/":6971", 533 RTP/AVP/TCP;unicast;interleaved=0-1 534 Accept-Ranges: NPT, UTC 535 User-Agent: PhonyClient 1.3 536 Supported: setup.mprtp, setup.rtp.rtcp.mux 538 S->C: RTSP/2.0 200 OK 539 CSeq: 112 540 Session: 12345678 541 Transport: RTP/AVPF/UDP; unicast; dest_mprtp_addr=" 542 1 192.0.2.2 4000"; 543 src_mprtp_addr="1 192.0.2.1 49170; 544 2 198.51.100.1 51372"; RTCP-mux 545 Accept-Ranges: NPT 546 Date: 23 Jan 2012 15:35:06 GMT 547 Server: PhonyServer 1.3 548 Supported: setup.mprtp, setup.rtp.rtcp.mux 550 The RTSP Client can issue a PLAY request on receiving the 200 OK and 551 media can start to stream once the RTSP Server receives the PLAY 552 request. 554 3.2. Solution Overview with ICE 556 This overview uses the ICE mechanisms [I-D.ietf-mmusic-rtsp-nat] 557 defined for RTSP 2.0 [I-D.ietf-mmusic-rfc2326bis]. 559 1. The RTSP Server should include the "a=rtsp-ice-d-m" attribute and 560 also indicate that it supports MPRTP by including the "a=mprtp" 561 attribute in the SDP of the RTSP DESCRIBE message. 563 2. The client sends an RTSP SETUP message containing the D-ICE in 564 lower level transport and ICE candidates in the Transport header. 565 The RTSP Server and Client then follow the procedures (Steps 2 to 566 8) described in [I-D.ietf-mmusic-rtsp-nat]. 568 3. When the connectivity checks conclude, the RTSP Client can send 569 an updated RTSP SETUP message with its MPRTP interfaces (ICE 570 candidates that were successful) in the Transport header 571 ("dest_mprtp_addr="). The RTSP Server responds to the RTSP SETUP 572 message with a 200 OK containing its MPRTP interfaces (ICE 573 candidates that were successful) in the Transport header 574 ("src_mprtp_header="). After receiving the 200 OK, the RTSP 575 Client can issue the PLAY request. 577 4. Alternatively, after the connectivity checks conclude, the RTSP 578 Client can issue the PLAY request (Step 9 and 10 of 579 [I-D.ietf-mmusic-rtsp-nat]) and the endpoints can use the RTCP 580 (in-band) mechanism to advertise their interfaces. 582 5. If a new interface appears or an existing one disappears, the 583 RTSP Client should issue an updated SETUP message with the new 584 candidates (See Section 5.12 of [I-D.ietf-mmusic-rtsp-nat]) or 585 the RTSP Server should send a PLAY_NOTIFY message (See 586 Section 5.13 of [I-D.ietf-mmusic-rtsp-nat]). After connectivity 587 checks succeed for the new interfaces, the RTSP Client can 588 proceed with the instructions in Step 3 or 4. 590 The overview is illustrated by means of an example: 592 C->S: DESCRIBE rtsp://server.example.com/foo RTSP/2.0 593 CSeq: 312 594 User-Agent: PhonyClient 1.3 595 Accept: application/sdp, application/example 596 Supported: setup.mprtp, setup.ice-d-m, setup.rtp.rtcp.mux 598 S->C: RTSP/2.0 200 OK 599 CSeq: 312 600 Date: 23 Jan 2012 15:35:06 GMT 601 Server: PhonyServer 1.3 602 Content-Type: application/sdp 603 Content-Length: 367 604 Supported: setup.mprtp, setup.ice-d-m, setup.rtp.rtcp.mux 606 v=0 607 o=mprtp-rtsp-server 2890844526 2890842807 IN IP4 192.0.2.1 608 s=SDP Seminar 609 i=A Seminar on the session description protocol 610 u=http://www.example.com/lectures/sdp.ps 611 e=seminar@example.com (Seminar Management) 612 t=2873397496 2873404696 613 a=recvonly 614 a=rtsp-ice-d-m 615 a=control: * 616 m=video 49170 RTP/AVP 98 617 a=rtpmap:98 H264/90000 618 a=fmtp:98 profile-level-id=42A01E; 619 a=rtcp-mux 620 a=mprtp 621 a=control: /video 623 C->S: SETUP rtsp://server.example.com/foo/video RTSP/2.0 624 CSeq: 302 625 Transport: RTP/AVP/D-ICE; unicast; ICE-ufrag=9uB6; 626 ICE-Password=YH75Fviy6338Vbrhrlp8Yh; 627 candidates="1 1 UDP 2130706431 192.0.2.2 628 4000 typ host"; RTCP-mux, 629 RTP/AVP/UDP; unicast; dest_addr=":6970"/":6971", 630 RTP/AVP/TCP;unicast;interleaved=0-1 631 Accept-Ranges: NPT, UTC 632 User-Agent: PhonyClient 1.3 633 Supported: setup.mprtp, setup.ice-d-m, setup.rtp.rtcp.mux 635 S->C: RTSP/2.0 200 OK 636 CSeq: 302 637 Session: 12345678 638 Transport: RTP/AVP/D-ICE; unicast; RTCP-mux; 639 ICE-ufrag=8hhY; ICE-Password= 640 asd88fgpdd777uzjYhagZg; candidates=" 641 1 1 UDP 2130706431 192.0.2.1 49170 typ host; 642 2 1 UDP 1694498815 198.51.100.1 51372 typ host" 643 Accept-Ranges: NPT 644 Date: 23 Jan 2012 15:35:06 GMT 645 Server: PhonyServer 1.3 646 Supported: setup.mprtp, setup.ice-d-m, setup.rtp.rtcp.mux 648 After the connectivity checks complete, the RTSP Client can send an 649 updated RTSP SETUP message containing the MPRTP interfaces for which 650 the connectivity checks were successful. These steps are the same as 651 the ones in the previous example. 653 3.3. RTSP Extensions 655 3.3.1. MPRTP Interface Transport Header Parameter 657 This section defines a new RTSP Transport parameter for carrying 658 MPRTP interfaces. The transport parameters may only occur once in 659 each transport specification. The parameter can contain one or more 660 MPRTP interfaces. If the RTSP Server supports MPRTP it MUST include 661 one or more MPRTP interfaces in the SETUP response. 663 trns-parameter = 665 trns-parameter =/ SEMI dest-mprtp-interface-par 666 trns-parameter =/ SEMI src-mprtp-interface-par 667 dest-mprtp-interface-par = "dest_mprtp_addr" EQUAL DQUOTE SWS 668 interface *(SEMI interface) SWS DQUOTE 669 src-mprtp-interface-par = "src_mprtp_addr" EQUAL DQUOTE SWS 670 interface *(SEMI interface) SWS DQUOTE 672 interface = counter SP 673 unicast-address SP 674 rtp_port SP 675 *(SP interface-description-extension) 677 counter = See section 2.3.1 678 unicast-address = See section 2.3.1 679 rtp_port = See section 2.3.1 680 interface-description-extension = See section 2.3.1 681 EQUAL = 682 DQUOTE = 683 SWS = 684 SEMI = 686 3.3.2. MPRTP Feature Tag 688 A feature tag is defined for indicating MPRTP support in the RTSP 689 capabilities mechanism: "setup.mprtp". This feature tag indicates 690 that the endpoint supports all the mandatory extensions defined in 691 this specification and is applicable to all types of RTSP agents; 692 clients, servers and proxies. 694 The MPRTP compliant RTSP Client MUST send the feature tag 695 "setup.mprtp" in the "Supported" header of all DESCRIBE and SETUP 696 requests. 698 3.3.3. Status Codes 700 TBD 702 3.3.4. New Reason for PLAY_NOTIFY 704 A new value used in the PLAY_NOTIFY methods Notify-Reason header is 705 defined: "src-mprtp-interface-update". This reason indicates that 706 the RTSP Server has updated set of MPRTP interfaces. 708 Notify-Reas-val =/ "src-mprtp-interface-update" 710 PLAY_NOTIFY requests with Notify-Reason header set to src-mprtp- 711 interface-update MUST include a mprtp-interfaces header. 713 mprtp-interfaces = "mprtp-interfaces" HCOLON interface 714 *(COMMA interface) 715 interface = counter SP 716 unicast-address SP 717 rtp_port SP 718 *(SP interface-description-extension) 720 counter = See section 2.3.1 721 unicast-address = See section 2.3.1 722 rtp_port = See section 2.3.1 723 interface-description-extension = See section 2.3.1 725 Example: 727 S->C: PLAY_NOTIFY rtsp://server.example.com/foo RTSP/2.0 728 CSeq: 305 729 Notify-Reason: src-mprtp-interface-update 730 Session: 12345678 731 mprtp-interfaces: 2 192.0.2.10 48211, 3 198.51.100.11 38703 732 Server: PhonyServer 1.3 734 C->S: RTSP/2.0 200 OK 735 CSeq: 305 736 User-Agent: PhonyClient 1.3 738 3.3.5. Re-SETUP 740 The server SHALL support SETUP requests in PLAYING state if it is 741 only updating the transport parameter (dest_mprtp_addr). If the 742 session is established using ICE then the RTSP Server and Client MUST 743 also follow the procedures described for Re-SETUP in 744 [I-D.ietf-mmusic-rtsp-nat]. 746 4. IANA Considerations 748 The following contact information shall be used for all registrations 749 in this document: 751 Contact: Varun Singh 752 mailto:varun.singh@iki.fi 753 tel:+358-9-470-24785 755 Note to the RFC-Editor: When publishing this document as an RFC, 756 please replace "RFC XXXX" with the actual RFC number of this document 757 and delete this sentence. 759 4.1. SDP Attributes 761 4.1.1. "mprtp" attribute 763 o Attribute Name: MPRTP 765 o Long Form: Multipath RTP 767 o Type of Attribute: media-level 769 o Charset Considerations: The attribute is not subject to the 770 charset attribute. 772 o Purpose: This attribute is extended to signal one of many possible 773 interfaces for communication. These interface addresses may have 774 been validated using ICE procedures. 776 o Appropriate Values: Section 2.1.1 of RFC XXXX. 778 4.2. RTSP 780 This document requests registration in a number of registries for 781 RTSP. 783 4.2.1. RTSP Feature Tag 785 This document request that one RTSP 2.0 feature tag be registered in 786 the "RTSP 2.0 feature tag" registry: 788 setup.mprtp See Section 3.3.2. 790 4.2.2. RTSP Transport Parameters 792 This document requests that 2 transport parameters be registered in 793 RTSP 2.0's "Transport Parameters": 795 "dest_mprtp_addr": See Section 3.3.1. 797 "src_mprtp_addr": See Section 3.3.1. 799 4.2.3. Notify-Reason value 801 This document requests that one assignment be done in the RTSP 2.0 802 Notify-Reason header value registry. The defined value is: 804 "src-mprtp-interface-update": See Section 3.3.4. 806 5. Security Considerations 808 All drafts are required to have a security considerations section. 809 See RFC 3552 [RFC3552] for a guide. 811 6. Acknowledgements 813 Varun Singh, Saba Ahsan, and Teemu Karkkainen are supported by 814 Trilogy (http://www.trilogy-project.org), a research project 815 (ICT-216372) partially funded by the European Community under its 816 Seventh Framework Program. 818 The work of Varun Singh, Joerg Ott, Ralf Globisch and Thomas Schierl 819 has been partially supported by the European Institute of Innovation 820 and Technology (EIT) ICT Labs activity RCLD 11882. 822 The views expressed here are those of the author(s) only. Neither 823 the European Commission nor the EITICT labs is liable for any use 824 that may be made of the information in this document. 826 7. Contributors 828 Saba Ahsan 829 Aalto University 830 School of Science and Technology 831 Otakaari 5 A 832 Espoo, FIN 02150 833 Finland 835 Email: sahsan@cc.hut.fi 837 Lars Eggert 838 NetApp 839 Sonnenallee 1 840 Kirchheim 85551 841 Germany 843 Phone: +49 151 12055791 844 Email: lars@netapp.com 845 URI: http://eggert.org/ 847 8. References 849 8.1. Normative References 851 [I-D.keranen-mmusic-ice-address-selection] 852 Keraenen, A. and J. Arkko, "Update on Candidate Address 853 Selection for Interactive Connectivity Establishment 854 (ICE)", draft-keranen-mmusic-ice-address-selection-01 855 (work in progress), July 2012. 857 [I-D.singh-avtcore-mprtp] 858 Singh, V., Karkkainen, T., Ott, J., Ahsan, S., and L. 859 Eggert, "Multipath RTP (MPRTP)", draft-singh-avtcore- 860 mprtp-09 (work in progress), June 2014. 862 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 863 Requirement Levels", BCP 14, RFC 2119, March 1997. 865 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 866 Jacobson, "RTP: A Transport Protocol for Real-Time 867 Applications", STD 64, RFC 3550, July 2003. 869 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 870 Specifications: ABNF", STD 68, RFC 5234, January 2008. 872 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 873 (ICE): A Protocol for Network Address Translator (NAT) 874 Traversal for Offer/Answer Protocols", RFC 5245, April 875 2010. 877 [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and 878 Control Packets on a Single Port", RFC 5761, April 2010. 880 8.2. Informative References 882 [I-D.ietf-mmusic-rfc2326bis] 883 Schulzrinne, H., Rao, A., Lanphier, R., Westerlund, M., 884 and M. Stiemerling, "Real Time Streaming Protocol 2.0 885 (RTSP)", draft-ietf-mmusic-rfc2326bis-40 (work in 886 progress), February 2014. 888 [I-D.ietf-mmusic-rtsp-nat] 889 Goldberg, J., Westerlund, M., and T. Zeng, "A Network 890 Address Translator (NAT) Traversal Mechanism for Media 891 Controlled by Real-Time Streaming Protocol (RTSP)", draft- 892 ietf-mmusic-rtsp-nat-22 (work in progress), July 2014. 894 [I-D.ietf-mmusic-trickle-ice] 895 Ivov, E., Rescorla, E., and J. Uberti, "Trickle ICE: 896 Incremental Provisioning of Candidates for the Interactive 897 Connectivity Establishment (ICE) Protocol", draft-ietf- 898 mmusic-trickle-ice-01 (work in progress), February 2014. 900 [I-D.ivov-mmusic-trickle-ice-sip] 901 Ivov, E., Marocco, E., and C. Holmberg, "A Session 902 Initiation Protocol (SIP) usage for Trickle ICE", draft- 903 ivov-mmusic-trickle-ice-sip-02 (work in progress), June 904 2014. 906 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 907 A., Peterson, J., Sparks, R., Handley, M., and E. 908 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 909 June 2002. 911 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 912 with Session Description Protocol (SDP)", RFC 3264, June 913 2002. 915 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 916 Text on Security Considerations", BCP 72, RFC 3552, July 917 2003. 919 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 920 Description Protocol", RFC 4566, July 2006. 922 Appendix A. Change Log 924 Note to the RFC-Editor: please remove this section prior to 925 publication as an RFC. 927 A.1. Changes in draft-singh-mmusic-mprtp-sdp-extension-03 929 o Minor changes, updated refs. 931 A.2. Changes in draft-singh-mmusic-mprtp-sdp-extension-02 933 o Mainly editorial fixes. 935 o Changed DQ to DQUOTE in ABNF definition. 937 A.3. Changes in draft-singh-mmusic-mprtp-sdp-extension-01 939 o Added IPv6 address selection. 941 o Editorial fixes. 943 A.4. Changes in draft-singh-mmusic-mprtp-sdp-extension-00 945 o The document is created by splitting the draft-singh-avtcore- 946 mprtp-04 into 2 parts. The RTP related stuff is kept in the 947 former while the SDP related discussion is moved to this new 948 document. 950 Authors' Addresses 952 Varun Singh 953 Aalto University 954 School of Electrical Engineering 955 Otakaari 5 A 956 Espoo, FIN 02150 957 Finland 959 Email: varun@comnet.tkk.fi 960 URI: http://www.netlab.tkk.fi/~varun/ 962 Joerg Ott 963 Aalto University 964 School of Electrical Engineering 965 Otakaari 5 A 966 Espoo, FIN 02150 967 Finland 969 Email: jo@comnet.tkk.fi 971 Teemu Karkkainen 972 Aalto University 973 School of Electrical Engineering 974 Otakaari 5 A 975 Espoo, FIN 02150 976 Finland 978 Email: teemuk@comnet.tkk.fi 980 Ralf Globisch 981 Fraunhofer HHI 982 Einsteinufer 37 983 Berlin D-10587 984 Germany 986 Email: ralf.globisch@gmail.com 987 Thomas Schierl 988 Fraunhofer HHI 989 Einsteinufer 37 990 Berlin D-10587 991 Germany 993 Phone: +49-30-31002-227 994 Email: ts@thomas-schierl.de