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

Bernard Aboba <bernard_aboba@hotmail.com> Wed, 15 May 2013 18:47 UTC

Return-Path: <bernard_aboba@hotmail.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 24CFA21F8ECB for <mmusic@ietfa.amsl.com>; Wed, 15 May 2013 11:47:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.426
X-Spam-Level:
X-Spam-Status: No, score=-102.426 tagged_above=-999 required=5 tests=[AWL=0.172, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
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 TlvAwY0Y3-VA for <mmusic@ietfa.amsl.com>; Wed, 15 May 2013 11:47:02 -0700 (PDT)
Received: from blu0-omc2-s16.blu0.hotmail.com (blu0-omc2-s16.blu0.hotmail.com [65.55.111.91]) by ietfa.amsl.com (Postfix) with ESMTP id 277C021F8F0C for <mmusic@ietf.org>; Wed, 15 May 2013 11:47:02 -0700 (PDT)
Received: from BLU169-W119 ([65.55.111.73]) by blu0-omc2-s16.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 15 May 2013 11:47:00 -0700
X-TMN: [+PzcR7r5xHYFfZCUQLxPezL2ViR9VOppp6poyGCJZR8=]
X-Originating-Email: [bernard_aboba@hotmail.com]
Message-ID: <BLU169-W119163BAE68316B331EE12193A20@phx.gbl>
Content-Type: multipart/alternative; boundary="_f601f660-fe55-4728-b22f-25a7afcdf4cf_"
From: Bernard Aboba <bernard_aboba@hotmail.com>
To: Colin Perkins <csp@csperkins.org>
Date: Wed, 15 May 2013 11:47:00 -0700
Importance: Normal
In-Reply-To: <1922EE35-127D-459C-AC7A-D2E98A0CDBA0@csperkins.org>
References: <CABkgnnWPWMLEecfqksGJrWrqvsu44gts48igUiLyiVV0iPhwQQ@mail.gmail.com>, <C5E08FE080ACFD4DAE31E4BDBF944EB1134E782F@xmb-aln-x02.cisco.com>, <5193B1DB.2070308@alum.mit.edu>, <1922EE35-127D-459C-AC7A-D2E98A0CDBA0@csperkins.org>
MIME-Version: 1.0
X-OriginalArrivalTime: 15 May 2013 18:47:00.0889 (UTC) FILETIME=[95B75090:01CE519C]
Cc: "mmusic@ietf.org" <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: Wed, 15 May 2013 18:47:08 -0000

Colin said: 
"People often want to look at this from the point of view of what they wish they can change SDP to mean, but unless we are doing SDPng, we need to look at it from the practical point of view of what has deployed and what SDP was defined as when that equipment deployed. We need to find a way that provided backwards interoperability while still allowing us to negotiate the things we want now. You can easily define an extension to SDP that means that RTP received on a single m line was meant to be rendered in different windows, but the fact of the matter remains that is not how lots of SIP equipment worked so you can't pretend SDP always meant that because it did not."
[BA]  The reality is that "SIP equipment" covers an awful lot of ground.  There are implementations that use a single m line for video and can handle and render multiple SSRCs within that RTP session in different windows.   Emil has referred to one of those (Jitsi videobridge).  There are also implementations that use a single m line and support simulcast/layered coding, rendering SSRC groups (e.g. groupings of simulcast and layered sources) in different windows.   Several implementations of H.264/SVC work this way. 
So when people on the say "SIP equipment works this way" or "SDP works this way" or even "RTP works this way" my BS meter goes off.  Usually they mean "the equipment I'm familiar with works this way".   
I'm not sure we can make a definitive statement about what "backwards interoperability" means with respect to video systems today, at least without some work to survey existing implementations.  And this somewhat complicates the "Plan A" vs. "Plan B" discussion in RTCWEB, because the reality is that *neither* of these plans can achieve widespread "backwards interoperability" with respect to SDP, if what you mean by that is "I can take the SDP produced by a WebRTC implementation, throw it over the wire to an existing implementation and expect anything good to happen". 
IMHO, it is unrealistic to expect *any* implementation of the current WebRTC API to deliver that.  Until "comment 22" is resolved, SDP parsing/munging is going to be an unpleasant, time consuming but necessary task for interop with legacy equipment.  So as they said in Dr. Strangelove, "stop worrying and love the bomb". 
What I *would* like is for the RTP/RTCP produced by WebRTC implementations to not require a compute intensive media gateway/transcoder/munger to enable media to be handled by existing systems, at least when the same video codecs are available (and no, that shouldn't necessarily mean "video codec implementations based on the same source code", because the spec should be good enough to enable interoperability of independent implementations).