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

Eric Rescorla <> Thu, 13 June 2013 15:22 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id ADB0621F99CD for <>; Thu, 13 Jun 2013 08:22:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -99.166
X-Spam-Status: No, score=-99.166 tagged_above=-999 required=5 tests=[AWL=0.960, 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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id dd58e1cst5-m for <>; Thu, 13 Jun 2013 08:21:56 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c01::22b]) by (Postfix) with ESMTP id 893DC21F99C5 for <>; Thu, 13 Jun 2013 08:21:53 -0700 (PDT)
Received: by with SMTP id n1so2419453qcw.2 for <>; Thu, 13 Jun 2013 08:21:53 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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=7vxE87QVYYgybifqTeWZPnVKe3aDSX9LNG6v3GtBD1E=; b=EatcxizKRaxBRvZWup1XhGWVWpiQFOo5yrESBB9Vql+yQhAknUqnx1WL72vv13W8Bg o7uK9tjRCYl0NQxoFJZ703IHC0RR8Lcp+9gLgC7j9ccnGH2d53h6t/NxWDFs4u6ZrK31 JLlzO7WJW4XzcMHpbv4fsgjHUGLoTUw8LZEKSw7oORq7qWw9G4h9WCbQP5p7lta6tR54 33oYbyyp32Wr2w1bP6zej6uIy7E2XXdEORKT3qe3c0sC0bXcwq/jXSOW3Gmg6kZOg/HI OvTAOD6Ut8KWj9nD5YPpQpsdel3RCSnirh2rsOlrfYSkGkjqjH3EQUBMrF892dua3BV4 6GZA==
X-Received: by with SMTP id fo8mr3528784qab.62.1371136912927; Thu, 13 Jun 2013 08:21:52 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Thu, 13 Jun 2013 08:21:12 -0700 (PDT)
X-Originating-IP: []
In-Reply-To: <>
References: <>
From: Eric Rescorla <>
Date: Thu, 13 Jun 2013 08:21:12 -0700
Message-ID: <>
To: =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= <>
Content-Type: multipart/alternative; boundary=20cf3005dc0aa2497504df0ab06b
X-Gm-Message-State: ALoCoQlhBirH9dOHoWhBFHqkcHvwJvxsCEv9qFiAnaKQYFKuT3Rjf45rk5922SI+4PS8jZpUeYwN
Cc: "" <>
Subject: Re: [rtcweb] Why is required to have local streams before running ICE gathering? (another SDP limitation?)
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 13 Jun 2013 15:22:02 -0000

On Thu, Jun 13, 2013 at 7:55 AM, Iñaki Baz Castillo <>; 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).

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.