Re: [MMUSIC] What is an m-line?

Suhas Nandakumar <suhasietf@gmail.com> Thu, 23 May 2013 09:05 UTC

Return-Path: <suhasietf@gmail.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4460A21F8E9A for <mmusic@ietfa.amsl.com>; Thu, 23 May 2013 02:05:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.799
X-Spam-Level:
X-Spam-Status: No, score=-0.799 tagged_above=-999 required=5 tests=[AWL=-1.766, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, MANGLED_FORM=2.3, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HgX2mekoCJxd for <mmusic@ietfa.amsl.com>; Thu, 23 May 2013 02:04:56 -0700 (PDT)
Received: from mail-qe0-f48.google.com (mail-qe0-f48.google.com [209.85.128.48]) by ietfa.amsl.com (Postfix) with ESMTP id 0728F21F8D94 for <mmusic@ietf.org>; Thu, 23 May 2013 02:04:55 -0700 (PDT)
Received: by mail-qe0-f48.google.com with SMTP id 2so1044010qea.21 for <mmusic@ietf.org>; Thu, 23 May 2013 02:04:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=QUrmdo+mk70mHeiTcR7vz6Nyxg06KEsFagVsNkh9E4M=; b=jYcyimkocGfGZyxRVF8N3/aRpCCTiKiXKVm3t/AJB0NQ1UsDkjpv7G/2OfDK8R0utW cMuzk1Ujiw9ODfApkiK5av4gsc/7zYyhBlfALYXObXtJBrLjdpozj8Hy+ZPraGQM0u+5 jHcC3Tj2Ei5ycyBTCTf8Zg9q0uwtp55SXpoH5vJWa5mQSI8ynDlHuq80lAQPCYqmvJpW hC9aoQXG2ZTIebHzS8yOJadeIAUW/Pt6T1GiC6QhRX2VWXwRuZVpeTL6UJGCH55w/Aa5 QvlmKBjp+DOekUlUroGPirBlUlXg/1rXwHeLNhUOcAX0aYOqR4zSQbXSVNyFzrrCUS2n stDQ==
MIME-Version: 1.0
X-Received: by 10.224.34.198 with SMTP id m6mr10842253qad.39.1369299895512; Thu, 23 May 2013 02:04:55 -0700 (PDT)
Received: by 10.49.25.14 with HTTP; Thu, 23 May 2013 02:04:55 -0700 (PDT)
In-Reply-To: <519138CB.5020202@alum.mit.edu>
References: <CABkgnnWPWMLEecfqksGJrWrqvsu44gts48igUiLyiVV0iPhwQQ@mail.gmail.com> <519138CB.5020202@alum.mit.edu>
Date: Thu, 23 May 2013 02:04:55 -0700
Message-ID: <CAMRcRGQJjiLVhV=U2nrKErgHaSY3HhVxmZt3HzzvbdQCikEfTQ@mail.gmail.com>
From: Suhas Nandakumar <suhasietf@gmail.com>
To: Paul Kyzivat <pkyzivat@alum.mit.edu>
Content-Type: multipart/alternative; boundary="20cf3074b7b0dd0e6804dd5ef9c4"
Cc: mmusic@ietf.org
Subject: Re: [MMUSIC] What is an m-line?
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 23 May 2013 09:05:00 -0000

On Mon, May 13, 2013 at 12:02 PM, Paul Kyzivat <pkyzivat@alum.mit.edu>wrote:

> On 5/13/13 2:42 PM, Martin Thomson wrote:
>
>> We've had a great deal of discussion about plan A and B and the
>> various interactions of these proposals with bundling.  But I still
>> don't get a good sense that there is a working consensus on what an
>> m-line actually represents.
>>
>> I think that we've each reached our own conclusions, but they
>> definitely are not consistent.  We need a well-understood semantic for
>> m-lines if we have any chance of resolving these issues; Plan A/B
>> being only the first RTCWEB problem to address.
>>
>> RFC 4566 is helpfully devoid of detail, so we are free to come up with
>> any interpretation we choose.  Here are the ones that I have seen:
>>
>>   1. an m-line represents a single RTP session
>>      (or at least the part of the session that touches the client)
>>      This appears to be consistent with the Plan B approach
>>
>
> Well, it was my impression that Plan B still intends to allow bundling in
> order to combine audio and video into a single RTP session. So in that case
> neither of the m-lines represents a single RTP session in full.
>
>
>    2. an m-line represents the set of RTP streams that decode into a
>> single rendering, including layers, simulcast and FEC
>>
>
> Hmm. I was thinking *this* was what Cullen intended by Plan A.
> But now that you bring it up, I thing there is some existing SDP syntax
> for simulcast/FEC/FID that might only work with (3). (But I don't have the
> details of that stuff in my head.)
>
>
>    3. an m-line represents a single RTP stream; multiple m-lines might
>> be required to obtain a single rendering if it uses layers, simulcast,
>> FEC or FID groupings
>>      This appears to be consistent with the Plan A approach
>>
>
> I offer another try:
>
> 4. an m-line represents one or more (zero or more?)
> sources/flows/tracks/captures (pick the name that suits you) that share a
> single RTP session and that all are consistent with the media description
> accompanying the m-line.
>
> IIUC this is what Plan B is trying to achieve.
>
>
        I think trying to describe a m=line based on the usage isn't the
right way. Since each approach, either Plan A or Plan B or Plan Z can
choose to add/remove aspects of the description in defining a m=line. In
general all the above can be m=line.

Media description as understood by RFC4566 is a way to describe aspects of
media stream from a sender to a receiver. It should be able to describe
    - underlying transport context
    - media context (encoder/decoder)
   most importantly

How such  description(s) is/are mapped to the underlying RTP session(s)  or
how is it mapped to source and sinks or how  relationships is established
is just a matter of choice as enforced by the usage.

Hence i feel this question turns out to be more philosophical to me :)


./Suhas


>         Thanks,
>         Paul
>
>
>  In the first instance, an m-line can be multiple "things".  In the
>> latter two cases, an m-line is consistently one "thing" (or part
>> thereof).
>>
>> The first interpretation has a natural advantage in terms of signaling
>> economy and natural bundling.  The latter interpretations seem to have
>> advantages in dealing with call transfer and SSRC renumbering.
>>
>> So, which is correct?
>> ______________________________**_________________
>> mmusic mailing list
>> mmusic@ietf.org
>> https://www.ietf.org/mailman/**listinfo/mmusic<https://www.ietf.org/mailman/listinfo/mmusic>
>>
>>
> ______________________________**_________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/**listinfo/mmusic<https://www.ietf.org/mailman/listinfo/mmusic>
>