IETF Logo Mail Archive

Re: [rtcweb] [MMUSIC] Default proto transport in JSEP

Cullen Jennings <fluffy@iii.ca> Wed, 21 November 2018 00:10 UTC

Return-Path: <fluffy@iii.ca>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F5E9130E9C for <rtcweb@ietfa.amsl.com>; Tue, 20 Nov 2018 16:10:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
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 HoQBnBXK3QqG for <rtcweb@ietfa.amsl.com>; Tue, 20 Nov 2018 16:10:16 -0800 (PST)
Received: from smtp97.iad3b.emailsrvr.com (smtp97.iad3b.emailsrvr.com [146.20.161.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDBFC130E76 for <rtcweb@ietf.org>; Tue, 20 Nov 2018 16:10:12 -0800 (PST)
Received: from smtp13.relay.iad3b.emailsrvr.com (localhost [127.0.0.1]) by smtp13.relay.iad3b.emailsrvr.com (SMTP Server) with ESMTP id 0A24260318; Tue, 20 Nov 2018 19:10:12 -0500 (EST)
X-Auth-ID: fluffy@iii.ca
Received: by smtp13.relay.iad3b.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 7D844602A6; Tue, 20 Nov 2018 19:10:11 -0500 (EST)
X-Sender-Id: fluffy@iii.ca
Received: from [10.1.3.91] (S0106004268479ae3.cg.shawcable.net [70.77.44.153]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:25 (trex/5.7.12); Tue, 20 Nov 2018 19:10:12 -0500
Content-Type: multipart/alternative; boundary="Apple-Mail=_4007E742-3BC0-468F-967A-EB1132A8BA24"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Cullen Jennings <fluffy@iii.ca>
In-Reply-To: <CAD5OKxsNFFmER__H0+5Mzts58yn9cWLMEADhSnLR4nreKD9WAQ@mail.gmail.com>
Date: Tue, 20 Nov 2018 17:10:09 -0700
Cc: RTCWeb IETF <rtcweb@ietf.org>, mmusic WG <mmusic@ietf.org>
Message-Id: <9B9B741B-622F-4565-899B-700636408F6C@iii.ca>
References: <CA+9kkMADnZJBaV0hfLuwGU0bGBEP5tCPZ=8Zd_85Dgzi37ghAQ@mail.gmail.com> <CAD5OKxsNFFmER__H0+5Mzts58yn9cWLMEADhSnLR4nreKD9WAQ@mail.gmail.com>
To: Roman Shpount <roman@telurix.com>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtcweb/WP0GjkmWoOqoNrGabiZvRu8DL24>
Subject: Re: [rtcweb] [MMUSIC] Default proto transport in JSEP
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtcweb/>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 21 Nov 2018 00:10:17 -0000

Sounds like the ice-sip-sdp draft has not concerned itself much with working with the existing deployed endpoint which treat 0.0.0.0 as a hold indicator. I think the JSEP solution will work much better in practice. 

This is discussed a bit in 
https://tools.ietf.org/html/rfc6337#section-5.4 <https://tools.ietf.org/html/rfc6337#section-5.4>


> On Nov 19, 2018, at 11:28 AM, Roman Shpount <roman@telurix.com> wrote:
> 
> Hi All,
> 
> The current language in JSEP makes it incompatible with any ICE implementation, either existing or the future ones compliant with ice-sip-sdp draft. You can, of course, overwrite ice-sip-sdp, but this will mean JSEP will be a completely incompatible system..
> 
> The problem is that JSEP proposes to use UDP protocol in the m= line and at the same time update address and port to the currently selected candidate. Based on ice-sip-sdp, if protocol of the current selected candidate does not match protocol in the m= line, this will mean either ICE mismatch or additional candidate with protocol, address, and port form m= and c= line.
> 
> Second, ice-sip-sdp treats SDP during ICE restart, when multiple candidates are present different from SDP when ICE is not restarted (single candidate). According to ice-sip-sdp, when only a single candidate is present, this candidate protocol, address and port are set in m= and c= line. JSEP proposes to put original UDP protocol and address and port from the single candidate.
> 
> To be specific, it is not the fact that protocol in m= line is not updated is an issue. It is that protocol in not updated but address and port in m= and c= line are updated. In the ice-sip-sdp draft there is a solution for this issue -- set address to IN IP4 0.0.0.0 and port to 9. This is specifically supposed to be ignored and not cause the ICE mismatch or extra candidates. If JSEP wants to overwrite ice-sip-sdp, it can specify that m- line protocol should always be set to UDP based protocol, c= line address should be set to   IN IP4 0.0.0.0 and m= line port set to 9. In case of an ICE only system where c= and m= line address information is irrelevant, this makes implementation simpler since m= and c= line address information can stay constant for the duration of the session.
> 
> Regards,
> _____________
> Roman Shpount
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic

v2.23.0 | Report a Bug | By Email