Re: [MMUSIC] ICE SDP/JSEP peace accords

Adam Roach <adam@nostrum.com> Mon, 14 January 2019 23:57 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 A332B131456 for <mmusic@ietfa.amsl.com>; Mon, 14 Jan 2019 15:57:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level:
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) 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 GI6A6zmfeI3L for <mmusic@ietfa.amsl.com>; Mon, 14 Jan 2019 15:57:38 -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 02536131366 for <mmusic@ietf.org>; Mon, 14 Jan 2019 15:57:37 -0800 (PST)
Received: from Svantevit.local (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 x0ENvZIK064249 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 14 Jan 2019 17:57:36 -0600 (CST) (envelope-from adam@nostrum.com)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1547510257; bh=rK/g23ZvVvfprJQS8vYOhljjlTnQCTZGqZHd0O9uonQ=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=Qzf7khdwlQPfOQGqNy+lpTjvRHOiveFxiifgTr4wl7Q+Dn0AahGKnRVTfcsOpDxea JjLjoM4GpcjTV0eqa1EqzV1/9d0Qe+fJ7U2cV82PpnFanQVGJOS/ECYiF9jXJjJCYw 09GnSkVJK55vybivykXbsIIjzJhS70iQg0Qg7M9o=
X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Svantevit.local
To: Roman Shpount <roman@telurix.com>
Cc: "mmusic@ietf.org" <mmusic@ietf.org>
References: <0454609c-ce69-80d4-93d8-f89bc8ba897e@nostrum.com> <CAD5OKxu1bPDU_snQ=H7RwVgPKW_hKJY1Nj7g82vTpJ+gorPrYQ@mail.gmail.com>
From: Adam Roach <adam@nostrum.com>
Message-ID: <f279e997-0236-b78c-e555-5189d9818ef2@nostrum.com>
Date: Mon, 14 Jan 2019 17:57:30 -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: <CAD5OKxu1bPDU_snQ=H7RwVgPKW_hKJY1Nj7g82vTpJ+gorPrYQ@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------390CE9E08D16BE8E8EE581C6"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/IckduhpKg1IK1N0SOaCUmWbtDc0>
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: Mon, 14 Jan 2019 23:57:43 -0000

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.


> 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.


> 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.

/a