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

[Eric Rescorla <[e-mail]>]

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

-Ekr