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

Roman Shpount <roman@telurix.com> Tue, 20 November 2018 05:31 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 116E912958B for <mmusic@ietfa.amsl.com>; Mon, 19 Nov 2018 21:31:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.89
X-Spam-Level:
X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_PERMERROR=0.01] 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 4hFtN-jEabSX for <mmusic@ietfa.amsl.com>; Mon, 19 Nov 2018 21:31:17 -0800 (PST)
Received: from mail-pl1-x62b.google.com (mail-pl1-x62b.google.com [IPv6:2607:f8b0:4864:20::62b]) (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 37DB6127332 for <mmusic@ietf.org>; Mon, 19 Nov 2018 21:31:17 -0800 (PST)
Received: by mail-pl1-x62b.google.com with SMTP id z23so430470plo.0 for <mmusic@ietf.org>; Mon, 19 Nov 2018 21:31:17 -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=P7zCR/SdVEA1VTuQ2W8NsiEyXjx/sG977jhbkAG6ejI=; b=rB3pt5saN4LSCCTyqTHh3cIGmmqhmPmzimAD/XLQH6e7rcQeB299ZnfzfuMZ2U0EZs xfKfIynQkaByu9mppI4h5eeo83NBlxfFN5pySGZSRrJCwPUw3VueccuIt3kM1w+QabwS YpbwUwTpvI2LPnu3zuAPvnlNh96pwRRkrSfPRyBkDX38qHz0IF7ZUJxCp9OIauquU5v+ iO0Fyutf5obEmWMtb29aKDu2rdDDwnYsNXgYV4PWJkktW8MPMTEV55J+iZ+oJ8EPMp5P Lb9M8oVQwRmyG7Nx8o0A7ltM0xMNBTsM8oydn1vxHiZIGMsWqsJdLmRIQtSqJFyXw+Ag qZVQ==
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=P7zCR/SdVEA1VTuQ2W8NsiEyXjx/sG977jhbkAG6ejI=; b=b4KoKsHb70FTNWB33wz+JoJbniAtzw5ReARGKP9F85cdqsuWCmMKj7WtXpAoCjiZmb wMw+irLAM4QAMcW6RD+ognQDL4nzaGsfPMeh6Z/f2j14Tj/d0bh/70E/IXm69GjLe4yt fLkZtSsCIdots/4R3IQzghUwRyhOMTn7TpQawvXffhaLYzSSamCDkpIGKScXVi8BY4wx 79RV0le7mRHozSytwV+8lLs974ZoY3kXf3LdedcVSu53/7yuTOyoQL+Ng/3QEnPXbYDV 2LfykC1JxqnvCcWQtTJLAVwnf7IQgidyk/P8vtn24zA89FbZSI6jV888NTcpq7n0UBkd Nhlg==
X-Gm-Message-State: AA+aEWbgHBMOHj6R1ydfmwFVDINy1gBLa3zEK/GW3aaZn9JgkKZM+swk ZK7z5iTkf4ht69T5ciiyfYMDwA==
X-Google-Smtp-Source: AFSGD/WduKWCvgwsXKL2f7NGbxIK7r/W73+7jCl5Qlj3tNpc5OG0p3iklz5Pif7olouBTORf4YYkHA==
X-Received: by 2002:a17:902:2006:: with SMTP id n6-v6mr761096pla.131.1542691875300; Mon, 19 Nov 2018 21:31:15 -0800 (PST)
Received: from mail-pg1-f173.google.com (mail-pg1-f173.google.com. [209.85.215.173]) by smtp.gmail.com with ESMTPSA id a73-v6sm49828698pfj.38.2018.11.19.21.31.14 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 19 Nov 2018 21:31:14 -0800 (PST)
Received: by mail-pg1-f173.google.com with SMTP id s198so388423pgs.2; Mon, 19 Nov 2018 21:31:14 -0800 (PST)
X-Received: by 2002:a63:b4c:: with SMTP id a12mr659276pgl.131.1542691873731; Mon, 19 Nov 2018 21:31:13 -0800 (PST)
MIME-Version: 1.0
References: <CA+9kkMADnZJBaV0hfLuwGU0bGBEP5tCPZ=8Zd_85Dgzi37ghAQ@mail.gmail.com> <CAD5OKxsNFFmER__H0+5Mzts58yn9cWLMEADhSnLR4nreKD9WAQ@mail.gmail.com> <CALiegfkHXv6f8P3C-C=2RKCyxWfzCAzkzOqxBXmmsNCPrZzFfg@mail.gmail.com> <CAD5OKxswZdGm1CYvy=NoyEtN-eFFp7Sc8mmGT7jAJ-q3msJYXA@mail.gmail.com> <CALiegfmFV=988+WuViUQRGJRgR=mcqS9Y+eDnL4pH6VrbJRvCQ@mail.gmail.com> <CAD5OKxtwuQu0du+ptmJpX0ALQnUtjLG==NanP8OB51D4M9fYhg@mail.gmail.com> <CALiegfnMbwTruVKU-VnsZvddqRhnuCm1k8zLcLSuWSs9zT1JUA@mail.gmail.com> <CAD5OKxtxAiBbVY4HQjfjwqfsGoUxAZzmmrTWVfe7pG6MTsHGRA@mail.gmail.com> <CALiegfnVOFvUKYMRp7z0Q3aVyzbi=+JuyXmH+PL6_pNW9j9PVA@mail.gmail.com> <CAD5OKxtpepraJWVbJy2+x_4pFbeqF57=yh1GVF-WoYGBX1OV-Q@mail.gmail.com> <CALiegf=ffb1UL0FPrk770Q-ACQL-ySAqxBzB1M0yJXZUM6y9sg@mail.gmail.com> <CAD5OKxtj=nEWjOWztcAVMDsFOFRGO7hQaKUsn-Pqbk7Ma64Trg@mail.gmail.com> <CALiegfno4y5P-qLkrxSs0zLbEEUo1HWyp0rfEA8KecRjTQ43sQ@mail.gmail.com> <CAOJ7v-2o1Se9zaMgktQtwNW46zvB2i7Hk7+GK1yhWJV5xcT7ZA@mail.gmail.com> <CAD5OKxveNtx3uD7tD_mTgE-Rv2JTZPBmjk34iUJD9uw25-ZCzQ@mail.gmail.com> <CAOJ7v-1V_vtq+szN6299kw9dH_TOz9sxa+YYwQkBwHeJPoqvgA@mail.gmail.com>
In-Reply-To: <CAOJ7v-1V_vtq+szN6299kw9dH_TOz9sxa+YYwQkBwHeJPoqvgA@mail.gmail.com>
From: Roman Shpount <roman@telurix.com>
Date: Tue, 20 Nov 2018 00:31:02 -0500
X-Gmail-Original-Message-ID: <CAD5OKxt6JyFXsdANSX13LytLsosRQUnP5oKoR1PUjZmJyP0kxw@mail.gmail.com>
Message-ID: <CAD5OKxt6JyFXsdANSX13LytLsosRQUnP5oKoR1PUjZmJyP0kxw@mail.gmail.com>
To: Justin Uberti <juberti@google.com>
Cc: Iñaki Baz Castillo <ibc@aliax.net>, RTCWeb IETF <rtcweb@ietf.org>, mmusic WG <mmusic@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000021b8e3057b11f187"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/JT9tVIdpQO6-qzlrVFdB3ymJxXY>
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, 20 Nov 2018 05:31:19 -0000

On Mon, Nov 19, 2018 at 11:41 PM Justin Uberti <juberti@google.com> wrote:

> Are you aware of any implementations that will trigger ICE mismatch if the
> proto does not match? Also, this would only happen in situations where the
> client offers *only* TCP candidates, which would require manual filtering
> by the client and is clearly a corner case.
>

I think a couple of popular hardware VoIP phones and one widely used SIP
based business communication/messaging product will trigger a mismatch in
case of incorrect protocol (non UDP if UDP candidates are present and non
TCP, if only TCP candidates are present according to their ICE
implementation document). I have to say, that these things do have a
tendency to change between product updates and I have not tested this
product for a while. Our own products currently match the protocol to
default candidate, so we did not need to retest this issue.

TCP based transport will happen for any subsequent offer/answer exchange
when TCP candidate is nominated. Only a single TCP ICE candidate will be
present in the session description, so that protocol in m= line will have
to be TCP. In case of the above mentioned product, their ICE protocol
implementation document says that call must be terminated, if in subsequent
offer, protocol in the m= line does not match the protocol in the ICE
candidate.

Regards,
_____________
Roman Shpount