Re: [rtcweb] We are moving beyond the assumptions on which O/A is based

[Paul Kyzivat <[e-mail]>]

On 5/14/13 12:38 PM, Ted Hardie wrote:
> On Sat, May 11, 2013 at 9:51 AM, Paul Kyzivat <[e-mail]
> <mailto:[e-mail]>> wrote:
>
>     In clue we are addressing that by exchanging (in a separate channel)
>     advertisements of what the endpoints are willing to send, and only
>     doing O/A to set up the media that is of interest.
>
>     In rtcweb it isn't so structured, but I suspect something is
>     happening implicitly, though it may be more hard-wired per application.
>
>
> So, I repeat what I said before, I think you can get to there in RTCWEB,
> but it won't be the same way pokerstars gets to where it wants to go.
>
> The simplest thing I can imagine, to just put it out there, is to start
> RTCWEB with just a data channel, pass the clue messages on top, then
> start the media channels after that's done.  That seems to be reasonably
> in line with what you've described above and it's well within the RTCWEB
> APIs.

I expect the same thing to happen with rtcweb as without it:

An initial offer proposes a data channel and some initial media.

If the other end also supports clue, then it will accept the data 
channel, and some or all of the media, as it sees fit, given that it 
doesn't know what the purpose of that media is yet. (E.g. the media 
might consist of one audio and one video. But it also might be 
optimistic and assume the other end is configured just like it is.)

Then the two sides will exchange clue advertisements over the data channel.

Based on the advertisements, the two sides will then decide what they 
want to receive, and send clue configure messages describing that.

Before or after the configuration messages, if necessary, a new O/A (or 
two) may be exchanged to arrange the media to be consistent with the 
advertisements and configurations.

> What won't happen is for *every* application to adopt that procedure;
> some will want behaviour that looks closer to vanilla offer/answer; some
> will want behaviour that is more-or-less directed by the server, and
> some will want blueberry jam (that is, something we don't know about yet).

Certainly. If the web server supporting the browser does't support clue 
then this isn't going to result in a clue call. But that would only come 
up for *received* calls, and receiving such a call via rtcweb depends on 
having an app that is at least addressable by a clue client. That means 
it must have a sip address. If so, then at least it will probably be 
able to connect as a "legacy" sip device.

My concern it that it be *possible* to do this with rtcweb, preferably 
obscure gateway code.

	Thanks,
	Paul