]> Aalto University

School of Electrical Engineering Otakaari 5 A Espoo FIN 02150 Finland varun@comnet.tkk.fi http://www.netlab.tkk.fi/~varun/

Aalto University

School of Electrical Engineering Otakaari 5 A Espoo FIN 02150 Finland jo@comnet.tkk.fi

Aalto University

School of Electrical Engineering Otakaari 5 A Espoo FIN 02150 Finland teemuk@comnet.tkk.fi

Fraunhofer HHI

Einsteinufer 37 Berlin D-10587 Germany ralf.globisch@gmail.com

Fraunhofer HHI

Einsteinufer 37 Berlin D-10587 Germany +49-30-31002-227 ts@thomas-schierl.de

Internet Engineering Task Force MMUSIC Working Group RTP RTCP multipath streaming Multipath RTP (MPRTP) is an extension to the Real-time Transport Protocol (RTP) that allows multi-homed endpoints to take advantage of the availability of multiple Internet paths between endpoints to send/receive media packets. This document describes how to express the interface advertisement and negotiation during session setup in SDP (Session Description Protocol).

Multipath RTP (MPRTP) is an extension to RTP that allows splitting a single RTP stream into multiple subflows, which are then transmitted over different Internet paths. Multipath RTCP (MPRTCP) is an extension to RTCP. It is used along with MPRTP to report per-path sender and receiver characteristics. A Multipath RTP session can be set up in many possible ways e.g., during handshake, or upgraded mid-session. The capability exchange may be done using out-of-band signaling (e.g., Session Description Protocol (SDP) in Session Initiation Protocol (SIP), Real-Time Streaming Protocol (RTSP)) or using in-band signaling (e.g., in RTCP). This document defines an extension to the SDP attribute 'a=mprtp' defined in the base MPRTP specification. Using this extension an endpoint can advertise its multiple interfaces.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in .

The definitions for the words Endpoint, Interface, Path and Subflow in this document are as per .

The base Multipath RTP specification defines the 'a=mprtp' attribute to indicate support for MPRTP. In the following section, we extend the 'a=mprtp' attribute to advertise an endpoint's multiple interfaces in SDP instead of advertising the interfaces in-band in RTCP.

If the endpoint is aware of its multiple interfaces and wants to use them for MPRTP, it MAY use SDP to advertise these interfaces. Alternatively, it MAY use in-band signaling to advertise its interfaces, as defined in . The receiving endpoint MUST use the same mechanism to respond to an interface advertisement. In particular, if an endpoint receives an SDP containing multiple MPRTP interfaces, then it MUST respond to the offer in SDP with its set of MPRTP interfaces.

The interface attribute is an optional media-level attribute and is used to advertise an endpoint's interface address. The syntax of the interface attribute is defined using the following Augmented BNF, as defined in . The definitions of unicast-address, port, token, SP, and CRLF are according to RFC4566.

