Re: [rtcweb] Why is required to have local streams before running ICE gathering? (another SDP limitation?)

Eric Rescorla <ekr@rtfm.com> Thu, 13 June 2013 15:23 UTC

Return-Path: <ekr@rtfm.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 A17D321F99D2 for <rtcweb@ietfa.amsl.com>; Thu, 13 Jun 2013 08:23:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.645
X-Spam-Level:
X-Spam-Status: No, score=-99.645 tagged_above=-999 required=5 tests=[AWL=0.480, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05sLngJ6HPS3 for <rtcweb@ietfa.amsl.com>; Thu, 13 Jun 2013 08:23:46 -0700 (PDT)
Received: from mail-qc0-x229.google.com (mail-qc0-x229.google.com [IPv6:2607:f8b0:400d:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id DD5EF21F99CD for <rtcweb@ietf.org>; Thu, 13 Jun 2013 08:23:45 -0700 (PDT)
Received: by mail-qc0-f169.google.com with SMTP id c10so5499878qcz.14 for <rtcweb@ietf.org>; Thu, 13 Jun 2013 08:23:45 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:x-gm-message-state; bh=9s6huKtweRLjrlYZmVRMX6F55FKOLqre0G3VRyNPjuI=; b=FQT44mXv7H6oMAcaIiAzvd1Rd1MR97cS7ih8w9bxdbuD2bwP/N+6M5j7/aEqxQkHbI 57mdfYFzkoP65EBKStI48yDQKoCmQxb0VZH/JYLNEXUQ65wOkaeotMi5EtjlSd9HNdIF 7BCVmvuP/MXEGeA9AsR77nQkmJ/1/Nz8k+ImCyj3sZdNMNf9gWSz3DGHcjHnFEnJp4tI L9tUHuib1MhKL9t23ZLBmLe694zzykyaVdZMQpJ/aa+0pM4z7EcukZJ3PtBXy207t5gD EmMKcHmOaQ+dU62GhOlwyfQxUlmuigTET+LPRtGTlqidEA7bxR+0kprDrJ1VLpP7pqA9 aYyw==
X-Received: by 10.49.71.203 with SMTP id x11mr2037634qeu.19.1371137025389; Thu, 13 Jun 2013 08:23:45 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.49.0.163 with HTTP; Thu, 13 Jun 2013 08:23:05 -0700 (PDT)
X-Originating-IP: [74.95.2.170]
In-Reply-To: <CABcZeBPFTOi6S4YXUSPTo1pGvT=zM9_bivi9Q7MAg5wSrATfXQ@mail.gmail.com>
References: <CALiegf=ABGSR+CRM-GiMJ-Vmk29-FAyCNgWSFfeneB4V6ObkYQ@mail.gmail.com> <CABcZeBPFTOi6S4YXUSPTo1pGvT=zM9_bivi9Q7MAg5wSrATfXQ@mail.gmail.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Thu, 13 Jun 2013 08:23:05 -0700
Message-ID: <CABcZeBM6NN2jm9s+mrNj759AiQu31R8QdRgkr65gKxOFm0jvjw@mail.gmail.com>
To: =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= <ibc@aliax.net>
Content-Type: multipart/alternative; boundary=047d7b6dc47456489204df0ab78a
X-Gm-Message-State: ALoCoQmdtrSnU6hYa9+yj+M0xXwEKY4JSGRg7dATvhpSm4lxRKJRXW8DWsTEOaKExmLdTjucM4IA
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Why is required to have local streams before running ICE gathering? (another SDP limitation?)
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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: Thu, 13 Jun 2013 15:23:52 -0000

On Thu, Jun 13, 2013 at 8:21 AM, Eric Rescorla <ekr@rtfm.com> wrote:

>
>
>
> On Thu, Jun 13, 2013 at 7:55 AM, Iñaki Baz Castillo <ibc@aliax.net> wrote:
>
>> Hi, let me expose the following simple case:
>>
>>
>> 1) SIP application in the web.
>>
>> 2) Alice receives INVITE from Bob with audio and video.
>>
>> 3) Alice JS UA is ringing, Alice does not answer or reject the call yet.
>>
>> 4) Alice JS UA does not know whether Alice would answer with audio and/or
>> video.
>>
>> 5) Alice JS UA starts ICE gathering and obtains all its ICE candidates.
>>
>> 6) Alice presses "Answer with audio and video".
>>
>> 7) Alice JS UA calls getUserMedia, creates the PC, gets the SDP and
>> passes it to Bob JS UA in a SIP 200 response.
>>
>>
>> Well, this is not possible in WebRTC due to step 5. Unfortunately
>> before ICE gathering, the local PC must be set with the local SDP, so
>> getUserMedia is required to happen before ICE gathering.
>>
>
> I don't think that there is an intention that ICE gathering must not happen
> prior to setLocal:
>
> 1. There is agreement that there should be a mechanism to pre-specify
> the size of a candidate pool to gather, though I just glanced in the spec
> and I didn't see it. (May have missed it though).
>

I see that there still is some (not quite up to date) text here:


   1.

   Create an ICE Agent as defined in
[ICE<http://dev.w3.org/2011/webrtc/editor/webrtc.html#bib-ICE>]
   and let connection's RTCPeerConnection ICE Agent be that ICE Agent and
   provide it the STUN and TURN servers from the configuration array. The ICE
   Agent will proceed with gathering as soon as the IceTransports constraint
   is not set to "none". At this point the ICE Agent does not know how many
   ICE components it needs (and hence the number of candidates to gather), but
   it can make a reasonable assumption such as 2. As the
RTCPeerConnection object
   gets more information, the ICE Agent can adjust the number of components.



   -Ekr





> 2. Firefox, at least, gathers some candidates as soon as the PC is
> created, and I don't think this should be forbidden. (Though there is
> some disagreement about this.)
>
>
>
>
>> But we cannot prompt Alice with the getUserMedia pop-up while she has
>> not yet decided to answer the incoming call.
>>
>> The fact is that both the audio and video will use the same UDP
>> channel/transport, so having ICE candidates for the audio and the
>> video m lines is just unneeded.
>>
>> So IMHO this is another issue due to the usage of SDP, right? or may
>> be I am wrong? If so please let me know a use case in which the
>> browser would mantain two different UDP channels/transports for the
>> same "call" (a single SDP O/A).
>>
>
> It's not a matter of using SDP, it's a matter of being able to interop
> at all with endpoints which don't bundle.
>
> -Ekr
>
>