Re: [MMUSIC] What is an m-line?
Harald Alvestrand <harald@alvestrand.no> Fri, 17 May 2013 06:37 UTC
Return-Path: <harald@alvestrand.no>
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 5290421F9380 for <mmusic@ietfa.amsl.com>; Thu, 16 May 2013 23:37:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.599
X-Spam-Level:
X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 CkGhgUhf1JNG for <mmusic@ietfa.amsl.com>; Thu, 16 May 2013 23:37:13 -0700 (PDT)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 7BBD721F9344 for <mmusic@ietf.org>; Thu, 16 May 2013 23:37:11 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 0AE3039E0D7 for <mmusic@ietf.org>; Fri, 17 May 2013 08:37:10 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03bH8tm0cA4W for <mmusic@ietf.org>; Fri, 17 May 2013 08:37:08 +0200 (CEST)
Received: from [IPv6:2001:470:de0a:27:d594:249c:4a90:3766] (unknown [IPv6:2001:470:de0a:27:d594:249c:4a90:3766]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 1EDBB39E01E for <mmusic@ietf.org>; Fri, 17 May 2013 08:37:08 +0200 (CEST)
Message-ID: <5195D013.1030204@alvestrand.no>
Date: Fri, 17 May 2013 08:37:07 +0200
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 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> <51955257.5090606@alum.mit.edu>
In-Reply-To: <51955257.5090606@alum.mit.edu>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
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: Fri, 17 May 2013 06:37:17 -0000
On 05/16/2013 11:40 PM, Paul Kyzivat wrote: > 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. Well.... Paul's previous message said: "Note that in sip there are two ways to do a transfer: - REFER, which leads to INVITE/Replaces - 3pcc, which leads to just a reINVITE. The INVITE/Replaces is much clearer that a change is required. The "Replaces" is a giveaway, and the new SDP should have a different session id. (But in cases where there are multiple media streams, mapped to distinct windows or devices, it may be hard to decide what to do.) " It seems like in this case, the SIP headers influence the meaning of the SDP, so it's not 100% true that all the meaning is in the SDP. Or did I miss some subtlety here? > 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 >> > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > 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