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

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 13 Jun 2013 16:55:03 +0200

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
<[email-masked]>

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 13 Jun 2013 08:21:12 -0700

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

> 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

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 13 Jun 2013 08:23:05 -0700

> 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

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Fri, 14 Jun 2013 13:53:56 +0200

2013/6/13 Eric Rescorla <[email-masked]>:
> Create an ICE Agent as defined in [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.

Hi Eric, thanks a lot for the information you provide.

Is it feasible with the current API to ask for N ICE candidates prior
to having the local SDP set as local descriptor in the PeerConnection?

--
Iñaki Baz Castillo
<[email-masked]>

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 14 Jun 2013 06:59:22 -0700

> to having the local SDP set as local descriptor in the PeerConnection?
That has been discussed (and I thought agreed upon) but I don't see
it in the spec.

-Ekr

---

From: Jim Barnett <[email-masked]>
Date: Fri, 14 Jun 2013 17:46:26 +0000

You can call updateICE at any point.  I also recall us agreeing to let you specify the number of candidates, but it's not in the spec. If it gets added to updateICE then you would be able to specify the number of candidates before setLocal.

On Jun 14, 2013, at 10:01 AM, "Eric Rescorla" <[email-masked]<mailto:[email-masked]>> wrote:

On Fri, Jun 14, 2013 at 4:53 AM, Iñaki Baz Castillo <[email-masked]<mailto:[email-masked]>> wrote:

-Ekr

_______________________________________________
rtcweb mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Justin Uberti <[email-masked]>
Date: Sat, 15 Jun 2013 16:40:28 -0700

> getUserMedia is required to happen before ICE gathering.

This should be possible today. You can set the local description with no
MediaStreams but the constraint OfferToReceiveVideo:true to start candidate
gathering for both audio and video.

When you do eventually get the stream, you can call setLocalDescription
again, to indicate whether video is to be used or not.

> same "call" (a single SDP O/A).

This happens in any non-BUNDLE scenario.

> [email-masked]

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 17 Jun 2013 18:53:05 +0200

Thanks to both, it seems what we need for implementing the desired feature.

-- 
Iñaki Baz Castillo
<[email-masked]>