Re: [MMUSIC] ICE SDP/JSEP peace accords

Roman Shpount <roman@telurix.com> Tue, 15 January 2019 00:26 UTC

Return-Path: <roman@telurix.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 D9036130E62 for <mmusic@ietfa.amsl.com>; Mon, 14 Jan 2019 16:26:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.03
X-Spam-Level:
X-Spam-Status: No, score=-2.03 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.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 kF4Dw2FZbsWO for <mmusic@ietfa.amsl.com>; Mon, 14 Jan 2019 16:26:46 -0800 (PST)
Received: from mail-pl1-x632.google.com (mail-pl1-x632.google.com [IPv6:2607:f8b0:4864:20::632]) (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 9BA1C12D4EA for <mmusic@ietf.org>; Mon, 14 Jan 2019 16:26:46 -0800 (PST)
Received: by mail-pl1-x632.google.com with SMTP id y1so402519plp.9 for <mmusic@ietf.org>; Mon, 14 Jan 2019 16:26:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=hEj36wSGltaIsRCt+t1z5mTWuxl/TZw9UtvS4uCRjYo=; b=P+6jH8rCnlvq/Zk8KGOEZXR0QWz5DA5qi00rjpG9O8UEDYG41OVM/KEFf+GCwOgOT/ mS1RCRsgApOpoHr/7GGO9enEc5DTojO21nxoLc9AAux5jpPhICrIE0pGfGoCoudfHwhr 1UvQi6OJhdso8aArz9du/JBYQSxtRlCLlb+mxgTxz3OIF59xhgGd0xJpdcc8C9HXRHcy 2FNaJm4oLaXtRTlNk2DRVBUt7vT+S7SBQVRJDE31Dcjh8Go2QlwPC3crApUsm9Y3wUnZ DQf2niAwoy0E18+Ei1ocfdKJdf1U9BTlzUz3KESbPxMAPLBeDjRQMABNYgVS8xK8hRi8 RE8w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=hEj36wSGltaIsRCt+t1z5mTWuxl/TZw9UtvS4uCRjYo=; b=oytAVLoMmKbaVPZfobGZGGKyrhw1ac/uRTMOaL6A5WgVmMJZyXUPRAY6by26x9elQR wG859fgzJ31XAvcnWJAkhfQ6m1KTWLTY1Uj7zIBLoSy/UmNAFEBbgOYetTBZGdVoORQM ZHRobgvSSPHqKFHI0Grzu236CfHltZqC667V8UWiHUtiU9pS/a2jrWPwyWhIQ5zL38aC AoHCr6/pI45QR4i1HL8n+tHar3yrDAxp0u66kIsQmkbaMTn7awXrAX9LhkrKBFjaK5lG g5OZDrc2EU+m/KNfBdFpFBT/jcP83GapzgW/h6T9OmBL2NOCUFyaxkUJC03jWpNDLjz1 wJsw==
X-Gm-Message-State: AJcUukdQUC5QScXJu8R+6uBXBVLXu6tRCzF/3W/8hAWHybzTvT6VT8YA jsswoa1C3QnawZF2qmaRTrcnSw1egzo=
X-Google-Smtp-Source: ALg8bN6/rtIr9/TGaBgQEldeJBPleiV1XS8eGeGjkDw5PAYfQO+oQrbyP8GI5bLRfZa5nYpNJXhe7g==
X-Received: by 2002:a17:902:28e6:: with SMTP id f93mr1166275plb.239.1547512005889; Mon, 14 Jan 2019 16:26:45 -0800 (PST)
Received: from mail-pl1-f176.google.com (mail-pl1-f176.google.com. [209.85.214.176]) by smtp.gmail.com with ESMTPSA id s84sm3386165pfi.15.2019.01.14.16.26.45 for <mmusic@ietf.org> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 14 Jan 2019 16:26:45 -0800 (PST)
Received: by mail-pl1-f176.google.com with SMTP id g9so417027plo.3 for <mmusic@ietf.org>; Mon, 14 Jan 2019 16:26:45 -0800 (PST)
X-Received: by 2002:a17:902:720c:: with SMTP id ba12mr1199540plb.79.1547512004772; Mon, 14 Jan 2019 16:26:44 -0800 (PST)
MIME-Version: 1.0
References: <0454609c-ce69-80d4-93d8-f89bc8ba897e@nostrum.com> <CAD5OKxu1bPDU_snQ=H7RwVgPKW_hKJY1Nj7g82vTpJ+gorPrYQ@mail.gmail.com> <f279e997-0236-b78c-e555-5189d9818ef2@nostrum.com>
In-Reply-To: <f279e997-0236-b78c-e555-5189d9818ef2@nostrum.com>
From: Roman Shpount <roman@telurix.com>
Date: Mon, 14 Jan 2019 19:26:34 -0500
X-Gmail-Original-Message-ID: <CAD5OKxur5Te+ANm7iB3yvfPBFthhMqNVR_oYOB=1vbDBA0nnVA@mail.gmail.com>
Message-ID: <CAD5OKxur5Te+ANm7iB3yvfPBFthhMqNVR_oYOB=1vbDBA0nnVA@mail.gmail.com>
To: Adam Roach <adam@nostrum.com>
Cc: "mmusic@ietf.org" <mmusic@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000548a05057f7437cb"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/I0axrPIMonWnp6LDuOZN6jUAc0M>
Subject: Re: [MMUSIC] 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, 15 Jan 2019 00:26:51 -0000

On Mon, Jan 14, 2019 at 6:57 PM Adam Roach <adam@nostrum.com> wrote:

> On 1/14/19 5:39 PM, Roman Shpount wrote:
>
>
> 1. We are discussing the JSEP update that changes the protocol behavior.
> Subsequent offers in JSEP always specified transport, address and port of
> the only (default) candidate present. No version of JSEP draft was ever
> published where it was not the case. This is a protocol change which is
> being done when document is already in Editor Queue. If any implementations
> currently exist that send UDP/TLS/RTP/SAVPF in subsequent offers when only
> TCP candidates are present, they are not compliant with latest published
> JSEP draft.
>
> The JSEP document was internally inconsistent, as you have pointed out in
> the past. Two statements conflicted with each other, so no matter what an
> implementation did, it was possible to point to a normative statement in
> JSEP that it was violating. The change to JSEP is being made to bring it in
> line with the behavior that was actually developed and deployed.
>
Can we see some sort of indication of what is actually currently
implemented? As far as I remember this changed a couple of times, so it
would be interesting to see what is currently deployed. At the end of the
day, we are talking about changing of a few lines in existing
implementations which are still deploying huge compatibility breaking
changes, like unified plan.


> 2. So far nothing specifies what is being placed in address and port of c=
> and m= line when m= line specifies UDP based protocol but all the ICE
> candidates are TCP. If anybody thinks this is specified somewhere except
> the latest JSEP editorial update, please let me know. What I do not want to
> happen is to make JSEP specify that m= and c= line should contain address
> from TCP candidate with protocol in m= line being UDP. This would be a new
> behavior introduced only to save an extra sentence. Ideally, I would prefer
> that in this case IN IP4 0.0.0.0 address was used in the c= line and port 9
> was used in m= line to indicate that this information is supposed to be
> discarded. I do not think this would break any existing implementations and
> can be done without any changes to the current JSEP draft with an
> ice-sip-sdp update.
>
>
> This is a rough edge, but -- again -- we're really at a point where the
> currently deployed JSEP behavior is what JSEP needs to document. It might
> make you sad, but it's the only really practical approach. I can see why
> you prefer what you prefer, but I can't work out what breaks if we don't do
> your preferred thing.
>
 The result of putting random information in c= and m= line is that it
means SDP from WebRTC implementation would need to be munged and modified
when passed to non WebRTC implementations. If you have a server which
processes SDP from both regular phones and WebRTC, offers from these two
sources will need to be treated differently. In case of phones, default
candidate that does not match any ICE candidates should be treated as an
additional candidate. In case of WebRTC, it should be ignored.

> 3. I am not sure your analysis is entirely correct. There is a problem
> with was it being proposed and exiting RFC5245 implementations. According
> to RFC 5245 section 9.2 (https://tools.ietf.org/html/rfc5245#section-9.2
> ):
>
> When receiving a subsequent offer within an existing session, an agent
> MUST reapply the verification procedures in Section 5.1 without regard to
> the results of verification from any previous offer/answer exchanges.
>
>
> In  RFC 5245 section 5.1:
>
> The agent will proceed with the ICE procedures defined in this
> specification if, for each media stream in the SDP it received, the default
> destination for each component of that media stream appears in a candidate
> attribute.
> ...
> If this condition is not met, the agent MUST process the SDP based on
> normal RFC 3264 procedures...
>
>
> Default destination in RFC 5245 includes transport, address and port. So
> if all three of these do not match any of the candidates, entire offer is
> processed as non-ICE. This means all the sections marked as * in your
> description will break against the RFC 5245.
>
>
> That is an interesting and rather unfortunate wrinkle. I fear it falls
> victim to the preconditions I laid out at the top of my message, and
> there's probably no helping it. I mean, we can make the documents say the
> right things, but the chances of that causing the implementations to do
> what you want are probably as close to zero as to make no difference.
>
I thought that RFC5245 interop is something which was important to WebRTC.
Are we dropping this now?

Regards,
______________
Roman Shpount