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

Paul Kyzivat <pkyzivat@alum.mit.edu> Thu, 16 May 2013 21:40 UTC

Return-Path: <pkyzivat@alum.mit.edu>
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 E828D11E80D1 for <mmusic@ietfa.amsl.com>; Thu, 16 May 2013 14:40:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.319
X-Spam-Level:
X-Spam-Status: No, score=-0.319 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1]
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 n2PD8nTw3Yyx for <mmusic@ietfa.amsl.com>; Thu, 16 May 2013 14:40:43 -0700 (PDT)
Received: from qmta10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:17]) by ietfa.amsl.com (Postfix) with ESMTP id A600311E80CC for <mmusic@ietf.org>; Thu, 16 May 2013 14:40:41 -0700 (PDT)
Received: from omta02.westchester.pa.mail.comcast.net ([76.96.62.19]) by qmta10.westchester.pa.mail.comcast.net with comcast id cdz61l0040QuhwU5AlghDs; Thu, 16 May 2013 21:40:41 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta02.westchester.pa.mail.comcast.net with comcast id clgg1l0113ZTu2S3Nlggpv; Thu, 16 May 2013 21:40:41 +0000
Message-ID: <51955257.5090606@alum.mit.edu>
Date: Thu, 16 May 2013 17:40:39 -0400
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version: 1.0
To: mmusic@ietf.org
References: <CABkgnnWPWMLEecfqksGJrWrqvsu44gts48igUiLyiVV0iPhwQQ@mail.gmail.com>, , <C5E08FE080ACFD4DAE31E4BDBF944EB1134E782F@xmb-aln-x02.cisco.com>, , <5193B1DB.2070308@alum.mit.edu>, , <1922EE35-127D-459C-AC7A-D2E98A0CDBA0@csperkins.org>, <BLU169-W119163BAE68316B331EE12193A20@phx.gbl>, <5193EA5C.7050905@alvestrand.no> <BLU169-W743682718AEA906C0F3C2A93A20@phx.gbl>
In-Reply-To: <BLU169-W743682718AEA906C0F3C2A93A20@phx.gbl>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1368740441; bh=1rRY/2aetbHj/eE11oAwNp42jEXy/cQsBDUi5pt4IN0=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=phGtOEA0sKMbalAs+Y/2r/PS9jVpsYDsqIekmfU4D7rpbAIpvE1s587p1kcRzPGge 1FdhAbmflZGF1tfm2f53t32WS69uFgDQKCyRGUyoR2F0I8HoYzI5wTfKUv4Dx2uqoZ jkE7baCAJUEOBPJP16ZdzFKHuhn4MnCl/tRcKwZv2vgOnWlrUOMBYJp3qiIYCV/6gM zrGV9Lutt1cYWQ0fly5v+JFP3YPVWc2KnZNlAjPguCGFB17DpngFTMEAY/nqA2qHsH oUWx26Qmv0QWzgCOTdYyoNjqgM0xEZ1Pk5OU9XnsVLgIns8P3iqpTNKMMKYGWGmkAo DzEh6DFFsY6qA==
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, 16 May 2013 21:40:48 -0000

I'd like people to keep one thing in mind:

RTCWEB has an independent mechanism that can be used to declare and/or 
negotiation some sort of consistency of intent between the two ends of a 
session. But native SIP applications don't. SDP is *the* way to agree 
about what is being done, and the semantics of the media that is being 
exchanged. So anything that might be done in a native SIP environment 
must be able to be negotiated without any prior knowledge prior to the 
SDP O/A. And even afterwards unless the application uses SDP to 
establish another means of negotiation. (As clue is doing.)

And to play with those native sip apps, RTCWEB needs to be able to 
generate and consume the same SDP.

	Thanks,
	Paul

On 5/15/13 6:43 PM, Bernard Aboba wrote:
> Harald said:
>
>
> "I take a somewhat different approach:
> If it's possible to *write an application* that uses the WebRTC
> interface, does not mangle the SDP, and sends that to an existing
> implementation (supporting SRTP and ICE), and has something useful
> happen, I think it's the success we can hope for."
> [BA] Since existing non-WebRTC audio applications typically have to do
> at least some SDP mangling,  WebRTC would be at parity if the SDP
> mangling is no worse than what is typically required today.  If we can
> reach that point with an audio application (which I think is plausible)
> then the situation would be tolerable, albeit not perfect.  The SDP
> mangling in the WebRTC sample application is at that level -- not
> pretty, but not shocking by any means.
> For video, the non-WebRTC interop situation is much worse -- both SDP
> mangling (nastier than for audio) and RTP/RTCP mangling is
> typically involved, */even for implementations of the same codec./*
> Since RTP/RTCP mangling is the really expensive operation, if this can
> be avoided, the cost of  interop can be brought way down.  In the
> non-WebRTC world, we are just reaching the point where this has become
> feasible, so I would set the WebRTC bar in roughly the same place - we
> may end up with more SDP mangling than is comfortable, but we need to
> avoid RTP/RTCP mangling if at all possible.
> Harald also said:
>
> "This may mean having the application use content settings to force
> tracks to different m-lines, keep low the number of tracks offered, and
> other tricks that make sense in the context of *that application*.
> It's the *application* that needs to interwork, it's not "WebRTC in
> general". WebRTC just needs to make it possible."
> [BA] Right.  The reality is that most "applications" (90+ percent of
> them) won't need to put in this effort, so it just needs to be possible
> to achieve for those that do.   And as long as it is not necessary to
> touch every RTP packet in the process, we are just talking about a
> one-time application development cost that is "just software".
> Harald finally said:
>
> "I see the idea that *any application* should produce SDP that's useful
> in such a scenario as an illusion, and pursuing that illusion is just
> going to hurt us."
> [BA] Agree. s/illusion/delusion/ :)
>
>
>
>     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).
>
>
> I find nothing to disagree with in this paragraph.
>
>
> _______________________________________________ mmusic mailing list
> mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic
>
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>