<mprtp-interface>: specifies one unicast IP address, the RTP port number of the endpoint (MPRTP uses RTP/RTCP port multiplexing). The unicast address with lowest counter value MUST match the connection address ('c=' line). Similarly, the RTP and RTCP ports MUST match the RTP and RTCP ports in the associated 'm=' line. The counter SHOULD start at 1 and increment with each additional interface. Multiple interface lines MUST be ordered in a decreasing priority level as is the case with the Interface Advertisement blocks in in-band signaling (See ). <unicast-address>: is taken from RFC4566. It is one of the IP addresses of the endpoint and allows the use of IPv4 addresses, IPv6 addresses and Fully Qualified Domain Names (FQDN). When choosing IPv6 addresses the endpoint MUST perform the IPv6 address prioritization and selection as proposed in . <port>: is from RFC4566. It is the RTP port associated with the unicast address and note that the RTP and RTCP ports are multiplexed for MPRTP subflows according to . <counter>: is a monotonically increasing positive integer starting at 1. The counter MUST reset for each media line. The counter value for an 'mprtp-interface' should remain the same for the session, unless the priorities of the interfaces change. [Editor's note: do we need a counter?] The 'mprtp-interface' can be extended using the 'interface-description-extension' parameter. An endpoint MUST ignore any extensions it does not understand.

The ABNF grammar is illustrated by means of an example:

If the endpoints intend to use ICE for discovering interfaces and running connectivity checks, the following two step procedure MUST be followed: Advertise ICE candidates: in the initial OFFER the endpoints exchange candidates, as defined in ICE. Thereafter the endpoints run connectivity checks. Advertise MPRTP interfaces: When a sufficient number of connectivity checks succeed, the endpoint MUST send an updated offer containing the interfaces that they want to use for MPRTP. When an endpoint uses ICE's regular nomination procedure, it chooses the best ICE candidate as the default path. In the case of an MPRTP endpoint, if the connectivity check of more than one ICE candidate succeeded, then an MPRTP endpoint MAY advertise (some of) these as MPRTP interfaces in an updated offer. When an endpoint uses ICE's aggressive nomination procedure, the selected candidate may change as more ICE checks complete. Instead of sending updated offers as additional ICE candidates appear (transience), the endpoint MAY use in-band signaling to advertise its interfaces, as defined in . Additionally, it MAY send an updated offer when the transience stabilizes. If the default interface disappears and the paths used for MPRTP are different from the one in the c= and m= lines then the 'mprtp interface' with the lowest counter value should be promoted to the c= and m= lines in the updated offer. When a new interface appears, then the application/endpoint should internally decide if it wishes to use it and sends an updated offer with ICE candidates of the new interface. The receiving endpoint responds to the offer with all its ICE candidates in the answer and starts connectivity checks between all its candidates and the offerer's new ICE candidate. Similarly, the initiating endpoint starts connectivity checks between the new interface and all the received ICE candidates in the answer. If the connectivity checks succeed, the initiating endpoint MAY send an updated offer with the new interface as an additional 'mprtp interface'. [Editor's Note: should we also consider using trickle ICE for MPRTP? Trickle ICE is introduced in: and for SIP in .]

When SDP is used to negotiate MPRTP interfaces (see ) following the offer/answer model , the collection of "a=mprtp interface" attribute lines indicates the interfaces the endpoint wishes to use for sending and/or receiving media data. The SDP offer MUST include this attribute at the media level. If the answerer wishes to also use SDP for advertising MPRTP interfaces, it MUST also include its interfaces at the media-level "a=mprtp interface" attribute in the answer. If the answer does not contain an "a=mprtp interface" attribute, the offerer MUST use in-band signaling for advertising interfaces. When SDP is used in a declarative manner, the presence of an "a=mprtp interface" attribute signals that the sender can send or receive media data over multiple interfaces. The receiver SHOULD be capable of streaming media to the multiple interfaces and be prepared to receive media from multiple interfaces. The following sections shows examples of SDP offer and answer for in-band and out-of-band signaling.

The following offer/answer shows that both the endpoints are MPRTP capable and SHOULD use in-band signaling for interfaces advertisements.

The endpoint MAY now use in-band RTCP signaling to advertise its multiple interfaces. Alternatively, it MAY make another offer with the interfaces in SDP (out-of-band signaling).

If multiple interfaces are included in an SDP offer then the MPRTP-capable receiver MUST respond to the request with an SDP answer containing one or more interfaces. If the SDP answer does not contain "a=mprtp", the offerer can conclude that the endpoint does not support MPRTP and continue the session using a single path.

In this example, the offerer advertises two interfaces and the answerer responds with a single interface description. The endpoint MAY use one or both paths depending on the end-to-end characteristics of each path.

In this example, the endpoint first sends its ICE candidates in the initial offer and the other endpoint answers with its ICE candidates. Initial offer (with ICE candidates):

Thereafter, each endpoint conducts ICE connectivity checks and when sufficient number of connectivity checks succeed, the endpoint sends an updated offer. In the updated offer, the endpoint advertises its multiple interfaces for MPRTP. Updated offer (with MPRTP interfaces):

The MPRTP layer MAY choose to augment paths to increase throughput. If the desired media rate exceeds the current media rate, the endpoints MUST renegotiate the application specific ("b=AS:xxx") bandwidth.

TBD

TBD

Endpoints MUST use RTSP 2.0 for session setup. Endpoints MUST multiplex RTP and RTCP on a single port and follow the recommendations made in Appendix C of .

