idnits 2.17.1 draft-singh-mmusic-mprtp-sdp-extension-03.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 (January 13, 2014) is 3750 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-06 ** Obsolete normative reference: RFC 5245 (Obsoleted by RFC 8445, RFC 8839) == Outdated reference: A later version (-40) exists of draft-ietf-mmusic-rfc2326bis-34 == Outdated reference: A later version (-22) exists of draft-ietf-mmusic-rtsp-nat-16 == Outdated reference: A later version (-02) exists of draft-ietf-mmusic-trickle-ice-00 == Outdated reference: A later version (-02) exists of draft-ivov-mmusic-trickle-ice-sip-00 -- Obsolete informational reference (is this intentional?): RFC 4566 (Obsoleted by RFC 8866) Summary: 1 error (**), 0 flaws (~~), 7 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: July 17, 2014 Aalto University 6 R. Globisch 7 T. Schierl 8 Fraunhofer HHI 9 January 13, 2014 11 Multipath RTP (MPRTP) attribute in Session Description Protocol 12 draft-singh-mmusic-mprtp-sdp-extension-03 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 July 17, 2014. 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 . . . . . . . . . . . . 8 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 . . . . . . . . . . . . . . . . . . 15 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 . . . . . . . . . . . . . . . . . . . . . 17 85 4.1.1. "mprtp" attribute . . . . . . . . . . . . . . . . . . 17 86 4.2. RTSP . . . . . . . . . . . . . . . . . . . . . . . . . . 17 87 4.2.1. RTSP Feature Tag . . . . . . . . . . . . . . . . . . 17 88 4.2.2. RTSP Transport Parameters . . . . . . . . . . . . . . 18 89 4.2.3. Notify-Reason value . . . . . . . . . . . . . . . . . 18 90 5. Security Considerations . . . . . . . . . . . . . . . . . . . 18 91 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 92 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 18 93 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 94 8.1. Normative References . . . . . . . . . . . . . . . . . . 19 95 8.2. Informative References . . . . . . . . . . . . . . . . . 20 96 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 20 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 . . . . . . . . . . . . . . . . . . . . . . . 21 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 370 In this example, the endpoint first sends its ICE candidates in the 371 initial offer and the other endpoint answers with its ICE candidates. 373 Initial offer (with ICE candidates): 375 Offer: 376 v=0 377 o=alice 2890844526 2890844527 IN IP4 192.0.2.1 378 s= 379 c=IN IP4 192.0.2.1 380 t=0 0 381 a=ice-pwd:asd88fgpdd777uzjYhagZg 382 a=ice-ufrag:8hhY 383 a=mprtp 384 m=video 49170 RTP/AVP 98 385 a=rtpmap:98 H264/90000 386 a=fmtp:98 profile-level-id=42A01E; 387 a=rtcp-mux 388 a=candidate:1 1 UDP 2130706431 192.0.2.1 49170 typ host 389 a=candidate:2 1 UDP 1694498815 198.51.100.1 51372 typ host 391 Answer: 392 v=0 393 o=bob 2890844528 2890844529 IN IP4 192.0.2.2 394 s= 395 c=IN IP4 192.0.2.2 396 t=0 0 397 a=ice-pwd:YH75Fviy6338Vbrhrlp8Yh 398 a=ice-ufrag:9uB6 399 a=mprtp 400 m=video 4000 RTP/AVP 98 401 a=rtpmap:98 H264/90000 402 a=fmtp:98 profile-level-id=42A01E; 403 a=rtcp-mux 404 a=candidate:1 1 UDP 2130706431 192.0.2.2 4000 typ host 406 Thereafter, each endpoint conducts ICE connectivity checks and when 407 sufficient number of connectivity checks succeed, the endpoint sends 408 an updated offer. In the updated offer, the endpoint advertises its 409 multiple interfaces for MPRTP. 411 Updated offer (with MPRTP interfaces): 413 Offer: 414 v=0 415 o=alice 2890844526 2890844527 IN IP4 192.0.2.1 416 s= 417 c=IN IP4 192.0.2.1 418 t=0 0 419 m=video 49170 RTP/AVP 98 420 a=rtpmap:98 H264/90000 421 a=fmtp:98 profile-level-id=42A01E; 422 a=rtcp-mux 423 a=candidate:1 1 UDP 2130706431 192.0.2.1 49170 typ host 424 a=candidate:2 1 UDP 1694498815 198.51.100.1 51372 typ host 425 a=mprtp interface:1 192.0.2.1:49170 426 a=mprtp interface:2 198.51.100.1:51372 428 Answer: 429 v=0 430 o=bob 2890844528 2890844529 IN IP4 192.0.2.2 431 s= 432 c=IN IP4 192.0.2.2 433 t=0 0 434 m=video 4000 RTP/AVP 98 435 a=rtpmap:98 H264/90000 436 a=fmtp:98 profile-level-id=42A01E; 437 a=rtcp-mux 438 a=candidate:1 1 UDP 2130706431 192.0.2.2 4000 typ host 439 a=mprtp interface:1 192.0.2.2:4000 441 2.4. Increased Throughput 443 The MPRTP layer MAY choose to augment paths to increase throughput. 444 If the desired media rate exceeds the current media rate, the 445 endpoints MUST renegotiate the application specific ("b=AS:xxx") 446 [RFC4566] bandwidth. 448 2.5. Increased Reliability 450 TBD 452 2.6. Decoding dependency 454 TBD 456 3. MPRTP in RTSP 458 Endpoints MUST use RTSP 2.0 [I-D.ietf-mmusic-rfc2326bis] for session 459 setup. Endpoints MUST multiplex RTP and RTCP on a single port 460 [RFC5761] and follow the recommendations made in Appendix C of 461 [I-D.ietf-mmusic-rfc2326bis]. 463 3.1. Solution Overview without ICE 465 1. The RTSP Server should include all of its interfaces via the SDP 466 attribute ("a=mprtp interface") in the RTSP DESCRIBE message. 468 2. The RTSP Client should include its multiple interfaces in the 469 RTSP SETUP message using the new attribute ("dest_mprtp_addr=") 470 in the Transport header. 472 3. The RTSP Server responds to the RTSP SETUP message with a 200 OK 473 containing its MPRTP interfaces (using the "src_mprtp_header=") 474 in the Transport header. After this, the RTSP Client can issue a 475 PLAY request. 477 4. If a new interface appears or an existing one disappear at the 478 RTSP Client during playback, it should send a new RTSP SETUP 479 message containing the updated interfaces ("dest_mprtp_addr") in 480 the Transport header. 482 5. If a new interface appears or an existing one disappears at the 483 RTSP Server during playback, the RTSP Server should send a 484 PLAY_NOTIFY message with a new Notify-Reason: "src-mprtp- 485 interface-update". The request must contain the updated 486 interfaces ("dest_mprtp_addr") in the "MPRTP-Interfaces" header. 488 6. Alternatively, the RTSP Server or Client may use the RTCP (in- 489 band) mechanism to advertise their interfaces. 491 The overview is illustrated by means of an example: 493 C->S: DESCRIBE rtsp://server.example.com/fizzle/foo RTSP/2.0 494 CSeq: 111 495 User-Agent: PhonyClient 1.3 496 Accept: application/sdp, application/example 497 Supported: setup.mprtp, setup.rtp.rtcp.mux 499 S->C: RTSP/2.0 200 OK 500 CSeq: 111 501 Date: 23 Jan 2011 15:35:06 GMT 502 Server: PhonyServer 1.3 503 Content-Type: application/sdp 504 Content-Length: 367 505 Supported: setup.mprtp, setup.rtp.rtcp.mux 507 v=0 508 o=mprtp-rtsp-server 2890844526 2890844527 IN IP4 192.0.2.1 509 s= 510 c=IN IP4 192.0.2.1 511 t=0 0 512 m=video 49170 RTP/AVP 98 513 a=rtpmap:98 H264/90000 514 a=fmtp:98 profile-level-id=42A01E; 515 a=extmap:1 urn:ietf:params:rtp-hdrext:mprtp 516 a=rtcp-mux 517 a=mprtp interface:1 192.0.2.1:49170 518 a=mprtp interface:2 198.51.100.1:51372 520 On receiving the response to the RTSP DESCRIBE message, the RTSP 521 Client sends an RTSP SETUP message containing its MPRTP interfaces in 522 the Transport header using the "dest_mprtp_addr=" attribute. The 523 RTSP Server responds with a 200 OK containing both the RTSP Client's 524 and the RTSP Server's MPRTP interfaces. 526 C->S: SETUP rtsp://server.example.com/fizzle/foo/audio RTSP/2.0 527 CSeq: 112 528 Transport: RTP/AVPF/UDP; unicast; dest_mprtp_addr=" 529 1 192.0.2.2 4000"; RTCP-mux, 530 RTP/AVP/UDP; unicast; dest_addr=":6970"/":6971", 531 RTP/AVP/TCP;unicast;interleaved=0-1 532 Accept-Ranges: NPT, UTC 533 User-Agent: PhonyClient 1.3 534 Supported: setup.mprtp, setup.rtp.rtcp.mux 536 S->C: RTSP/2.0 200 OK 537 CSeq: 112 538 Session: 12345678 539 Transport: RTP/AVPF/UDP; unicast; dest_mprtp_addr=" 540 1 192.0.2.2 4000"; 541 src_mprtp_addr="1 192.0.2.1 49170; 542 2 198.51.100.1 51372"; RTCP-mux 543 Accept-Ranges: NPT 544 Date: 23 Jan 2012 15:35:06 GMT 545 Server: PhonyServer 1.3 546 Supported: setup.mprtp, setup.rtp.rtcp.mux 548 The RTSP Client can issue a PLAY request on receiving the 200 OK and 549 media can start to stream once the RTSP Server receives the PLAY 550 request. 552 3.2. Solution Overview with ICE 554 This overview uses the ICE mechanisms [I-D.ietf-mmusic-rtsp-nat] 555 defined for RTSP 2.0 [I-D.ietf-mmusic-rfc2326bis]. 557 1. The RTSP Server should include the "a=rtsp-ice-d-m" attribute and 558 also indicate that it supports MPRTP by including the "a=mprtp" 559 attribute in the SDP of the RTSP DESCRIBE message. 561 2. The client sends an RTSP SETUP message containing the D-ICE in 562 lower level transport and ICE candidates in the Transport header. 563 The RTSP Server and Client then follow the procedures (Steps 2 to 564 8) described in [I-D.ietf-mmusic-rtsp-nat]. 566 3. When the connectivity checks conclude, the RTSP Client can send 567 an updated RTSP SETUP message with its MPRTP interfaces (ICE 568 candidates that were successful) in the Transport header 569 ("dest_mprtp_addr="). The RTSP Server responds to the RTSP SETUP 570 message with a 200 OK containing its MPRTP interfaces (ICE 571 candidates that were successful) in the Transport header 572 ("src_mprtp_header="). After receiving the 200 OK, the RTSP 573 Client can issue the PLAY request. 575 4. Alternatively, after the connectivity checks conclude, the RTSP 576 Client can issue the PLAY request (Step 9 and 10 of 577 [I-D.ietf-mmusic-rtsp-nat]) and the endpoints can use the RTCP 578 (in-band) mechanism to advertise their interfaces. 580 5. If a new interface appears or an existing one disappears, the 581 RTSP Client should issue an updated SETUP message with the new 582 candidates (See Section 5.12 of [I-D.ietf-mmusic-rtsp-nat]) or 583 the RTSP Server should send a PLAY_NOTIFY message (See 584 Section 5.13 of [I-D.ietf-mmusic-rtsp-nat]). After connectivity 585 checks succeed for the new interfaces, the RTSP Client can 586 proceed with the instructions in Step 3 or 4. 588 The overview is illustrated by means of an example: 590 C->S: DESCRIBE rtsp://server.example.com/foo RTSP/2.0 591 CSeq: 312 592 User-Agent: PhonyClient 1.3 593 Accept: application/sdp, application/example 594 Supported: setup.mprtp, setup.ice-d-m, setup.rtp.rtcp.mux 596 S->C: RTSP/2.0 200 OK 597 CSeq: 312 598 Date: 23 Jan 2012 15:35:06 GMT 599 Server: PhonyServer 1.3 600 Content-Type: application/sdp 601 Content-Length: 367 602 Supported: setup.mprtp, setup.ice-d-m, setup.rtp.rtcp.mux 604 v=0 605 o=mprtp-rtsp-server 2890844526 2890842807 IN IP4 192.0.2.1 606 s=SDP Seminar 607 i=A Seminar on the session description protocol 608 u=http://www.example.com/lectures/sdp.ps 609 e=seminar@example.com (Seminar Management) 610 t=2873397496 2873404696 611 a=recvonly 612 a=rtsp-ice-d-m 613 a=control: * 614 m=video 49170 RTP/AVP 98 615 a=rtpmap:98 H264/90000 616 a=fmtp:98 profile-level-id=42A01E; 617 a=rtcp-mux 618 a=mprtp 619 a=control: /video 621 C->S: SETUP rtsp://server.example.com/foo/video RTSP/2.0 622 CSeq: 302 623 Transport: RTP/AVP/D-ICE; unicast; ICE-ufrag=9uB6; 624 ICE-Password=YH75Fviy6338Vbrhrlp8Yh; 625 candidates="1 1 UDP 2130706431 192.0.2.2 626 4000 typ host"; RTCP-mux, 627 RTP/AVP/UDP; unicast; dest_addr=":6970"/":6971", 628 RTP/AVP/TCP;unicast;interleaved=0-1 629 Accept-Ranges: NPT, UTC 630 User-Agent: PhonyClient 1.3 631 Supported: setup.mprtp, setup.ice-d-m, setup.rtp.rtcp.mux 633 S->C: RTSP/2.0 200 OK 634 CSeq: 302 635 Session: 12345678 636 Transport: RTP/AVP/D-ICE; unicast; RTCP-mux; 637 ICE-ufrag=8hhY; ICE-Password= 638 asd88fgpdd777uzjYhagZg; candidates=" 639 1 1 UDP 2130706431 192.0.2.1 49170 typ host; 640 2 1 UDP 1694498815 198.51.100.1 51372 typ host" 641 Accept-Ranges: NPT 642 Date: 23 Jan 2012 15:35:06 GMT 643 Server: PhonyServer 1.3 644 Supported: setup.mprtp, setup.ice-d-m, setup.rtp.rtcp.mux 646 After the connectivity checks complete, the RTSP Client can send an 647 updated RTSP SETUP message containing the MPRTP interfaces for which 648 the connectivity checks were successful. These steps are the same as 649 the ones in the previous example. 651 3.3. RTSP Extensions 653 3.3.1. MPRTP Interface Transport Header Parameter 655 This section defines a new RTSP Transport parameter for carrying 656 MPRTP interfaces. The transport parameters may only occur once in 657 each transport specification. The parameter can contain one or more 658 MPRTP interfaces. If the RTSP Server supports MPRTP it MUST include 659 one or more MPRTP interfaces in the SETUP response. 661 trns-parameter = 663 trns-parameter =/ SEMI dest-mprtp-interface-par 664 trns-parameter =/ SEMI src-mprtp-interface-par 665 dest-mprtp-interface-par = "dest_mprtp_addr" EQUAL DQUOTE SWS 666 interface *(SEMI interface) SWS DQUOTE 667 src-mprtp-interface-par = "src_mprtp_addr" EQUAL DQUOTE SWS 668 interface *(SEMI interface) SWS DQUOTE 670 interface = counter SP 671 unicast-address SP 672 rtp_port SP 673 *(SP interface-description-extension) 675 counter = See section 2.3.1 676 unicast-address = See section 2.3.1 677 rtp_port = See section 2.3.1 678 interface-description-extension = See section 2.3.1 679 EQUAL = 680 DQUOTE = 681 SWS = 682 SEMI = 684 3.3.2. MPRTP Feature Tag 686 A feature tag is defined for indicating MPRTP support in the RTSP 687 capabilities mechanism: "setup.mprtp". This feature tag indicates 688 that the endpoint supports all the mandatory extensions defined in 689 this specification and is applicable to all types of RTSP agents; 690 clients, servers and proxies. 692 The MPRTP compliant RTSP Client MUST send the feature tag 693 "setup.mprtp" in the "Supported" header of all DESCRIBE and SETUP 694 requests. 696 3.3.3. Status Codes 698 TBD 700 3.3.4. New Reason for PLAY_NOTIFY 702 A new value used in the PLAY_NOTIFY methods Notify-Reason header is 703 defined: "src-mprtp-interface-update". This reason indicates that 704 the RTSP Server has updated set of MPRTP interfaces. 706 Notify-Reas-val =/ "src-mprtp-interface-update" 708 PLAY_NOTIFY requests with Notify-Reason header set to src-mprtp- 709 interface-update MUST include a mprtp-interfaces header. 711 mprtp-interfaces = "mprtp-interfaces" HCOLON interface 712 *(COMMA interface) 713 interface = counter SP 714 unicast-address SP 715 rtp_port SP 716 *(SP interface-description-extension) 718 counter = See section 2.3.1 719 unicast-address = See section 2.3.1 720 rtp_port = See section 2.3.1 721 interface-description-extension = See section 2.3.1 723 Example: 725 S->C: PLAY_NOTIFY rtsp://server.example.com/foo RTSP/2.0 726 CSeq: 305 727 Notify-Reason: src-mprtp-interface-update 728 Session: 12345678 729 mprtp-interfaces: 2 192.0.2.10 48211, 3 198.51.100.11 38703 730 Server: PhonyServer 1.3 732 C->S: RTSP/2.0 200 OK 733 CSeq: 305 734 User-Agent: PhonyClient 1.3 736 3.3.5. Re-SETUP 738 The server SHALL support SETUP requests in PLAYING state if it is 739 only updating the transport parameter (dest_mprtp_addr). If the 740 session is established using ICE then the RTSP Server and Client MUST 741 also follow the procedures described for Re-SETUP in 742 [I-D.ietf-mmusic-rtsp-nat]. 744 4. IANA Considerations 746 The following contact information shall be used for all registrations 747 in this document: 749 Contact: Varun Singh 750 mailto:varun.singh@iki.fi 751 tel:+358-9-470-24785 753 Note to the RFC-Editor: When publishing this document as an RFC, 754 please replace "RFC XXXX" with the actual RFC number of this document 755 and delete this sentence. 757 4.1. SDP Attributes 759 4.1.1. "mprtp" attribute 761 o Attribute Name: MPRTP 763 o Long Form: Multipath RTP 765 o Type of Attribute: media-level 767 o Charset Considerations: The attribute is not subject to the 768 charset attribute. 770 o Purpose: This attribute is extended to signal one of many possible 771 interfaces for communication. These interface addresses may have 772 been validated using ICE procedures. 774 o Appropriate Values: Section 2.1.1 of RFC XXXX. 776 4.2. RTSP 778 This document requests registration in a number of registries for 779 RTSP. 781 4.2.1. RTSP Feature Tag 782 This document request that one RTSP 2.0 feature tag be registered in 783 the "RTSP 2.0 feature tag" registry: 785 setup.mprtp See Section 3.3.2. 787 4.2.2. RTSP Transport Parameters 789 This document requests that 2 transport parameters be registered in 790 RTSP 2.0's "Transport Parameters": 792 "dest_mprtp_addr": See Section 3.3.1. 794 "src_mprtp_addr": See Section 3.3.1. 796 4.2.3. Notify-Reason value 798 This document requests that one assignment be done in the RTSP 2.0 799 Notify-Reason header value registry. The defined value is: 801 "src-mprtp-interface-update": See Section 3.3.4. 803 5. Security Considerations 805 All drafts are required to have a security considerations section. 806 See RFC 3552 [RFC3552] for a guide. 808 6. Acknowledgements 810 Varun Singh, Saba Ahsan, and Teemu Karkkainen are supported by 811 Trilogy (http://www.trilogy-project.org), a research project 812 (ICT-216372) partially funded by the European Community under its 813 Seventh Framework Program. 815 The work of Varun Singh, Joerg Ott, Ralf Globisch and Thomas Schierl 816 has been partially supported by the European Institute of Innovation 817 and Technology (EIT) ICT Labs activity RCLD 11882. 819 The views expressed here are those of the author(s) only. Neither 820 the European Commission nor the EITICT labs is liable for any use 821 that may be made of the information in this document. 823 7. Contributors 825 Saba Ahsan 826 Aalto University 827 School of Science and Technology 828 Otakaari 5 A 829 Espoo, FIN 02150 830 Finland 832 Email: sahsan@cc.hut.fi 834 Lars Eggert 835 NetApp 836 Sonnenallee 1 837 Kirchheim 85551 838 Germany 840 Phone: +49 151 12055791 841 Email: lars@netapp.com 842 URI: http://eggert.org/ 844 8. References 846 8.1. Normative References 848 [I-D.keranen-mmusic-ice-address-selection] 849 Keraenen, A. and J. Arkko, "Update on Candidate Address 850 Selection for Interactive Connectivity Establishment 851 (ICE)", draft-keranen-mmusic-ice-address-selection-01 852 (work in progress), July 2012. 854 [I-D.singh-avtcore-mprtp] 855 Singh, V., Karkkainen, T., Ott, J., Ahsan, S., and L. 856 Eggert, "Multipath RTP (MPRTP)", draft-singh-avtcore- 857 mprtp-06 (work in progress), January 2013. 859 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 860 Requirement Levels", BCP 14, RFC 2119, March 1997. 862 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 863 Jacobson, "RTP: A Transport Protocol for Real-Time 864 Applications", STD 64, RFC 3550, July 2003. 866 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 867 Specifications: ABNF", STD 68, RFC 5234, January 2008. 869 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 870 (ICE): A Protocol for Network Address Translator (NAT) 871 Traversal for Offer/Answer Protocols", RFC 5245, April 872 2010. 874 [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and 875 Control Packets on a Single Port", RFC 5761, April 2010. 877 8.2. Informative References 879 [I-D.ietf-mmusic-rfc2326bis] 880 Schulzrinne, H., Rao, A., Lanphier, R., Westerlund, M., 881 and M. Stiemerling, "Real Time Streaming Protocol 2.0 882 (RTSP)", draft-ietf-mmusic-rfc2326bis-34 (work in 883 progress), April 2013. 885 [I-D.ietf-mmusic-rtsp-nat] 886 Goldberg, J., Westerlund, M., and T. Zeng, "A Network 887 Address Translator (NAT) Traversal mechanism for media 888 controlled by Real-Time Streaming Protocol (RTSP)", draft- 889 ietf-mmusic-rtsp-nat-16 (work in progress), May 2013. 891 [I-D.ietf-mmusic-trickle-ice] 892 Ivov, E., Rescorla, E., and J. Uberti, "Trickle ICE: 893 Incremental Provisioning of Candidates for the Interactive 894 Connectivity Establishment (ICE) Protocol", draft-ietf- 895 mmusic-trickle-ice-00 (work in progress), October 2013. 897 [I-D.ivov-mmusic-trickle-ice-sip] 898 Ivov, E., Marocco, E., and C. Holmberg, "A Session 899 Initiation Protocol (SIP) usage for Trickle ICE", draft- 900 ivov-mmusic-trickle-ice-sip-00 (work in progress), January 901 2013. 903 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 904 A., Peterson, J., Sparks, R., Handley, M., and E. 905 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 906 June 2002. 908 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 909 with Session Description Protocol (SDP)", RFC 3264, June 910 2002. 912 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 913 Text on Security Considerations", BCP 72, RFC 3552, July 914 2003. 916 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 917 Description Protocol", RFC 4566, July 2006. 919 Appendix A. Change Log 921 Note to the RFC-Editor: please remove this section prior to 922 publication as an RFC. 924 A.1. Changes in draft-singh-mmusic-mprtp-sdp-extension-03 926 o Minor changes, updated refs. 928 A.2. Changes in draft-singh-mmusic-mprtp-sdp-extension-02 930 o Mainly editorial fixes. 932 o Changed DQ to DQUOTE in ABNF definition. 934 A.3. Changes in draft-singh-mmusic-mprtp-sdp-extension-01 936 o Added IPv6 address selection. 938 o Editorial fixes. 940 A.4. Changes in draft-singh-mmusic-mprtp-sdp-extension-00 942 o The document is created by splitting the draft-singh-avtcore- 943 mprtp-04 into 2 parts. The RTP related stuff is kept in the 944 former while the SDP related discussion is moved to this new 945 document. 947 Authors' Addresses 949 Varun Singh 950 Aalto University 951 School of Electrical Engineering 952 Otakaari 5 A 953 Espoo, FIN 02150 954 Finland 956 Email: varun@comnet.tkk.fi 957 URI: http://www.netlab.tkk.fi/~varun/ 959 Joerg Ott 960 Aalto University 961 School of Electrical Engineering 962 Otakaari 5 A 963 Espoo, FIN 02150 964 Finland 966 Email: jo@comnet.tkk.fi 967 Teemu Karkkainen 968 Aalto University 969 School of Electrical Engineering 970 Otakaari 5 A 971 Espoo, FIN 02150 972 Finland 974 Email: teemuk@comnet.tkk.fi 976 Ralf Globisch 977 Fraunhofer HHI 978 Einsteinufer 37 979 Berlin D-10587 980 Germany 982 Email: ralf.globisch@gmail.com 984 Thomas Schierl 985 Fraunhofer HHI 986 Einsteinufer 37 987 Berlin D-10587 988 Germany 990 Phone: +49-30-31002-227 991 Email: ts@thomas-schierl.de