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

Paul Kyzivat <pkyzivat@alum.mit.edu> Fri, 17 May 2013 15:22 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 5B04621F870F for <mmusic@ietfa.amsl.com>; Fri, 17 May 2013 08:22:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.324
X-Spam-Level:
X-Spam-Status: No, score=-0.324 tagged_above=-999 required=5 tests=[AWL=0.113, 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 4URP5hCd1TGw for <mmusic@ietfa.amsl.com>; Fri, 17 May 2013 08:22:17 -0700 (PDT)
Received: from qmta07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:64]) by ietfa.amsl.com (Postfix) with ESMTP id 693DD21F969C for <mmusic@ietf.org>; Fri, 17 May 2013 08:22:16 -0700 (PDT)
Received: from omta20.westchester.pa.mail.comcast.net ([76.96.62.71]) by qmta07.westchester.pa.mail.comcast.net with comcast id d00F1l0091YDfWL573NFlJ; Fri, 17 May 2013 15:22:15 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta20.westchester.pa.mail.comcast.net with comcast id d3NF1l00h3ZTu2S3g3NFbl; Fri, 17 May 2013 15:22:15 +0000
Message-ID: <51964B27.1040008@alum.mit.edu>
Date: Fri, 17 May 2013 11:22:15 -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> <51955257.5090606@alum.mit.edu> <5195D013.1030204@alvestrand.no>
In-Reply-To: <5195D013.1030204@alvestrand.no>
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=1368804135; bh=ixM/T7NoJ4Ikia1IhmbbwnGhnvYc4ituFfcqCJ1FjWA=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=IDgmgtZE6sr6ayxTggQWCyUXL6lWNS+b2Unbz/xLDaLWdklQVVxNWbdi3JqitJfaW iCm6MGq/xq7IutpRTQJvfHwvqhuZ/EgSI8ea3d1EiGu2kVbh4nd6eAKsSeyp7WglEg Hhc0EWiPIobkZZGe4sqT3Ti8HUs5Oc3lCZCpqHVKxXGBxonX3W/d+MQvkBWdb/0hQJ pBXZGVqWRFV4etyrh+oS0sxyfEEBJFNZpBroUAwo8sLmIg9L2EN+RLXJtWoWLFhgPV 6T57YolVvKYAiLs7H74lpNPkdZodYEpyW+eNr9KLYk8p6ERN41D2whezZDcKhbzVUQ b2+t2XnznUo0A==
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 15:22:22 -0000

On 5/17/13 2:37 AM, Harald Alvestrand wrote:
> 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?

Yes and no.

The INVITE/Replaces is analogous to establishing a new PeerConnection 
and asking it to replace the old one. I guess you could say that the 
'Replaces' augments the SDP by saying 'bind this to the devices used in 
that other call'.

More generally, yes the SIP can influence the SDP interpretation a 
little bit. (E.g. by using SIP Options.) But it is a blunt instrument, 
and usually proposals to do so get argued down as layer violations. 
There certainly is no precision to delve down to influence individual 
m-lines.

	Thanks,
	Paul

>> 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
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>