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> >
- Re: [MMUSIC] What is an m-line? Paul Kyzivat
- Re: [MMUSIC] What is an m-line? Colin Perkins
- Re: [MMUSIC] What is an m-line? Bernard Aboba
- [MMUSIC] What is an m-line? Martin Thomson
- Re: [MMUSIC] What is an m-line? Paul Kyzivat
- Re: [MMUSIC] What is an m-line? Bernard Aboba
- Re: [MMUSIC] What is an m-line? Jonathan Lennox
- Re: [MMUSIC] What is an m-line? Martin Thomson
- Re: [MMUSIC] What is an m-line? Martin Thomson
- Re: [MMUSIC] What is an m-line? Cullen Jennings (fluffy)
- Re: [MMUSIC] What is an m-line? Martin Thomson
- Re: [MMUSIC] What is an m-line? Colin Perkins
- Re: [MMUSIC] What is an m-line? Kevin Dempsey
- Re: [MMUSIC] What is an m-line? Martin Thomson
- Re: [MMUSIC] What is an m-line? Colin Perkins
- Re: [MMUSIC] What is an m-line? Harald Alvestrand
- Re: [MMUSIC] What is an m-line? Bernard Aboba
- Re: [MMUSIC] What is an m-line? Martin Thomson
- Re: [MMUSIC] What is an m-line? Emil Ivov
- Re: [MMUSIC] What is an m-line? Martin Thomson
- Re: [MMUSIC] What is an m-line? Emil Ivov
- Re: [MMUSIC] What is an m-line? Martin Thomson
- Re: [MMUSIC] What is an m-line? Emil Ivov
- Re: [MMUSIC] What is an m-line? Paul Kyzivat
- Re: [MMUSIC] What is an m-line? Paul Kyzivat
- Re: [MMUSIC] What is an m-line? Paul Kyzivat
- Re: [MMUSIC] What is an m-line? Harald Alvestrand
- Re: [MMUSIC] What is an m-line? Paul Kyzivat
- Re: [MMUSIC] What is an m-line? Suhas Nandakumar