WebRTC Peer Connection generated ICE candidates do not use SDP MID of the original offer

[jp-fournier-dev]

When working with an iOS we've encountered a bug related to how the ICE candidates are generated : it seems we don't adjust the sdpMid value to match the offer received from the mobile device.

For example, iOS gives us SDP with the following mid :

a=group:BUNDLE audio video
...
a=mid:audio
...
a=mid:video

while Android is giving us the following :

a=group:BUNDLE 0 1
...
a=mid:0
...
a=mid:1

This works well without trickle, since when the SDP answer is generated by the RTC Peer Connection, the mid are conserved from the offer. Meanwhile, when ICE candidates are generated and sent as we go, they do not get adjusted with the according mid. This causes iOS to ignore the candidates and for the connection to only be tested using the candidates that are in the SDP.

Using workaround I can make this work and was curious what is the stance on this ? Should it be the responsability of another element to fix the candidates ? There's a chicken and egg situation here, where to generate candidates accurately, you need to have the offer in hand to begin with and set the mid according to it. Given that the RTCPeerConnection starts gathering immediately, is the better way to go to restartIce once the offer is applied and only get the candidates from then?

[sipsorcery]

I think restarting the ICE gaterhing would be inefficient especially if there are TURN servers involved.

Seems like the best way would be to update the mid's on the already gathered ICE candidates or some kind of mapping from the initial mid to the new ones supplied in the offer.

[jp-fournier-dev]

I'll probably go from there indeed.

The only way I see this working otherwise is by permitting constructing the RTCPeerConnection with an offer in hand already so that the generated ICE candidates can be modified by the session before the event is raised, but that would require reworking the initialization phase of the connection