Working on the glare control resolution for a WebRTC session, the media (getusermedia) is grabbed at the time of session initiation or answer.
Both sides of the session (side A and side B) initiate the session at the same time resulting in an SDP Offer being received by each side while they are expecting an SDP Answer.
The solution that i have used is that a unique token is allocated to each signaling channel (i.e., side A and side B have different tokens) and used similarly to ISUP to perform glare control (e.g., the lower or higher side token wins).
The actual mechanism i use, and which seems to work, is based on the side that has the lower token of the two being allowed to continue the session initiation and ignoring the remote SDP Offer and the remote side creating a new PeerConnection and then processing the received offer on the new PeerConnection and attaching its media when ready to the new PC. Subsequently the ICE candidates from the allowed initiating side are processed.
Question is - is there any downside or danger to grabbing a new PC to process the received offer on? (the original PC on which the losing side was trying to initiate is dropped, and i assume garbage collected at some point).
So something which might (though i am not sure) be problematic is that i do not currently delete the ICE candidates that arrived after the SDP Offer which is ignored assuming that these ICE candidates will still be valid.
But any thoughts on this greatly appreciated.
