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

Iñaki Baz Castillo <ibc@aliax.net> Thu, 13 June 2013 14:55 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 268B621F941D for <rtcweb@ietfa.amsl.com>; Thu, 13 Jun 2013 07:55:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.677
X-Spam-Level:
X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
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 MLJOK7qYjSKZ for <rtcweb@ietfa.amsl.com>; Thu, 13 Jun 2013 07:55:26 -0700 (PDT)
Received: from mail-qe0-f44.google.com (mail-qe0-f44.google.com [209.85.128.44]) by ietfa.amsl.com (Postfix) with ESMTP id E885E21F91A5 for <rtcweb@ietf.org>; Thu, 13 Jun 2013 07:55:25 -0700 (PDT)
Received: by mail-qe0-f44.google.com with SMTP id 5so4143944qeb.31 for <rtcweb@ietf.org>; Thu, 13 Jun 2013 07:55:23 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type :content-transfer-encoding:x-gm-message-state; bh=l2AZRKp2fc4pHK/DpTR5IBPBrCJifB3HeNfYY0EETJs=; b=FNpXjK8GDS//QNrrPjxb14J/Sv0ht+sYCrlVROV8/C+9NC3ufEUnlWdH9f8a/G55KF SSUwKNA357YgFff07PvsHZnFcHA2DC27fHoE4kotNMtHStWxsB8CIf7tSijEajvSgv+c sN/G+gIM6HhCaq4V1wVY7S58X0uqqH9vAMD8SMEaayeGWS0pvgOIv53lZRe6V8k69/Az bZuGBymYp2gklMtwl6mRPLHDbb+SWRuUNvpx0Uxz3eXX0MRN7IN4S7vC5K34YplaqmNk MU4uf+SA/aiLo8EX7P/qllJ9mCkOnRmX+rbMc6dfxjII77kTF+1jlt+8KGGCFk37l74t ugXA==
X-Received: by 10.224.187.129 with SMTP id cw1mr3450140qab.68.1371135323117; Thu, 13 Jun 2013 07:55:23 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.49.67.65 with HTTP; Thu, 13 Jun 2013 07:55:03 -0700 (PDT)
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= <ibc@aliax.net>
Date: Thu, 13 Jun 2013 16:55:03 +0200
Message-ID: <CALiegf=ABGSR+CRM-GiMJ-Vmk29-FAyCNgWSFfeneB4V6ObkYQ@mail.gmail.com>
To: "rtcweb@ietf.org" <rtcweb@ietf.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Gm-Message-State: ALoCoQlfilbUhK6cNpI5a4e/Sf2RmjTApvmXpH5wl4xYf4QZq7xa8Qm36/jgqGP/t86dY7CMwyr1
Subject: [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 14:55:31 -0000

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.

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

This is just for "legacy interoperability", right? this is, for the
case in which the remote peer is a not-full-WebRTC device and uses
different UDP channels/transports for each m line in the SDP. If so,
would not be MUCH easier just to *require* as per WebRTC specs that
two peers MUST use a single UDP channel/transport for each SDP O/A?

Thanks a lot.



--
Iñaki Baz Castillo
<ibc@aliax.net>