I was debugging a webrtc trickle ice exchange the other day and realized I never paid much attention to the candidate messages (generated by calling RTCIceCandidate.toJson() ) that look like this:
{"candidate":"candidate:394300051 1 tcp 1518214911 192.168.1.12 9 typ host tcptype active generation 0 ufrag rfBJ network-id 1",
"sdpMid":"0","sdpMLineIndex":0}
In the above json message exactly what do sdpMid and sdpMLineIndex represent? They always appear to have the same values (either 0/"0" or 1/"1").
Is it correct to say:
That sdpMid corresponds to the a=mid line for a stream in the intial SDP? That is, if the line for the audio stream was declared as a=mid:audio, then the candidate's sdpMid value would have been "audio" as well.
That sdpMLineIndex is the index number of the stream as it appeared in the SDP? That is if audio was first in the SDP, then this value is 0 and if video was second it would be 1?
In other words, sdpMid is a string name for the stream and sdpMLineIndex is an index value. But the standard convention used by most implementations is to just have these values be the same.
Is this correct?
sdpMid and sdpMLineIndex are equivalent for the currently browser-generated offers for simple cases. They are not equivalent for cases like stopping a transceiver (using .stop()) and then generating a new offer. This new offer usually has a new mid which can be an incrementally generated number whereas the sdpMLineIndex may not increment if a previously unused m= line gets recycled.
Effectively they are artifacts from very early versions of the specifications and implementations lagging behind (here for Firefox).