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

Harald Alvestrand <> Fri, 17 May 2013 06:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5290421F9380 for <>; Thu, 16 May 2013 23:37:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -110.599
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id CkGhgUhf1JNG for <>; Thu, 16 May 2013 23:37:13 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 7BBD721F9344 for <>; Thu, 16 May 2013 23:37:11 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0AE3039E0D7 for <>; Fri, 17 May 2013 08:37:10 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 03bH8tm0cA4W for <>; 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 (Postfix) with ESMTPSA id 1EDBB39E01E for <>; Fri, 17 May 2013 08:37:08 +0200 (CEST)
Message-ID: <>
Date: Fri, 17 May 2013 08:37:07 +0200
From: Harald Alvestrand <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6
MIME-Version: 1.0
References: <>, , <>, , <>, , <>, <BLU169-W119163BAE68316B331EE12193A20@phx.gbl>, <> <BLU169-W743682718AEA906C0F3C2A93A20@phx.gbl> <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: Re: [MMUSIC] What is an m-line?
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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 mailing list
> _______________________________________________
> mmusic mailing list