STUN 服务器如何知道发送 STUN 请求时使用的是短期凭证还是长期凭证？

Question

RFC 5389 允许对 STUN 服务器进行两种身份验证形式之一：

 ... This section defines two mechanisms for STUN that a client and server
 can use to provide authentication and message integrity; these two
 mechanisms are known as the short-term credential mechanism and the
 long-term credential mechanism.  These two mechanisms are optional,
 and each usage must specify if and when these mechanisms are used.
 Consequently, both clients and servers will know which mechanism (if
 any) to follow based on knowledge of which usage applies.  For
 example, a STUN server on the public Internet supporting ICE would
 have no authentication, whereas the STUN server functionality in an
 agent supporting connectivity checks would utilize short-term credentials.

最流行的 STUN 服务器很可能是 stun:stun.l.google.com:19302 上可用的服务器，显然不需要任何凭据。

iceServers 通过以下对象提供给 RTCPeerConnection：

   myPeerConnection = new RTCPeerConnection({
      iceServers: [
         {
              urls: "turn:turnserver.example.org",
              username: "webrtc",
              credential: "turnpassword"
         }
       ]
   });

我的问题是在向STUN服务器发送请求时，ICE处理是如何构造STUN请求的？它使用短期或长期凭证吗？我认为我看到的 credentialType 属性是被解释为短期还是长期？ STUN 服务器如何知道创建消息请求遵循了哪个过程（短期或长期）。除非它知道这一点，否则它无法验证请求，除非过程相同。既然如此，为什么还要区分两者呢

Answer 1

TURN 分配始终使用长期凭证机制完成，请参见https://www.rfc-editor.org/rfc/rfc5766#section-2.2

对 STUN 服务器的 STUN 请求通常不需要身份验证。

短期凭证机制用于 ICE 等其他事物，请参阅 https://www.rfc-editor.org/rfc/rfc5245#section-4.3

STUN 服务器如何知道发送 STUN 请求时使用的是短期凭证还是长期凭证？

How does a STUN server know whether short-term or long-term credentials were used for sending the STUN request?

webrtc

stun