Re: [rtcweb] Quick comments on draft-roach-rtcweb-glareless-add-00

[Paul Kyzivat <[e-mail]>]

On 5/7/13 6:07 PM, Adam Roach wrote:

>> Second, it seems like the avoidance of glare by having a single
>> offer/answerer at a time would work in most cases, but I'm wondering
>> why the initial exchange isn't simply a request to change roles? If
>> the initial offer role is determined by time, one of the options seems to
>> be to accede to a request by the other client to become the offerer.
>
> That's an interesting approach that certainly works just fine. It's
> probably worth documenting as an alternative. One thing to note is that
> the technique described in my draft is something applications can apply
> unilaterally without any standardization work; whether they choose to
> perform a solicitation/offer/answer or role-switch/offer/answer is
> something implementors can decide to do as they see fit. Implementations
> can even do both, with the decision about which approach to use at any
> given moment dictated by which works best for the current application
> behavior.
>
> The only real twist this introduces is for the work described in section
> 3. If we think this role switching behavior is useful, then it's
> probably something that we would want to include in any equivalent SIP
> mechanisms.

If find the approach in the draft very unappealing. The persistent 
answerer must send a solicitation that describes the offer it wants the 
persistent offerer to make on its behalf. You don't explain how this 
would be encoded, but in general it must be like a delta on the last 
offer it received. So it will be at least as complex as SDP itself, but 
different. I expect that defining that will be difficult. But its 
further complicated because there is no defined signaling to carry it. 
At least with what we have so far the signaling *can* carry SDP offers 
and answers. (Though something else can be used.)

Switching to the scheme Ted suggests makes it much simpler, since the 
only new thing required is a signal to request the role change.

Note that the "change roles" request is just a variation on token 
passing. The relationship between single-offerer+change-roles and normal 
O/A is like that between token ring and ethernet. We know how that 
battle turned out.

I remain dubious that this glare situation is a problem that needs to be 
fixed. How often will it occur in practice? Is it really worth totally 
changing the model, and debugging the new one, to fix? And what happens 
when you interoperate with a traditional O/A app?

	Thanks,
	Paul