The RTSP Server should include all of its interfaces via the SDP attribute ("a=mprtp interface") in the RTSP DESCRIBE message. The RTSP Client should include its multiple interfaces in the RTSP SETUP message using the new attribute ("dest_mprtp_addr=") in the Transport header. Do we need a new lower layer transport MPRTP?. The RTSP Server responds to the RTSP SETUP message with a 200 OK containing its MPRTP interfaces (using the "src_mprtp_header=") in the Transport header. After this, the RTSP Client can issue a PLAY request. If a new interface appears or an existing one disappear at the RTSP Client during playback, it should send a new RTSP SETUP message containing the updated interfaces ("dest_mprtp_addr") in the Transport header. Sending a Re-SETUP to update the interfaces during PLAY state would require a change in behavior of the server. Similar to Section 5.12 of [draft-ietf-mmusic-rtsp-nat]. If a new interface appears or an existing one disappears at the RTSP Server during playback, the RTSP Server should send a PLAY_NOTIFY message with a new Notify-Reason: "src-mprtp-interface-update". The request must contain the updated interfaces ("dest_mprtp_addr") in the "MPRTP-Interfaces" header. Alternatively, the RTSP Server or Client may use the RTCP (in-band) mechanism to advertise their interfaces. Does it make sense to advertise out-of-band (in RTSP SETUP) when advertising in-band in RTCP is less complex? The overview is illustrated by means of an example:

S: DESCRIBE rtsp://server.example.com/fizzle/foo RTSP/2.0 CSeq: 111 User-Agent: PhonyClient 1.3 Accept: application/sdp, application/example Supported: setup.mprtp, setup.rtp.rtcp.mux S->C: RTSP/2.0 200 OK CSeq: 111 Date: 23 Jan 2011 15:35:06 GMT Server: PhonyServer 1.3 Content-Type: application/sdp Content-Length: 367 Supported: setup.mprtp, setup.rtp.rtcp.mux v=0 o=mprtp-rtsp-server 2890844526 2890844527 IN IP4 192.0.2.1 s= c=IN IP4 192.0.2.1 t=0 0 m=video 49170 RTP/AVP 98 a=rtpmap:98 H264/90000 a=fmtp:98 profile-level-id=42A01E; a=extmap:1 urn:ietf:params:rtp-hdrext:mprtp a=rtcp-mux a=mprtp interface:1 192.0.2.1:49170 a=mprtp interface:2 198.51.100.1:51372 ]]>

On receiving the response to the RTSP DESCRIBE message, the RTSP Client sends an RTSP SETUP message containing its MPRTP interfaces in the Transport header using the "dest_mprtp_addr=" attribute. The RTSP Server responds with a 200 OK containing both the RTSP Client's and the RTSP Server's MPRTP interfaces.

S: SETUP rtsp://server.example.com/fizzle/foo/audio RTSP/2.0 CSeq: 112 Transport: RTP/AVPF/UDP; unicast; dest_mprtp_addr=" 1 192.0.2.2 4000"; RTCP-mux, RTP/AVP/UDP; unicast; dest_addr=":6970"/":6971", RTP/AVP/TCP;unicast;interleaved=0-1 Accept-Ranges: NPT, UTC User-Agent: PhonyClient 1.3 Supported: setup.mprtp, setup.rtp.rtcp.mux S->C: RTSP/2.0 200 OK CSeq: 112 Session: 12345678 Transport: RTP/AVPF/UDP; unicast; dest_mprtp_addr=" 1 192.0.2.2 4000"; src_mprtp_addr="1 192.0.2.1 49170; 2 198.51.100.1 51372"; RTCP-mux Accept-Ranges: NPT Date: 23 Jan 2012 15:35:06 GMT Server: PhonyServer 1.3 Supported: setup.mprtp, setup.rtp.rtcp.mux ]]>

The RTSP Client can issue a PLAY request on receiving the 200 OK and media can start to stream once the RTSP Server receives the PLAY request.

