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

[Ted Hardie <[e-mail]>]

On Tue, May 7, 2013 at 3:07 PM, Adam Roach <[e-mail]> wrote:

> 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.
>
> Well, the overview document is pretty careful in its terminology:

"

      The RTCWEB media negotiations will be capable of representing the
       same SDP offer/answer semantics that are used in SIP [RFC3264
<http://tools.ietf.org/html/rfc3264>],
       in such a way that it is possible to build a signaling gateway
       between SIP and the RTCWEB media negotiation.

"


>
>    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.
>
>
I think the tweak I'm thinking of here is a shift from "used by RTCWEB" to
"supported by RTCWEB".
It's not critical, since it is motivation text rather than specification,
but it did strike me.



>
>  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.
>
>
It seems like this would require a similar Supported header to that
described in the draft and an Info package for changing roles.  Is there a
more efficient way to do that?  Or am I missing something else?

regards,

Ted Hardie


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