Re: Simultaneous Peer Connections

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