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

转向分配总是使用长期凭证机制来完成，请参阅https://www.rfc-editor.org/rfc/rfc5766#section-2.2。

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

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