Re: [rtcweb] Let's define the purpose of WebRTC

[Wolfgang Beck <[e-mail]>]

On Mon, Nov 7, 2011 at 4:14 AM, Randell Jesup <[e-mail]> wrote:
> On 11/6/2011 9:01 AM, Tim Panton wrote:
>> [..]
>
> For example, you mention forking and glare.  Well, I've given very
> non-interop cases of where forking would be useful: contacting someone who
> has 2 desktops, a notebook, a tablet, and a phone all logged into the
> service, or some of the game scenarios, or a very non-standard-SIP-like mesh
> conference using forked invites.
Do you really need forking to achieve this? Couldn't you just return
references to those devices back to the caller
which can then decide how to call them? A redirect server instead of a
forking proxy?

Forking is a good example how interop -- with SIP or with different
RTCWEB apps -- complicates things significantly.

> And glare: Cullen's classic example of glare is two people talking, browser to browser, and one saying "lets add
> video", and both turning it on.  No interop or SIP required for that to
> cause glare.
If your service requires this function, yes, you're right. It has
nothing to do with SIP and interop.

The question is: does a JS client have to deal with glare handling if
it can exclude conflicting offers by other means. My 'click here to
speak to a human' application might never need this at all.

> And RTP muxing? That's to avoid the startup-delay of having to
> ICE multiple ports (and the funny side-effects if they choose different
> paths).  Yes that does add some requirements to think about for interop;
> that's not subverting the charter or drifting from it.
>
RTP muxing has little to with RTCWEB. If it is a good thing, SIP and
other protocols using RTP/ICE should profit from it, too.



Wolfgang Beck