Re: [rtcweb] Reducing glare

[Iñaki Baz Castillo <[e-mail]>]

2013/5/10 Dale R. Worley <[e-mail]>:
> Two possible solutions for glare problems come to mind:
>
> One is to require the designated "follower" to accept and give a 200
> response to an incoming re-INVITE even if it has an outstanding
> re-INVITE.  The difficulty that follows is that the follower doesn't
> know whether the "leader" has accepted or rejected its re-INVITE until
> the response arrives, so there is an interval (between sending the 200
> to the leader's re-INVITE and receiving the leaders response to its
> re-INVITE) during which the follower doesn't know its outgoing media
> configuration.  We could probably fix that by annotating the leader's
> offers with the o= value of the follower's SDP that the leader
> currently is using.
>
> A second one would be to simply drastically shorten the glare backoff
> timer.  Given that we're talking about video systems, the RFC 3261
> timer ranges of 0 to 2 secs and 2.1 to 4 secs are very slow.  If we
> cut those times by a factor of 10, wouldn't the user-visible problems
> nearly vanish?


A third and better solution would be to stop assuming that SIP
problems are also WebRTC problems. The "glare" problem occurs due to
the artificial mandate of SDP O/A in WebRTC.

Want to avoid the "glare" problem and "SDP v=" number problem? Remove
SDP O/A from WebRTC and you are done. Then if somebody wants to play
with SDP at JS it can do it **at JS level**.

--
Iñaki Baz Castillo
<[e-mail]>