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上可用的服务器，并且显然不需要任何凭据。

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

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

我的问题是，在将请求发送到STUN服务器时，ICE处理如何构造STUN请求？它使用短期还是长期凭证？我认为我认为credentialType属性是短期的还是长期的？ STUN服务器如何知道创建消息请求所遵循的过程（短期还是长期）。除非知道，否则它将无法认证请求，除非过程相同。在这种情况下，为什么要区分两者。

Answer 1

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

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

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