Re: [AVTCORE] Comments on draft-singh-avt-mprtp-01

[varun singh <[e-mail]>]

Hi Ye-kui,

comments inline

On Tue, Feb 8, 2011 at 02:15, Wangyekui <[e-mail]> wrote:
> -          First of all, I think this draft initiated a very useful work. For example, today, many mobile operators have deployed dual-plane IP bearer networks, wherein a multipath version of RTP can be used for real-time communications such as voice- and video-over-IP services. BTW, you may want to mention this in the introduction section.

Can you elaborate on what is a dual-plane IP bearer.


> -          The draft specifies the negotiation of multiple paths is through upgrading from a single-path session and using in-band signaling (i.e. RTP header extension) for indication of additional paths. Would it be better to negotiate the use of one or more of the available paths out-of-band (i.e. using SDP)? One problem with in-band negotiation is that, if the initial path happens to be broken, then even the session setup would fail. Another problem is that in-band information may get lost (and when it happens the negotiation would fail).

If the initial path is broken then it would also fail for the case of
single path RTP. In the spec we allow for ICE and SDP. SDP is too slow
to always negotiate.

> -          In some cases, it may be useful to use multiple paths concurrently, for improved throughput. In some other cases, it may be more desirable to use only a subset of available paths at any time instance. For example, in mobile networks using dual-plane IP bearer, typically the better-performing path is used, while the other path is kept there for fast fallback when the path being used has problem. Therefore, it would be desirable if signaling of such a capability/preference is possible.
>

This is a good point and the draft aims to have basic mechanisms
first. Profiles to be added later, may be to the same document or as a
different draft. We'll add this inside as an editor's note.


> -          Finally, it would be useful if it is possible to indicate more path specific information when advertising paths (or “interfaces” as used in the draft), e.g., which of the two planes in a network using dual-plane IP bearer. It might be sufficient if there is a hook specified to enable backwards compatible extensions when the potential multipath RTP standard is used in the future by application system standards.

We need to stay independent of network architecture or infrastructure.
However, can you elaborate on the extension that can signal a path's
characteristic?


Regards,
Varun