IETF Logo Mail Archive

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

Roman Shpount <roman@telurix.com> Tue, 04 December 2018 21:21 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 16B46130EAA for <mmusic@ietfa.amsl.com>; Tue, 4 Dec 2018 13:21:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.347
X-Spam-Level:
X-Spam-Status: No, score=-3.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-1.459, 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 lmzFdlBuypSx for <mmusic@ietfa.amsl.com>; Tue, 4 Dec 2018 13:21:44 -0800 (PST)
Received: from mail-pf1-x433.google.com (mail-pf1-x433.google.com [IPv6:2607:f8b0:4864:20::433]) (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 7C7EA130E6E for <mmusic@ietf.org>; Tue, 4 Dec 2018 13:21:44 -0800 (PST)
Received: by mail-pf1-x433.google.com with SMTP id g62so8840468pfd.12 for <mmusic@ietf.org>; Tue, 04 Dec 2018 13:21:44 -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=s6WjL3qP1z+ZBHj4CCN+zPtY0njDoHz3rgQDmDQAqz8=; b=MQLjyxEC6OJQjZAe8buDDdg/HW7epOXMSITXh8PhlbfZEan5MKrtugEmiQiFlSi69T oujKO/BCeA+uuDcuPLSTehcM3UzvHoGoGgDHjg2MKA/rVlSmqpjMoOuwGaMsYiB+ltuM GNkPE3w+bFrVOHbr0TOaSaM2a0+Q5rm0h0dp/WV0s2t6Hs1088T6TUFYuEW4l0RMA0cq fbqGzj4EuvMg2qZZUsnZ13xw91QoKrTzwxvYjtyj3q3wHebvBJpp4rVAvRT3bANl770v R3PWBRIhLgFoTZkj9bzZzr0QQvpLzfqJS1PlxQYmwPDNb2yXB11kePKtL0WXAsAEZDJl c8Rg==
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=s6WjL3qP1z+ZBHj4CCN+zPtY0njDoHz3rgQDmDQAqz8=; b=A32/Wdc36aXfKuX55ZErJK7b4VTDzPT+NYHW2m/upnrvUnQhg9ZdfaQk/AGZYv9Kxg dU0b44s/ZZCM98TLrU8xzYWlZCT0smSUvSGXp5Lj05a/9f5q8ZeKoF3YSqPdiKfGWkLO 3oMSWNMgh+3v4ipVaIIAA1N7x6Ax5pIiQttekrkp76DVe7ZvisGrIxpy+kNENzm6/nBu WnIGWDKIrcfyhR5iNXc636dX/KgazHqdrKrJI+Xxd/pew3hjE0ZWR8/Az/kWz3vPi8Tc O/9zuevmmma9hpVGXzvAIOztVw7jjKUKGtMmKqNyz87oK9O4GrReofbGO8Es0YS8Mx2P reLg==
X-Gm-Message-State: AA+aEWaw1HX3HnlGy67TEP5KO+ONx+dZyNkJhKMbPRk4G54YUe4gPQpl HymsxhrEuSCOf4ig5jq+Cm0Ob2LNiy8=
X-Google-Smtp-Source: AFSGD/WLVSPXvmB1m8LaUAp6xMrJbWfYmSNtjpCVh8/OeT6a7nsoD4VUJaOcAhr7wSJgF6pSA49ewg==
X-Received: by 2002:a62:b15:: with SMTP id t21mr22524169pfi.136.1543958504065; Tue, 04 Dec 2018 13:21:44 -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 g28sm33714715pfd.100.2018.12.04.13.21.42 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 04 Dec 2018 13:21:43 -0800 (PST)
Received: by mail-pl1-f176.google.com with SMTP id y1so4109998plp.9; Tue, 04 Dec 2018 13:21:42 -0800 (PST)
X-Received: by 2002:a17:902:2f03:: with SMTP id s3mr21092354plb.277.1543958502575; Tue, 04 Dec 2018 13:21:42 -0800 (PST)
MIME-Version: 1.0
References: <CA+9kkMADnZJBaV0hfLuwGU0bGBEP5tCPZ=8Zd_85Dgzi37ghAQ@mail.gmail.com> <CAD5OKxsNFFmER__H0+5Mzts58yn9cWLMEADhSnLR4nreKD9WAQ@mail.gmail.com> <9B9B741B-622F-4565-899B-700636408F6C@iii.ca> <CAD5OKxv9r08RLvMSM4h11A6sXU9E=u_8Qvy-TBfjNcwkhcqf3w@mail.gmail.com> <54ebb208-e7b3-a0f1-6a5c-4745d3a56447@cisco.com> <CAD5OKxut5Lr+Bmyc20y+vV=+_RESw+h72DYLnt3G1_BjS6sTVA@mail.gmail.com> <1346FE48-5D61-48B7-BF37-3D7BAA930DB0@iii.ca> <CAD5OKxv0N+TF3L3bB9KPm4vqQdPZKE=1zkdw1PaV7CpNJ2kYaQ@mail.gmail.com> <110dc822-b3be-7bc2-dcc5-9e6c8277e0d1@nostrum.com> <CAD5OKxtKOLovNCi0cJiEiHD+M3tCda7ZSecU8EJKxVPuFs7maQ@mail.gmail.com> <AM6PR07MB5621291E0EA9E72A8065380A93AE0@AM6PR07MB5621.eurprd07.prod.outlook.com> <AM6PR07MB562184CD3351856DBC45A71B93AE0@AM6PR07MB5621.eurprd07.prod.outlook.com> <AM6PR07MB5621629CDF15C89D5AE048E893AF0@AM6PR07MB5621.eurprd07.prod.outlook.com>
In-Reply-To: <AM6PR07MB5621629CDF15C89D5AE048E893AF0@AM6PR07MB5621.eurprd07.prod.outlook.com>
From: Roman Shpount <roman@telurix.com>
Date: Tue, 04 Dec 2018 16:21:31 -0500
X-Gmail-Original-Message-ID: <CAD5OKxvr_PvirLVTxe0_eaotdv3YwFRF6BM=t=2B+Dzi_kAziA@mail.gmail.com>
Message-ID: <CAD5OKxvr_PvirLVTxe0_eaotdv3YwFRF6BM=t=2B+Dzi_kAziA@mail.gmail.com>
To: Christer Holmberg <christer.holmberg@ericsson.com>
Cc: Adam Roach - SIPCORE Chair <adam@nostrum.com>, RTCWeb IETF <rtcweb@ietf.org>, mmusic WG <mmusic@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000001814a4057c38da11"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/J5ZZ1DD12HnjmdE6O942TJex3B4>
Subject: Re: [MMUSIC] [rtcweb] Default proto transport in JSEP
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, 04 Dec 2018 21:21:46 -0000

Hi,

On Tue, Dec 4, 2018 at 2:04 AM Christer Holmberg <
christer.holmberg@ericsson.com> wrote:

> Also, as far as I understand, JSEP only defines an API, not a network
> protocol, so if you want to be standards compliant on the wire the JS app
> would have to modify the SDP before sending it to the network, and I do not
> think we want that.
>
>
I generally agree. JSEP is API specification and a signaling profile which
specifies in more detail offer/answer procedures which are used by JSEP
compliant end points. So far, JSEP was compliant with existing procedures,
but it made some things more strict. In that sense, using UDP based
protocols during ICE restart is totally within JSEP scope. Changing RFC
5245 and other related ICE documents, including ice-sip-sdp, in
non-backwards-compatible manner by changing procedures during subsequent
offer/answer exchanges which do not change ICE settings should not be
within this document scope. Furthermore,  it seems to be totally
unnecessary except for procedural and editorial reasons.

Regards,
_____________
Roman Shpount

v2.23.0 | Report a Bug | By Email