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

[Adam Roach <[e-mail]>]

On 5/7/13 16:17, Ted Hardie wrote:
> Taking the first look at this, there were two quick issues I wanted to
> mention.  The first is this text:
>
> "In the offer-answer model used by RTCWEB, "glare" arises when
> offer messages "cross on the wire" (that is, both parties in a session
> attempt to change the session at the same time)."
>
> While RTCWEB is being built to support offer/answer, there is no
> requirement that an application use that model for the interaction
> between two clients.

I'm not sure that's right. When calling setRemoteDescription / 
setLocalDescription, the RTCSessionDescription objects contain a 
mandatory "type" field that must be "offer", "answer", or "pranswer." 
This really makes the 3264 offer/answer model pretty thoroughly baked 
into the system.

>   So, this wording might need to get a tweak.

If I'm wrong above, I'm happy to take text that explains this fact. I 
can't craft any right now, since I don't know how you would set up a 
WebRTC session (I say WebRTC since we're really talking about the API 
side of things here) without use of offer/answer.

> 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.

> Is this because you're concerned that it would add a round trip?

I think it's more like half a round trip, but it's not worth splitting 
hairs over. In any case, I'm not terribly concerned about an extra 
(half-)round-trip delay for mid-session media changes.

/a