Re: Simultaneous Peer Connections

On 24/06/2013 1:53 PM, Adam Roach wrote:
> On 6/24/13 12:39, cowwoc wrote:
>> On 24/06/2013 1:31 PM, Dan Ristic wrote:
>>> I am running into an issue with simultaneous peer connections 
>>> between users. The issue is when pairing WebRTC with a presence 
>>> service, if user A sees user B and initiates a connection at the 
>>> same time that user B sees user A and initiates a connection back 
>>> both of them are in offer states. Since they are both in offer 
>>> states neither of them can accept the other offer request without 
>>> either creating two connections or jumping through hoops to figure 
>>> out who is the leader and who is the follower and dropping one of 
>>> the requests.
>>>
>>> My question would be if the spec would be able to handle such a case 
>>> and if not, what is the best way to get around this issue? I am 
>>> pretty much building the jumping through hoops part into my 
>>> JavaScript library to avoid this issue and it is proving to be a 
>>> hassle of getting the timing right.
>>
>>     I ran into a similar problem. I ended up programming the server 
>> to prevent this situation. Once a peer sends an offer, the server 
>> rejects any offers from the second peer. If the first peer gets 
>> disconnected their offer eventually times out and you can retry.
>
> This condition, in which both sides attempt to make a simultaneous 
> change to call state, is known as "glare." Handling of glare on 
> initial connection setup is something that the IETF and W3C have left 
> up to applications.The initial ROAP proposal did include a procedure 
> for resolving this kind of situation (see 
> http://tools.ietf.org/html/draft-jennings-rtcweb-signaling-01#section-5.4.1), 
> but the RTCWEB WG ultimately chose to work on JSEP instead (which 
> simply says "[T]he actual mechanism by which these offers and answers 
> are communicated to the remote side, including... glare handling, is 
> left entirely up to the application.")
>
> That said, leaving it "entirely up to the application" is completely 
> compatible with using the approach described by ROAP. At a high level: 
> you include a random integer in your initial offer message. If you get 
> an offer from the other side before you get an answer, you compare 
> your number against the one sent by the other side. If yours is 
> smaller, you lose the race: destroy the peerconnection you had 
> created, and make a new one to deal with the incoming offer. If yours 
> is larger, you win the race: ignore the inbound offer and wait for the 
> answer. For the rare chance in which both ends selected the same 
> number, both sides send an error and the call fails.
>
> /a

     Interesting approach! Coming back to Dan's recent post (that he 
handles the problem on the client side), I don't think that this is 
something that can be handled exclusively by the peers unless they have 
a way to communicate out-of-bound of WebRTC. Meaning, if all you could 
do is send back/forth SDP and Ice Candidates, there would be no way for 
you to resolve this problem. You'd have to cheat by sticking the 
out-of-bound information in the SDP or something.

Gili