Re: [MMUSIC] JSEP Issue #394: What appears in m= lines.

Magnus Westerlund <> Tue, 10 January 2017 15:13 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F41C112A00E; Tue, 10 Jan 2017 07:13:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id HPygr5SU44ID; Tue, 10 Jan 2017 07:13:27 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5E3FD12951F; Tue, 10 Jan 2017 07:13:26 -0800 (PST)
X-AuditID: c1b4fb2d-26a859800000561e-d6-5874fa15cc8c
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id B5.9E.22046.51AF4785; Tue, 10 Jan 2017 16:13:25 +0100 (CET)
Received: from [] ( by ( with Microsoft SMTP Server id 14.3.319.2; Tue, 10 Jan 2017 16:13:23 +0100
To: Eric Rescorla <>
References: <> <>
From: Magnus Westerlund <>
Message-ID: <>
Date: Tue, 10 Jan 2017 16:13:23 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"; format=flowed
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrBLMWRmVeSWpSXmKPExsUyM2K7q67or5IIg5tnBC1WvD7HbjF1+WMW i7X/2tkdmD2WLPnJ5DH5cRtzAFMUl01Kak5mWWqRvl0CV8aNZTcYC77zVjQuXMXcwNjA3cXI ySEhYCIx9/lFti5GLg4hgXWMEtvm9TBBOMsZJT60TmIEqRIWcJA4tnMtC4gtIqAg8evPCTBb SGAKo8SEVwEgNrOAi8SFqY+ZQGw2AQuJmz8a2UBsXgF7iXXPJoLVswioSkybeRwsLioQI/F2 /XJ2iBpBiZMznwDVsHNwCgRK7MiFmGghMXP+eUYIW16ieetsZoit2hINTR2sExgFZiFpnoWk ZRaSlgWMzKsYRYtTi4tz042M9VKLMpOLi/Pz9PJSSzYxAsPz4JbfujsYV792PMQowMGoxMP7 4VtJhBBrYllxZe4hRgkOZiUR3u9fgUK8KYmVValF+fFFpTmpxYcYpTlYlMR5zVbeDxcSSE8s Sc1OTS1ILYLJMnFwSjUw+mn7P1LbKe70kS2t+5BYq9Wk439j+ye8UPty84qQTjfnUt0fsyfM dVlv2rwsRNXf99GfhFu77wr+mGN7Isp8regj5r+128ouy5+Z013+SKWv2ctjr8Gx09UFxR68 7juTdixWm7QzoGJiCKPXkfSN9pW/v2r33P5qeXjL+RlS6y958STKPi/LVmIpzkg01GIuKk4E AJEvzr9LAgAA
Archived-At: <>
Cc: "" <>, mmusic WG <>
Subject: Re: [MMUSIC] JSEP Issue #394: What appears in m= lines.
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 10 Jan 2017 15:13:29 -0000

Den 2016-12-22 kl. 18:30, skrev Eric Rescorla:
> On Thu, Dec 22, 2016 at 7:15 AM, Magnus Westerlund
>     Okay, I agree that having any rules for what you should offer here
>     based on what the actual outcome is not the best idea here. I think
>     the rules should be based on capability and intent. So if you only
>     are going offer TCP candidates, then you clearly should use TCP/…,
> I'm going to push on this. If we've already agreed that mismatches are
> normal, why should we do that? Wouldn't it be better to just effectively
> deprecate this field?

So, my main argument for including any rules for how to set it, would be 
that the this part of the PROTO field still has meaning outside of 
WebRTC context. There one may actually have it to match what is goind to 
be used. Thus, it can provide some guidance to gateways on what to 
expect. It might be that we should actually set it to UDP for those not 
supporting ICE/TCP, and to TCP for the ones that supports both UDP and 
TCP. That would still provide information to the gateway.

I think simple rules based on implementation capabilities for how to set 
it are better than no rules. Especially as it would carry some 
information, not zero, which is the result of no rules.


Magnus Westerlund

Services, Media and Network features, Ericsson Research EAB/TXM
Ericsson AB                 | Phone  +46 10 7148287
Färögatan 6                 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: