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

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

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AD0A8129507 for <>; Tue, 10 Jan 2017 07:44:27 -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 tcIAm6V9xTs2 for <>; Tue, 10 Jan 2017 07:44:26 -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 E621F129504 for <>; Tue, 10 Jan 2017 07:44:25 -0800 (PST)
X-AuditID: c1b4fb3a-46fff70000005d1c-e5-58750157b06e
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id A5.96.23836.75105785; Tue, 10 Jan 2017 16:44:24 +0100 (CET)
Received: from [] ( by ( with Microsoft SMTP Server id 14.3.319.2; Tue, 10 Jan 2017 16:44:23 +0100
To: Harald Alvestrand <>, <>
References: <> <> <>
From: Magnus Westerlund <>
Message-ID: <>
Date: Tue, 10 Jan 2017 16:44:22 +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="windows-1252"; format=flowed
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrGLMWRmVeSWpSXmKPExsUyM2K7pW4EY2mEwaJ2TotjfV1sFlOXP2Zx YPK4MuEKq8eSJT+ZApiiuGxSUnMyy1KL9O0SuDKmTlvPVLBRpKK5V6aBsVegi5GTQ0LAROL1 7t+MXYxcHEIC6xgltp+9ygSSEBJYzijxvbUUxBYWcJA4tnMtC4gtImAvMb9nOTtEw2lGiaO3 LzGCJNgELCRu/mhkA7F5gYp2ff0AFmcRUJV4deok2FBRgRiJt+tBmkFqBCVOznwCNpRTwFFi 95qzrF2MHBzMQL0PtpaBhJkF5CWat85mhrhHW6KhqYN1AiP/LCTdsxA6ZiHpWMDIvIpRtDi1 uDg33chIL7UoM7m4OD9PLy+1ZBMjMPQObvlttYPx4HPHQ4wCHIxKPLwfvpVECLEmlhVX5h5i lOBgVhLhjf0PFOJNSaysSi3Kjy8qzUktPsQozcGiJM5rtvJ+uJBAemJJanZqakFqEUyWiYNT qoFxbV54i0riJM281VL2vBZXNi24+CHtxh+OnS98p/4//su1aX/p0XNfD8+NclumOX2a2it5 y19xxkb/8+LU3jI5zbDI89mvdG3tjzRe0+O/8nx3sKyMSbEuecyjWMM1+4GT0kSp7JuNnx8/ n8pr6ltkc/veyt7OdZ949679suzH8kdzE5adtXCbq8RSnJFoqMVcVJwIAD/YoHw5AgAA
Archived-At: <>
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:44:27 -0000

Den 2017-01-02 kl. 14:42, skrev Harald Alvestrand:
> Den 22. des. 2016 18:30, skrev Eric Rescorla:
>>      __
>>     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?
> Concur with EKR.
> This field (the TCP/UDP part of the protocol field) was defined in a way
> that makes its original purpose (to negotiate profiles) not only
> impossible while using ICE, but actively harmful, because you end up
> telling lies in very many cases, so people will have to accept things
> that don't match reality.
> Make the world as simple for implementors as possible: Send a fixed
> string, and accept all strings.

Okay, can we please be precise with what is suggested here. Because what 
you write above, and what EKR proposed is not really the same thing. The 
issue proposed that it was fine to set either of the strings. You saying 
a fixed string. I want to ask you which UDP/... or TCP/..., or even 

 From a strict clarity issue using ICE/... would be my preferred. But, 
that is probably going to throw some implementations, especially 
gateways. It will also require us to actually go write the registration 
to explain what it is.

Using UDP is likely the most compatible and will only fail in gateway 
cases where there are no UDP candidates and the gateway fail to pick 
that up.

Using TCP when there are no TCP candidates are equally misleading to 
gateway cases.

The above is why I proposed that implementation capabilities and any 
configuration to limit what functions being used would be an appropriate 

I hope at least we can agree that an JSEP Answer MUST use the PROTO 
string of the OFFER?


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: