3.5.2.1. ICE Candidate Format

3.5.2.1. ICE Candidate Format

In JSEP, ICE candidates are abstracted by an IceCandidate object, and as with session descriptions, SDP syntax is used for the internal representation.

The candidate details are specified in an IceCandidate field, using the same SDP syntax as the "candidate-attribute" field defined in [RFC8839], Section 5.1. Note that this field does not contain an "a=" prefix, as indicated in the following example:

candidate:1 1 UDP 1694498815 192.0.2.33 10000 typ host

The IceCandidate object contains a field to indicate which ICE username fragment (ufrag) it is associated with, as defined in [RFC8839], Section 5.4. This value is used to determine which session description (and thereby which gathering phase) this IceCandidate belongs to, which helps resolve ambiguities during ICE restarts. If this field is absent in a received IceCandidate (perhaps when communicating with a non-JSEP endpoint), the most recently received session description is assumed.

The IceCandidate object also contains fields to indicate which "m=" section it is associated with, which can be identified in one of two ways: either by an "m=" section index or by a MID. The "m=" section index is a zero-based index, with index N referring to the N+1th "m=" section in the session description referenced by this IceCandidate. The MID is a "media stream identification" value, as defined in [RFC5888], Section 4, which provides a more robust way to identify the "m=" section in the session description, using the MID of the associated RtpTransceiver object (which may have been locally generated by the answerer when interacting with a non-JSEP endpoint that does not support the MID attribute, as discussed in Section 5.10 below). If the MID field is present in a received IceCandidate, it MUST be used for identification; otherwise, the "m=" section index is used instead.

Implementations MUST be prepared to receive objects with some fields missing, as mentioned above.