This overview uses the ICE mechanisms defined for RTSP 2.0. The RTSP Server should include the "a=rtsp-ice-d-m" attribute and also indicate that it supports MPRTP by including the "a=mprtp" attribute in the SDP of the RTSP DESCRIBE message. The client sends an RTSP SETUP message containing the D-ICE in lower level transport and ICE candidates in the Transport header. The RTSP Server and Client then follow the procedures (Steps 2 to 8) described in . When the connectivity checks conclude, the RTSP Client can send an updated RTSP SETUP message with its MPRTP interfaces (ICE candidates that were successful) in the Transport header ("dest_mprtp_addr="). The RTSP Server responds to the RTSP SETUP message with a 200 OK containing its MPRTP interfaces (ICE candidates that were successful) in the Transport header ("src_mprtp_header="). After receiving the 200 OK, the RTSP Client can issue the PLAY request. Alternatively, after the connectivity checks conclude, the RTSP Client can issue the PLAY request (Step 9 and 10 of ) and the endpoints can use the RTCP (in-band) mechanism to advertise their interfaces. If a new interface appears or an existing one disappears, the RTSP Client should issue an updated SETUP message with the new candidates (See Section 5.12 of ) or the RTSP Server should send a PLAY_NOTIFY message (See Section 5.13 of ). After connectivity checks succeed for the new interfaces, the RTSP Client can proceed with the instructions in Step 3 or 4. The overview is illustrated by means of an example:

S: DESCRIBE rtsp://server.example.com/foo RTSP/2.0 CSeq: 312 User-Agent: PhonyClient 1.3 Accept: application/sdp, application/example Supported: setup.mprtp, setup.ice-d-m, setup.rtp.rtcp.mux S->C: RTSP/2.0 200 OK CSeq: 312 Date: 23 Jan 2012 15:35:06 GMT Server: PhonyServer 1.3 Content-Type: application/sdp Content-Length: 367 Supported: setup.mprtp, setup.ice-d-m, setup.rtp.rtcp.mux v=0 o=mprtp-rtsp-server 2890844526 2890842807 IN IP4 192.0.2.1 s=SDP Seminar i=A Seminar on the session description protocol u=http://www.example.com/lectures/sdp.ps e=seminar@example.com (Seminar Management) t=2873397496 2873404696 a=recvonly a=rtsp-ice-d-m a=control: * m=video 49170 RTP/AVP 98 a=rtpmap:98 H264/90000 a=fmtp:98 profile-level-id=42A01E; a=rtcp-mux a=mprtp a=control: /video ]]>

S: SETUP rtsp://server.example.com/foo/video RTSP/2.0 CSeq: 302 Transport: RTP/AVP/D-ICE; unicast; ICE-ufrag=9uB6; ICE-Password=YH75Fviy6338Vbrhrlp8Yh; candidates="1 1 UDP 2130706431 192.0.2.2 4000 typ host"; RTCP-mux, RTP/AVP/UDP; unicast; dest_addr=":6970"/":6971", RTP/AVP/TCP;unicast;interleaved=0-1 Accept-Ranges: NPT, UTC User-Agent: PhonyClient 1.3 Supported: setup.mprtp, setup.ice-d-m, setup.rtp.rtcp.mux S->C: RTSP/2.0 200 OK CSeq: 302 Session: 12345678 Transport: RTP/AVP/D-ICE; unicast; RTCP-mux; ICE-ufrag=8hhY; ICE-Password= asd88fgpdd777uzjYhagZg; candidates=" 1 1 UDP 2130706431 192.0.2.1 49170 typ host; 2 1 UDP 1694498815 198.51.100.1 51372 typ host" Accept-Ranges: NPT Date: 23 Jan 2012 15:35:06 GMT Server: PhonyServer 1.3 Supported: setup.mprtp, setup.ice-d-m, setup.rtp.rtcp.mux ]]>

After the connectivity checks complete, the RTSP Client can send an updated RTSP SETUP message containing the MPRTP interfaces for which the connectivity checks were successful. These steps are the same as the ones in the previous example.

This section defines a new RTSP Transport parameter for carrying MPRTP interfaces. The transport parameters may only occur once in each transport specification. The parameter can contain one or more MPRTP interfaces. If the RTSP Server supports MPRTP it MUST include one or more MPRTP interfaces in the SETUP response.

trns-parameter =/ SEMI dest-mprtp-interface-par trns-parameter =/ SEMI src-mprtp-interface-par dest-mprtp-interface-par = "dest_mprtp_addr" EQUAL DQUOTE SWS interface *(SEMI interface) SWS DQUOTE src-mprtp-interface-par = "src_mprtp_addr" EQUAL DQUOTE SWS interface *(SEMI interface) SWS DQUOTE interface = counter SP unicast-address SP rtp_port SP *(SP interface-description-extension) counter = See section 2.3.1 unicast-address = See section 2.3.1 rtp_port = See section 2.3.1 interface-description-extension = See section 2.3.1 EQUAL = DQUOTE = SWS = SEMI = ]]>

