Re: [rtcweb] Proposal to break the ICE impasse

Roman Shpount <roman@telurix.com> Tue, 29 January 2019 18:48 UTC

Return-Path: <roman@telurix.com>
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 43CDC130FB4 for <rtcweb@ietfa.amsl.com>; Tue, 29 Jan 2019 10:48:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.031
X-Spam-Level:
X-Spam-Status: No, score=-2.031 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] 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 iIJOwD0cC1lp for <rtcweb@ietfa.amsl.com>; Tue, 29 Jan 2019 10:48:50 -0800 (PST)
Received: from mail-pg1-x52a.google.com (mail-pg1-x52a.google.com [IPv6:2607:f8b0:4864:20::52a]) (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 7A2A5130F88 for <rtcweb@ietf.org>; Tue, 29 Jan 2019 10:48:50 -0800 (PST)
Received: by mail-pg1-x52a.google.com with SMTP id z11so9135028pgu.0 for <rtcweb@ietf.org>; Tue, 29 Jan 2019 10:48:50 -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=WfrGccs8rK1J+wh/ZvBwbVMzQFRNniAwyl/YM5CCgR0=; b=C8bJ9PAIS7SpRrimybwdAqNhtMnEwRmZZhwClOnDJCoM3J6opKBBpHvqUV7SvzMj63 nz5boLpy6bmY4xtqfZVbzSZGwkYCwBI34OT1xn/ViBp2p2kHzzpal5zT/CQNOOMl8n10 Dc82XEPixuCKshpHOstqvcoH2w9O7Ht60BsE51zehAzYLMgriuvLqGJb/CKi5zr0v5Sz BtFn+Tcn80208huAwM4LjaD8Mxh2oLAK8GeLNi1f/DUrx2s9ZV4VxcGpTUFnl4Y89LQj tlRWT8o7eQGnXsoMTl4zK12lqzYsaWaS8ZZ8mkBkcgT9uE/xXsYn/Daf758HRFOSPVfm aFBQ==
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=WfrGccs8rK1J+wh/ZvBwbVMzQFRNniAwyl/YM5CCgR0=; b=Oydgns/42pV3ZCLAk0Bbe6CGLH4sgQv+pLnznbPauhFqmcqGKyJXrFkHSfCf7DZpxC SXZMkAl0E+JYjH1ptilXkUOsufinSzn4akwx1HWAcQwTSK8BqQ08yBsf/xUKqpdkrejJ XRNoFw5DDL4tScgRU+/VWYiG5OnlgEpJFGILPVbuvuvl3kNvOglrR7buauLRrjKlR/MA 4eWbd3nqmhO6wGzfL94DGW7ELvpcCxmBkeJmdcgrnkKJDTK91Bi/g4klWI/OrRmKypfu PwoYGK+WV1OIzYwD1XiTq07x4QfBQe3TgSnNT3tjM0Ww7822qfKslcnXozZ/0o70HKXY x2wg==
X-Gm-Message-State: AJcUukfPre8nrLK9nEwC5tDEtNxciL0p1SHsBejZEWswoicZ7olD85bY qZFjCdvK6kmL9X5fikCgS0yuqSptRLc=
X-Google-Smtp-Source: ALg8bN4UoPtDWOen97tjBkn/+zpIPBFPqce+IvtOYu2W3w175qH/HnDzXAH3+7FOnJhs+xDMy7+OxA==
X-Received: by 2002:a63:62c4:: with SMTP id w187mr22802293pgb.230.1548787729689; Tue, 29 Jan 2019 10:48:49 -0800 (PST)
Received: from mail-pg1-f171.google.com (mail-pg1-f171.google.com. [209.85.215.171]) by smtp.gmail.com with ESMTPSA id 202sm47392566pfy.87.2019.01.29.10.48.48 for <rtcweb@ietf.org> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 29 Jan 2019 10:48:49 -0800 (PST)
Received: by mail-pg1-f171.google.com with SMTP id g189so9120630pgc.5 for <rtcweb@ietf.org>; Tue, 29 Jan 2019 10:48:48 -0800 (PST)
X-Received: by 2002:a62:160d:: with SMTP id 13mr27145672pfw.203.1548787728605; Tue, 29 Jan 2019 10:48:48 -0800 (PST)
MIME-Version: 1.0
References: <97ed2641-8a7e-19a9-be38-a3458ca9212e@nostrum.com> <CABcZeBP9t0SgsHAuENo99D6ffKd7Mw0Xs1vzUCOzSS=WJN5z8A@mail.gmail.com> <HE1PR07MB3161B0F1D2B5AC9DA72DDFAD93950@HE1PR07MB3161.eurprd07.prod.outlook.com> <CAOJ7v-3KHi0TUDsQvG6qq-qeNGBsqLxg+NC1c+Nxvgy0ks0d0g@mail.gmail.com> <CABcZeBNL=sWFfh=zwiuib80HPsno=GzF18gU+z3DrCZTK_PquA@mail.gmail.com> <CA+9kkMDh56CeXRGNSk_r-HrLkDNT5DnYc_FguXOdeccfq=LEMA@mail.gmail.com> <CABcZeBPboLf0bLUDTyJArxsPYSnUrULArmsZ9YshQCX+rEvexA@mail.gmail.com> <CA+9kkMCwCBHWEEADxVHT2ZbvWEi=bUBJ22icKHpA2p8Kg1fF9A@mail.gmail.com> <CALiegfnpj+Pu0Hg05iqHXCwhTefxn_Em7gTnzOXK897fzcyuwg@mail.gmail.com> <CAD5OKxvmQHT3TAt_=xCd_JKnPzXfnc=Mej-mr6KMsaKVoBkuSg@mail.gmail.com> <CALiegfm_jtv1bV3Ok6j20hkim8e6QxMYPrbbHejqoHnCHjMXpA@mail.gmail.com> <CAD5OKxsMWEE39O6hSc+UFjwTAa=z1A+XD5X2BY=Q7PEUdYE4UA@mail.gmail.com> <961E55AE-2072-4145-8BCF-62D67C6D150F@mozilla.com> <CAD5OKxuwhmAPvonV1rX1rN6yi08-4NPH1BOzVuJPUMEntnpRkw@mail.gmail.com> <CALiegfmZ_DSe7EFw48C6HoQ+bUReom4r0TTMf4wRG6UyAbgX2w@mail.gmail.com>
In-Reply-To: <CALiegfmZ_DSe7EFw48C6HoQ+bUReom4r0TTMf4wRG6UyAbgX2w@mail.gmail.com>
From: Roman Shpount <roman@telurix.com>
Date: Tue, 29 Jan 2019 13:48:37 -0500
X-Gmail-Original-Message-ID: <CAD5OKxvm_U=Tgvmxfi8hqiR=8tB_ueQtUSJJV5NLcVL8dBdHtw@mail.gmail.com>
Message-ID: <CAD5OKxvm_U=Tgvmxfi8hqiR=8tB_ueQtUSJJV5NLcVL8dBdHtw@mail.gmail.com>
To: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= <ibc@aliax.net>
Cc: Nils Ohlmeier <nohlmeier@mozilla.com>, RTCWeb IETF <rtcweb@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000065696105809d3e4a"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtcweb/jsJO_Lkw-9z-29WxPa8srbHHSnk>
Subject: Re: [rtcweb] Proposal to break the ICE impasse
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: Tue, 29 Jan 2019 18:48:53 -0000

On Tue, Jan 29, 2019 at 1:33 PM Iñaki Baz Castillo <ibc@aliax.net> wrote:

> On Tue, 29 Jan 2019 at 19:05, Roman Shpount <roman@telurix.com> wrote:
>
> > During steps 1-4, browser client sends an offer which includes both UDP
> and TCP candidates. It is using one of the UDP candidates as a default
> candidate in c= and m= line (proto is UDP/... something). Server, also
> responds with UDP and TCP candidates. It also uses one of the UDP
> candidates as a default candidate in c= and m= line (proto is UDP/...
> something). Since client location blocks everything except TCP, only the
> connectivity check for TCP candidate pair succeeds and TCP candidate gets
> nominated. Once ICE nomination process is completed, new offer is generated
> from the client without ICE restart (for instance to add a codec or
> initiate "fix up" offer). This offer must include locally nominated
> candidate pair and no other candidates (
> https://tools.ietf.org/html/draft-ietf-mmusic-ice-sip-sdp-24#section-3.4.1.2.2).
> This means this offer will only have TCP candidates present. This TCP
> candidate is the default candidate and will be used in c= and m= line
> resulting in TCP/... proto in the m= line.
>
> This is a very good point:
>
> > This (re)offer must include locally nominated candidate pair and no
> other candidates
>
> But how is the draft above useful at all if browsers do not set the
> selected candidate into c=/m= lines during a re-offer? Imagine browser
> do implement the draft above and, indeed, they set "TCP/DTLS/..." in
> the proto line of the re-offer with just TCP candidates. Assuming that
> they do NOT set the selected candidate pair in the m=/c= line, this is
> just valid to know whether UDP or TCP has been selected, nothing else.
> Am I wrong?
>

One way to interpret JSEP in its current state, that it specifies that
address and port in c= and m= line should be updated to the selected
candidate, but proto should always be UDP/..., even if address in c= and
port in m= lines are from the TCP candidate. All I am asking, is if end
point updates address c= and port in m= line, it should update the proto to
match.

In the other side, and assuming this is about JavaScript SIP+WebRTC
> clients, wouldn't it work if they mangle the SDP re-offer? By checking
> the peerconnection stats you can know the selected candidate and so
> on.
>
>
JS SIP + WebRTC clients are one of the issues. For instance, it is possible
to build a network using JS SIP clients (jssip works great :), regular VoIP
clients that support DTLS-SRTP (for instance something pjsip based), and
SBC which support DTLS-SRTP+ICE TCP. All are connected to the SIP-over-WS
enabled proxy. CDRs and monitoring are done from proxy using proxy
generated CDR and SIP signaling capture using something like SIP Homer. The
simplest way to get client connection information is by using "fix-up"
offers and extracting data from SIP signaling. It is possible to build a
separate monitoring solution for WebRTC clients using stats, but using
existing SIP based solutions already works well enough except for bogus
info about nominated candidate in c= and m= lines.

Regards,
_____________
Roman Shpount