Re: [rtcweb] Proposal to break the ICE impasse

Iñaki Baz Castillo <ibc@aliax.net> Tue, 29 January 2019 19:05 UTC

Return-Path: <ibc@aliax.net>
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 0D1F1130FC2 for <rtcweb@ietfa.amsl.com>; Tue, 29 Jan 2019 11:05:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.042
X-Spam-Level:
X-Spam-Status: No, score=-2.042 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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aliax-net.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 n-rG7Le_MHlZ for <rtcweb@ietfa.amsl.com>; Tue, 29 Jan 2019 11:05:44 -0800 (PST)
Received: from mail-vs1-xe44.google.com (mail-vs1-xe44.google.com [IPv6:2607:f8b0:4864:20::e44]) (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 9C66E130FB8 for <rtcweb@ietf.org>; Tue, 29 Jan 2019 11:05:44 -0800 (PST)
Received: by mail-vs1-xe44.google.com with SMTP id t17so12611383vsc.8 for <rtcweb@ietf.org>; Tue, 29 Jan 2019 11:05:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aliax-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Vhrl6tS4JAc/nvjkV/61ONt/BOtRAAD+b8sVamImUyk=; b=TIN/w9bM1eFCWHdyegvihMr1mF/1WFZcxvb5lrMByouwwUBwFOP2MnizCsapu9T3xa tkb2f68KpNTaKqtOi1b6IcUP680Ni2gp0sk87EvZMQ0PNgNHvRJL9RvKLYnVSlE5sgwi mpY3cMGEmrtfuzqSBbadx0OpXouOdWsKTCkptDdhwvNPPXeulYoCgf522z4Z7a8C4FHA 467sSlptUrM6rBBo8WUKjKqBcKU3/Ei0Lxr0ngejQjw/GGKkf0x4qc3lF6WNfrWx+gRt GDO5epQSgadOjO1AxJfiuMw+zUKSYse0AMUbwW2P6TcIRX5KuJbXLRrYxqrr06GMUayi 0bfQ==
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=Vhrl6tS4JAc/nvjkV/61ONt/BOtRAAD+b8sVamImUyk=; b=NMcsu31yYW87WSTpTnoVNdx39AKtEpbRWgQ0aedFutu2aXtgHTX+q6PqRg5VPfrenG eyQBgXr7htbg7syu2iwB0niN3p3S+/AAmnIZNPGcc4TX2nTEaIgxDo1Ltp6WslSOkbxU hIjmr+hn7mDmbnQMWqEYhO6h5gxGLhNiEZYr3TbEtjX1MOnTSYxwnXMlq6I5U9/ZtirN RbBaZdd0iv77ngmgyCsEv3NspNkh2dU3kRpusjL8t5oePCuDsyqpQDjnDBOl6oQ2tc0z BmzQYQFjURcDRxILBKX+WqyD3ZPAN+p3evz38+N1b6aQkmSKucP3vnioJUsCEi2QNneI a6NQ==
X-Gm-Message-State: AJcUukfIFTutGHeutHaxHuQLSJOUSbn7eC4CPyV/z68iHW7Fj8OXJtCw g1/59p4z0Z1SKYswtZNacB1s/tSmHMBfX0uRMONZxe2k
X-Google-Smtp-Source: ALg8bN4+p5+T7yhdJSEwCrW65DphW5X96NAutZCon4CId/LTZsgcPd8WAbkunntfpfrJXjaP3BW4mEBqq88q1fTTEEY=
X-Received: by 2002:a67:3edc:: with SMTP id a89mr11073870vsi.136.1548788743492; Tue, 29 Jan 2019 11:05:43 -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> <CAD5OKxvm_U=Tgvmxfi8hqiR=8tB_ueQtUSJJV5NLcVL8dBdHtw@mail.gmail.com>
In-Reply-To: <CAD5OKxvm_U=Tgvmxfi8hqiR=8tB_ueQtUSJJV5NLcVL8dBdHtw@mail.gmail.com>
From: Iñaki Baz Castillo <ibc@aliax.net>
Date: Tue, 29 Jan 2019 20:05:31 +0100
Message-ID: <CALiegfm1y_p3wDoXeckSw2BQ61gGYh4c9A7a=p0vi=BnWGoU4A@mail.gmail.com>
To: Roman Shpount <roman@telurix.com>
Cc: nohlmeier@mozilla.com, rtcweb@ietf.org
Content-Type: multipart/alternative; boundary="000000000000e368ee05809d7a7e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtcweb/Py9Csg3qhWjB6rFJl0giQPUO1zw>
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 19:05:47 -0000

I understand your point. But still I don't understand the purpose of the
new draft (set TCP/DTLS/etc in proto line if there are just TCP candidates
in the offer).

Of course, if browser follow the ICE spec and set the selected candidate in
the c/m lines, they must also indicate whether that is over UDP or TCP. The
problem here is what such a proto line is intended to mean when there is
ICE candidates of UDP and TCP. But ok, let's assume that browser do update
c/m lines in the trigger with the selected candidate, and they JUST change
the proto line to TCP/DTLS if there are just TCP candidates. Now thing
about this scenario:

1) Client initial offer with UDP and TCP candidates.

2) Server answers with both UDP and TCP candidates.

3.1) UDP is selected. Re-offer is created with just UDP candidates (as per
spec).

3.2) or TCP is selected. Re-offer is created with just TCP candidates (as
per specs).

In both 3.1 and 3.2 the "monitoring Node" doesn't need to inspect the proto
line. It can just check the protocol (UDP or TCP) of *any* candidate in the
offer to know whether UDP or TCP was selected.

Am I wrong?

El mar., 29 ene. 2019 19:48, Roman Shpount <roman@telurix.com> escribió:

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