Steps to reproduce
Seems Edge has a bug regarding ICE replies. Official RFCs require the USERNAME attribute MUST NOT be present. But Edge is sending USERNAME attribute in replies and does appear to reject our ICE responses from ORTC Lib that do not contain USERNAME attribute.
According to: https://tools.ietf.org/html/rfc5245#section-126.96.36.199
… A connectivity check
from R to L utilizes the username LFRAG:RFRAG and a password of
LPASS. The responses utilize the same usernames and passwords as the
requests (note that the USERNAME attribute is not present in the
If these checks pass, the agent continues to process the request or
indication. Any response generated by a server MUST include the
MESSAGE-INTEGRITY attribute, computed using the password utilized to
authenticate the request. The response MUST NOT contain the USERNAME
But edge does not appear to like our STUN response packets (as the ICE transport does not go into the “connected” state on the Edge side) and sends us USERNAME in ICE BIND responses. This seems to follow the MSDN articles on the topic where I noticed that MS has STUN BIND reply behavior defined wrongly.
The USERNAME attribute MUST have the same value as the USERNAME attribute in the corresponding STUN binding request message. The MESSAGE-INTEGRITY attribute MUST have the message integrity value that is computed by using the password of the local candidate in the matching candidate pair.
If a STUN binding response message is received without a USERNAME attribute, it MUST be discarded. The USERNAME attribute MUST be used to find the matching transport address pair for which the STUN binding response message is received.
NOTE: We understand that your implementation is partially conformant when considering Google’s ICE implementation, but Google support both methods in their WebRTC lib, Edge does not and is also not conformant with the STUN spec.
Comments and activity
- Microsoft Edge Team
Changed Status to “Duplicate”
Thanks for reporting the issue to us. It seems you opened two bugs for the same topic. We are resolving this one, and will track the issue with the other bug you opened (i.e. 7718294).
All the Best, MS Edge Team