Re: [rtcweb] Signalling, SDP, and the way we think about interconnecting RTCWEB applications

[Wolfgang Beck <[e-mail]>]

> You're making the argument that no federation is needed, because to contact
> someone on stackexchange you'd browse to stackexchange first.
>
> I don't think that handles the use-cases of, from within say gmail, you try
> to call someone on Stackexchange - or even more unavoidable, you try to
> invite someone from stackexchange to join your already-running call.  You
> can't exit out and load the stackexchange JS client.
>
Good point. Browsers have iframes and tabs in which I can render web
pages of different
sites in parallel. The browser has to deal with the case when more
than one JS client
tries to access the microphone or speaker.

Your first case is easy. I simply open a new tab or window and make the call.
Consultation calling should be easy, too: I have two browser windows,
one with party B, one
with party C. I could talk to them in turns by simply switching between windows.
Conferencing would require that the browser can move media streams
between its JS instances.

I'll go through this old list of IN services and check where my model fails.
http://www.cs.columbia.edu/~library/TR-repository/reports/reports-1999/cucs-002-99.ps.gz

I still refuse to understand RTCWEB as a MEGACO with javascript syntax..


Wolfgang