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