Subject: Re: [MMUSIC] SDP comments on draft-singh-avtcore-mprtp-02: General - Connectivity checks

From: Varun Singh <[email-masked]>
Date: Sun, 13 Nov 2011 18:41:09 +0800

Hi,
Apologies for the late reply.
I have incorporated most of the changes suggested by Christer and
Miguel and added some clarifications in some places. However, some
comments are still work in progress. You can find the changes in the
-03 draft (http://tools.ietf.org/rfcdiff?url2=draft-singh-avtcore-mprtp-03.txt)
1. About using STUN instead of RTCP for interface advertisementsThis
is still under consideration but we don't have an answer for this yet.
Our implementation uses RTCP (possibly because of the ease of
implementation)
2. In-band and Out-of-band interface advertisementWe have tried to
clarify this in the new revision but it probably requires some more
work (See http://tools.ietf.org/html/draft-singh-avtcore-mprtp-03#section-7.1.3)
- In case an endpoint receives an MPRTP interface advertisement (in
RTCP or in SDP), then it should respond using the same mechanism.- In
case of conflict between RTCP-based and SDP-based interface
advertisement, then at this instance the endpoints MUST advertise
using SDP.(if the endpoints send their interfaces independently at
roughly the same time, one in RTCP and the other in SDP then in this
particular instance they both should advertise using SDP.)
3. MPRTP in SDP
There are two ways of doing this:- MPRTP without ICE: directly
advertise the MPRTP interfaces (no need for connectivity checks)-
MPRTP with ICE: first advertise ICE candidates and after the
connectivity checks succeed, then advertise the MPRTP interfaces.

If an endpoint gets an interface advertisement without ICE then it
responds without ICE, else it responds with ICE.

We have included some basic examples in
http://tools.ietf.org/html/draft-singh-avtcore-mprtp-03#section-11.6
- TODO: More complex scenarios (when interfaces appear and disappear
mid-session).

Regards,
Varun

On Thu, Aug 18, 2011 at 21:04, Miguel A. Garcia
<[email-masked]> wrote:
> As an individual...
>
> Some comments to the connectivity checks of this draft.
>
> I basically agree with Christer. I find confusing several concepts that are
> highly mixed in the draft, namely:
>
> a) Whether ICE is mandatory or not
>
> b) The presence of two mechanisms for doing connectivity checks: ICE and the
> RTP built-in
>
> c) It seems to be mandated to do connectivity checks prior to using the
> MPRTP. This is something that currently is not mandated (unless you
> implement ICE). But if you implement vanilla RTP, you don't need to test the
> connectivity before you send or receive data.
>
> So, the recommendation to the authors is to avoid mandating connectivity
> tests, but having as an option.
>
> Use clear terminology: "STUN connectivity tests" versus "built-in RTP
> connectivity tests".
>
> This, of course, assuming that you still want to support both types of
> connectivity test, something that is arguable.
>
> /Miguel
>
>
> On 03/08/2011 22:54, Christer Holmberg wrote:
>>
>> Hi,
>>
>> Below are some general comments on the connectivity checks. More specific
>> comments will be found in my e-mails commending the individual sections.
>>
>> Regards,
>>
>> Christer
>>
>>
>> Connectivity checks:
>>
>>        FU_GEN-1: The document defines a new type of connectivity check. We
>> should have a
>>        discussion whether that's a good thing to do or not, but assuming
>> it will be done,
>>        as I also indicate in my editorial comments, you need to more
>> clearly define the "RTCP
>>        connectivity checks" somewhere in the document, and then refer to
>> it.
>>
>>        I think you also need to describe the characteristic differences
>> (security etc)
>>        compared to STUN connectivity checks, and I think you should have
>> some text on why
>>        you define a new type of connectivity check in the first place
>> (rather than relying on
>>        STUN).
>> _______________________________________________
>> mmusic mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/mmusic
>>
>
> --
> Miguel A. Garcia
> +34-91-339-3608
> Ericsson Spain
>

-- 
http://www.netlab.tkk.fi/~varun/