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

Suhas Nandakumar <> Thu, 23 May 2013 09:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4460A21F8E9A for <>; Thu, 23 May 2013 02:05:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.799
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id HgX2mekoCJxd for <>; Thu, 23 May 2013 02:04:56 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 0728F21F8D94 for <>; Thu, 23 May 2013 02:04:55 -0700 (PDT)
Received: by with SMTP id 2so1044010qea.21 for <>; Thu, 23 May 2013 02:04:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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 with SMTP id m6mr10842253qad.39.1369299895512; Thu, 23 May 2013 02:04:55 -0700 (PDT)
Received: by with HTTP; Thu, 23 May 2013 02:04:55 -0700 (PDT)
In-Reply-To: <>
References: <> <>
Date: Thu, 23 May 2013 02:04:55 -0700
Message-ID: <>
From: Suhas Nandakumar <>
To: Paul Kyzivat <>
Content-Type: multipart/alternative; boundary="20cf3074b7b0dd0e6804dd5ef9c4"
Subject: Re: [MMUSIC] What is an m-line?
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 23 May 2013 09:05:00 -0000

On Mon, May 13, 2013 at 12:02 PM, Paul Kyzivat <>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 :)


>         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 mailing list