Subject: [AVTCORE] New Version Notification for draft-singh-avtcore-mprtp-04.txt

From: Varun Singh <[email-masked]>
Date: Mon, 27 Feb 2012 12:37:08 +0200

Hi,

We have submitted an updated draft for Multipath RTP (MPRTP) and would
like the WG to review the draft and provide feedback.
The exact changes are:
https://tools.ietf.org/rfcdiff?url2=draft-singh-avtcore-mprtp-04.txt

The main changes are:
1. Advertising MPRTP interfaces can be done in RTCP or using SDP. Both
extensions are in the draft.
2. MPRTP multiplexes RTP and RTCP on a single port.
3. If an endpoint wants to do NAT traversal then it should use ICE
procedures and the Section 11 covers how it could be done. However,
using ICE is optional. So session can be setup using ICE and without
ICE (Examples for session setup are in Section 11.6).
4. Using MPRTP with RTSP 2.0

There are still some open issues, mainly related to advertising
interfaces in RTCP (in-band) and in SDP (out-of-band). In some
situations advertising in RTCP is less complex, especially, if the
interfaces were already offered as ICE candidates and connectivity
checks were successful.

Security considerations for sending interface advertisements in RTCP
(without ICE) are still pending and will be covered in the coming
iterations.

Cheers,
Varun

Begin forwarded message:
> A new version of I-D, draft-singh-avtcore-mprtp-04.txt has been successfully submitted by Varun Singh and posted to the IETF repository.
>
> Filename:      draft-singh-avtcore-mprtp
> Revision:      04
> Title:                 Multipath RTP (MPRTP)
> Creation date:         2012-02-27
> WG ID:                 Individual Submission
> Number of pages: 49
>
> Abstract:
>   The Real-time Transport Protocol (RTP) is used to deliver real-time
>   content and, along with the RTP Control Protocol (RTCP), forms the
>   control channel between the sender and receiver.  However, RTP and
>   RTCP assume a single delivery path between the sender and receiver
>   and make decisions based on the measured characteristics of this
>   single path.  Increasingly, endpoints are becoming multi-homed, which
>   means that they are connected via multiple Internet paths.  Network
>   utilization can be improved when endpoints use multiple parallel
>   paths for communication.  The resulting increase in reliability and
>   throughput can also enhance the user experience.  This document
>   extends the Real-time Transport Protocol (RTP) so that a single
>   session can take advantage of the availability of multiple paths
>   between two endpoints.
>
>
>
>
> The IETF Secretariat