A feature tag is defined for indicating MPRTP support in the RTSP capabilities mechanism: "setup.mprtp". This feature tag indicates that the endpoint supports all the mandatory extensions defined in this specification and is applicable to all types of RTSP agents; clients, servers and proxies. The MPRTP compliant RTSP Client MUST send the feature tag "setup.mprtp" in the "Supported" header of all DESCRIBE and SETUP requests.

TBD

A new value used in the PLAY_NOTIFY methods Notify-Reason header is defined: "src-mprtp-interface-update". This reason indicates that the RTSP Server has updated set of MPRTP interfaces.

PLAY_NOTIFY requests with Notify-Reason header set to src-mprtp-interface-update MUST include a mprtp-interfaces header.

Do we need to add a new header attribute?. Alternatively, the RTSP Server could just send the PLAY_NOTIFY and let the RTSP Client initiate a new RTSP SETUP message with its current interfaces and the RTSP Server can then respond with its updated set of interfaces. This will make it a 3-way exchange as opposed to a 1-way notification. Alternatively, using SET_PARAMETER reduces it to a 2-way exchange and can be initiated by both the RTSP Server and the RTSP Client. However, SET_PARAMETER can only be used when the endpoints are in SETUP state. Example:

C: PLAY_NOTIFY rtsp://server.example.com/foo RTSP/2.0 CSeq: 305 Notify-Reason: src-mprtp-interface-update Session: 12345678 mprtp-interfaces: 2 192.0.2.10 48211, 3 198.51.100.11 38703 Server: PhonyServer 1.3 C->S: RTSP/2.0 200 OK CSeq: 305 User-Agent: PhonyClient 1.3 ]]>

The server SHALL support SETUP requests in PLAYING state if it is only updating the transport parameter (dest_mprtp_addr). If the session is established using ICE then the RTSP Server and Client MUST also follow the procedures described for Re-SETUP in .

The following contact information shall be used for all registrations in this document:

Note to the RFC-Editor: When publishing this document as an RFC, please replace "RFC XXXX" with the actual RFC number of this document and delete this sentence.

Attribute Name: MPRTP Long Form: Multipath RTP Type of Attribute: media-level Charset Considerations: The attribute is not subject to the charset attribute. Purpose: This attribute is extended to signal one of many possible interfaces for communication. These interface addresses may have been validated using ICE procedures. Appropriate Values: of RFC XXXX.

This document requests registration in a number of registries for RTSP.

This document request that one RTSP 2.0 feature tag be registered in the "RTSP 2.0 feature tag" registry: setup.mprtp See .

This document requests that 2 transport parameters be registered in RTSP 2.0's "Transport Parameters": "dest_mprtp_addr": See . "src_mprtp_addr": See .

This document requests that one assignment be done in the RTSP 2.0 Notify-Reason header value registry. The defined value is: "src-mprtp-interface-update": See .

All drafts are required to have a security considerations section. See RFC 3552 for a guide.

Varun Singh, Saba Ahsan, and Teemu Karkkainen are supported by Trilogy (http://www.trilogy-project.org), a research project (ICT-216372) partially funded by the European Community under its Seventh Framework Program. The work of Varun Singh, Joerg Ott, Ralf Globisch and Thomas Schierl has been partially supported by the European Institute of Innovation and Technology (EIT) ICT Labs activity RCLD 11882. The views expressed here are those of the author(s) only. Neither the European Commission nor the EITICT labs is liable for any use that may be made of the information in this document.

&rfc2119; &rfc5245; &rfc3550; &rfc5234; &rfc5761; &I-D.singh-avtcore-mprtp; &I-D.keranen-mmusic-ice-address-selection; &rfc3552; &I-D.ietf-mmusic-rfc2326bis; &I-D.ietf-mmusic-rtsp-nat; &rfc3261; &rfc3264; &rfc4566; &I-D.ietf-mmusic-trickle-ice; &I-D.ivov-mmusic-trickle-ice-sip;

Note to the RFC-Editor: please remove this section prior to publication as an RFC.

Minor changes, updated refs.

Mainly editorial fixes. Changed DQ to DQUOTE in ABNF definition.

Added IPv6 address selection. Editorial fixes.

The document is created by splitting the draft-singh-avtcore-mprtp-04 into 2 parts. The RTP related stuff is kept in the former while the SDP related discussion is moved to this new document.