Re: [MMUSIC] Please Read and Comment: Re: ICE SDP/JSEP peace accords

Adam Roach <adam@nostrum.com> Tue, 22 January 2019 21:04 UTC

Return-Path: <adam@nostrum.com>
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 3184613114D for <mmusic@ietfa.amsl.com>; Tue, 22 Jan 2019 13:04:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.678
X-Spam-Level:
X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RTal6krXfHXk for <mmusic@ietfa.amsl.com>; Tue, 22 Jan 2019 13:04:24 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA66613113A for <mmusic@ietf.org>; Tue, 22 Jan 2019 13:04:23 -0800 (PST)
Received: from Svantevit.roach.at (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x0ML4DPq008240 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 22 Jan 2019 15:04:15 -0600 (CST) (envelope-from adam@nostrum.com)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1548191056; bh=q9TCmfTif5Iu1vaU/S0nPPLLkl0CHBl7FcA/kp3sy6w=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=qzjX9Cgni+g1QC0aPCaVRaTZkkn+xzeBOKceOOBIB9yGzXONTgx1s6KG2UnxQDPpl iDh4QMuA0+ymYMlNrA9yyZD6IGje0OfOBpFfh869RscFeD7Baog7UgUIR843t4hS82 6h7HY9YdsD55Qs5EXjqCEdJgDwBTP2uWyQDFOFq8=
X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Svantevit.roach.at
To: Roman Shpount <roman@telurix.com>, Christer Holmberg <christer.holmberg@ericsson.com>
Cc: Flemming Andreasen <fandreas@cisco.com>, "mmusic@ietf.org" <mmusic@ietf.org>
References: <0454609c-ce69-80d4-93d8-f89bc8ba897e@nostrum.com> <CAD5OKxu1bPDU_snQ=H7RwVgPKW_hKJY1Nj7g82vTpJ+gorPrYQ@mail.gmail.com> <f279e997-0236-b78c-e555-5189d9818ef2@nostrum.com> <9B6124BE-E369-4327-B759-77DB0ED8A484@ericsson.com> <6f42b5c5-72f0-8d6a-c68d-d19da7d94353@cisco.com> <HE1PR07MB3161189A6405D403F433F17293980@HE1PR07MB3161.eurprd07.prod.outlook.com> <CAD5OKxvNYnARbw5yvSHCeQUiSMRxQdMj9h5zUeXj+o3Nd8Kh-g@mail.gmail.com>
From: Adam Roach <adam@nostrum.com>
Message-ID: <3e17ec5d-e6b2-5d38-e206-2ed7b8b9c690@nostrum.com>
Date: Tue, 22 Jan 2019 15:04:07 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.4.0
MIME-Version: 1.0
In-Reply-To: <CAD5OKxvNYnARbw5yvSHCeQUiSMRxQdMj9h5zUeXj+o3Nd8Kh-g@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------26B50BF2E3408FB78531B3AC"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/-OyddGsPAKXLKETSAV2wmaV2dJY>
Subject: Re: [MMUSIC] Please Read and Comment: Re: ICE SDP/JSEP peace accords
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.29
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: <https://mailarchive.ietf.org/arch/browse/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: Tue, 22 Jan 2019 21:04:31 -0000

Yeah, so that's a one-character typo that made it from JSEP into both 
codebases. Firefox is fixed now (as of Firefox 66 [1]), and the editor's 
copy of JSEP is as well [2].

In terms of current offer-generation behavior, I had an brief exchange 
with the Chrome folks; the offers it generates /always/ indicate its 
preferred (default) candidate in the m=/o= line, regardless of the 
candidate in use. Since the preferred candidate will always be UDP, the 
transport is always sent as UDP/TLS/RTP/SAVPF.

Ironically, I don't yet know what the equivalent behavior in Firefox is. 
I'll ask around.

/a

____
[1] https://hg.mozilla.org/mozilla-central/rev/34476dc321b5
[2] https://github.com/rtcweb-wg/jsep/pull/861/files

On 1/22/19 2:51 PM, Roman Shpount wrote:
> On Tue, Jan 22, 2019 at 3:36 PM Christer Holmberg 
> <christer.holmberg@ericsson.com 
> <mailto:christer.holmberg@ericsson.com>> wrote:
>
>     I think Roman requested information about what exactly has been
>     implemented.
>
>
>
> We have discussed this with Adam Roach off-list.
>
> Currently both Chrome and Firefox use outdated protocol 
> TCP/TLS/RTP/SAVPF instead of TCP/DTLS/RTP/SAVPF which is defined in 
> rfc7850 Section 3.5 (https://tools.ietf.org/html/rfc7850#section-3.5).
>
> Chromium Code Search:
>
> https://cs.chromium.org/search/?q=TCP/DTLS/RTP/SAVPF&sq=package:chromium&type=cs
>
> Your search - TCP/DTLS/RTP/SAVPF - did not match any documents.
>
> https://cs.chromium.org/search/?q=TCP/TLS/RTP/SAVPF&sq=package:chromium&type=cs
>
> src/third_party/webrtc/pc/media_session.cc
>  cricket::IsDtlsRtp
>     81: // Most-likely values first.
>     82: return protocol == "UDP/TLS/RTP/SAVPF" || protocol == 
> "TCP/TLS/RTP/SAVPF" ||
>     83:        protocol == "UDP/TLS/RTP/SAVP" || protocol == 
> "TCP/TLS/RTP/SAVP";
>
> src/third_party/webrtc/pc/media_session_unittest.cc
>    230: static const char* kMediaProtocolsDtls[] = {
>    231:     "TCP/TLS/RTP/SAVPF", "TCP/TLS/RTP/SAVP", "UDP/TLS/RTP/SAVPF",
>    232:     "UDP/TLS/RTP/SAVP"};
>
> Firefox Code Search:
>
> https://dxr.mozilla.org/mozilla-central/search?q=TCP%2FDTLS%2FRTP%2FSAVPF
> 0 results from the mozilla-central tree
>
> https://dxr.mozilla.org/mozilla-central/search?q=TCP%2FTLS%2FRTP%2FSAVPF
> media/webrtc/signaling/src/sdp/SdpMediaSection.h
> 57 kTcpTlsRtpSavpf,    // TCP/TLS/RTP/SAVPF [JSEP-TBD]
> 264 return os << "TCP/TLS/RTP/SAVPF";
>
> media/webrtc/signaling/src/sdp/rsdparsa/src/media_type.rs 
> <http://media_type.rs>
> 272 "TCP/TLS/RTP/SAVPF" => SdpProtocolValue::TcpTlsRtpSavpf,
>
> media/webrtc/signaling/src/sdp/sipcc/sdp_main.c
> 273 {"TCP/TLS/RTP/SAVPF", sizeof("TCP/TLS/RTP/SAVPF")},
>
> This means both Chrome and Firefox never generate SDP with 
> TCP/DTLS/RTP/SAVPF. In fact, neither browser currently can parse SDP 
> with  TCP/DTLS/RTP/SAVPF and as a result they are not compliant with 
> JSEP 5.1.2 
> (https://tools.ietf.org/html/draft-ietf-rtcweb-jsep-25#section-5.1.2). 
> So, JSEP section 5.1.2 does not actually describe current 
> implementations and both Chrome and Firefox would need to be updated 
> to be compliant with this section of JSEP draft.
>
> I would think that since both Chrome and Firefox would need to be 
> updated to be compliant with JSEP section 5.1.2 anyway, it should be 
> possible to update section 5.1.2 and clarify that it only applies to 
> the offers during ICE restart.
>
> Regards,
> _____________
> Roman Shpount
>
>