Thinking

如何进行度量驱动调优:

• 一是在设计阶段就考虑调优，设定性能目标

• 二是在开发的各个阶段进行考量 - Optimization of the metrics, by the metrics, for the metrics

• 三是必须遵循 PDCA 这个闭环： 计划，执行，检查和调整

Quote

用于 STUN 的准许刷新协议

Session Traversal Utilities for NAT (STUN) Usage for Consent Freshness

refer to http://www.rfcreader.com/#rfc7675

To prevent attacks on peers, endpoints have to ensure the remote peer1 is willing to receive traffic.

When a session is first established, ICE implementations obtain an initial consent to send by performing STUN connectivity checks.

Consent is obtained only by full ICE implementations. An ICE-lite agent (as defined in Section 2.7 of [RFC5245]) does not generate connectivity checks or run the ICE state machine.

Consent: The mechanism of obtaining permission from the remote endpoint to send non-ICE traffic to a remote transport address.

准许：它是一个获取准许的机制，允许一个远程端点发送非 ICE 的流量到另一个远程传输地址

Consent is obtained using ICE. Note that this is an application-level consent; no human intervention is involved.

准许是通过使用 ICE 来获得的，它是一种应用层的准许，不需要人工交互。

Consent Freshness: Maintaining and renewing consent over time.

准许刷新：随着时间维持和更新准许

Program

• Q. How to make white noise?

refer to https://mdn.github.io/webaudio-examples/audio-buffer/

let AudioContext = window.AudioContext || window.webkitAudioContext;
let audioCtx;

function makeWhiteNoise(channels) {

  if(!audioCtx) {
    audioCtx = new AudioContext();
  }

  // 采样率即每秒的采样个数，创建一个2秒的立体声缓冲
  let frameCount = audioCtx.sampleRate * 2.0;
  console.log("sampleRate: ", audioCtx.sampleRate, ",frameCount: ", frameCount);

  let myArrayBuffer = audioCtx.createBuffer(channels, frameCount, audioCtx.sampleRate);

  //在此缓冲里填充白噪声，也就是 [-1.0, 1.0] 之间的随机值
  for (let channel = 0; channel < channels; channel++) {
   // This gives us the actual array that contains the data
   let nowBuffering = myArrayBuffer.getChannelData(channel);
   for (let i = 0; i < frameCount; i++) {
     // Math.random() is in [0; 1.0]，audio needs to be in [-1.0; 1.0]
     nowBuffering[i] = Math.random() * 2 - 1;
   }
  }

  // 先创建一个 AudioBufferSourceNode 作为源节点
  let source = audioCtx.createBufferSource();
  // set the buffer in the AudioBufferSourceNode
  source.buffer = myArrayBuffer;
  // 连接这个 AudioBufferSourceNode 到目标节点
  // destination so we can hear the sound
  source.connect(audioCtx.destination);
  // 开始源节点的播放
  source.start();

  source.onended = () => {
    console.log('White noise finished');
  }
}

• Q. How to mute mic?

    function muteMic(stream, bMute) {
        if (!stream) {
            return；
        }
        var tracks = stream.getAudioTracks();
        if (tracks.length) {
            for (var i = 0; i < tracks.length; i++) {
                tracks[i].enabled =!(bMute);
            }
        }

    };

WebRTC

Program

WebRTC 端点需要支持的 RTP 协议的相关特性和扩展：

Support for use of multiple simultaneous synchronization source (SSRC) values in a single RTP session, including support for RTP endpoints that send many SSRC values simultaneously, following [RFC3550] and [RFC8108]. The RTCP optimizations for multi-SSRC sessions defined in [RFC8861] MAY be supported; if supported, the usage MUST be signaled.

1) 支持多路复用，多个 SSRC为标识的流出现在一个会话中

Random choice of SSRC on joining a session; collision detection and resolution for SSRC values (see also Section 4.8).

2) 在一个会话中随机选择 SSRC 及 SSRC 值的冲突检测和解决

Support for reception of RTP data packets containing contributing source (CSRC) lists, as generated by RTP mixers, and RTCP packets relating to CSRCs.

3) 支持 RTP header 中的 CSRC 列表

Sending correct synchronization information in the RTCP Sender Reports, to allow receivers to implement lip synchronization; see Section 5.2.1 regarding support for the rapid RTP synchronization extensions.

4) 在 RTCP 发送者报告中发送正确的同步信息，以让接收者实现唇同步，参见 RFC6051

Support for multiple synchronization contexts. Participants that send multiple simultaneous RTP packet streams SHOULD do so as part of a single synchronization context, using a single RTCP CNAME for all streams and allowing receivers to play the streams out in a synchronized manner. For compatibility with potential future versions of this specification, or for interoperability with non-WebRTC devices through a gateway, receivers MUST support multiple synchronization contexts, indicated by the use of multiple RTCP CNAMEs in an RTP session. This specification mandates the usage of a single CNAME when sending RTP streams in some circumstances; see Section 4.9.

5) 支持多个同步上下文，共用一个 CNAME

Support for sending and receiving RTCP Sender Report (SR), Receiver Report (RR), Source Description (SDES), and BYE packet types. Note that support for other RTCP packet types is OPTIONAL unless mandated by other parts of this specification. Note that additional RTCP packet types are used by the RTP/SAVPF profile (Section 4.2) and the other RTCP extensions (Section 5). WebRTC endpoints that implement the Session Description Protocol (SDP) bundle negotiation extension will use the SDP Grouping Framework "mid" attribute to identify media streams. Such endpoints MUST implement the RTCP SDES media identification (MID) item described in [RFC8843].

6) 支持这些 RTCP 消息： SR, RR, SDES 和 BYE

Support for multiple endpoints in a single RTP session, and for scaling the RTCP transmission interval according to the number of participants in the session; support for randomized RTCP transmission intervals to avoid synchronization of RTCP reports; support for RTCP timer reconsideration (Section 6.3.6 of [RFC3550]) and reverse reconsideration (Section 6.3.4 of [RFC3550]).

7) 支持一个RTP会话中的多个端点，对 RTCP 传输的间隔进行调整

Support for configuring the RTCP bandwidth as a fraction of the media bandwidth, and for configuring the fraction of the RTCP bandwidth allocated to senders -- e.g., using the SDP "b=" line [RFC4566] [RFC3556].

8) 支持对 RTCP 的带宽的配置，作为媒体带宽中的一份子

Support for the reduced minimum RTCP reporting interval described in Section 6.2 of [RFC3550]. When using the reduced minimum RTCP reporting interval, the fixed (nonreduced) minimum interval MUST be used when calculating the participant timeout interval (see Sections 6.2 and 6.3.5 of [RFC3550]). The delay before sending the initial compound RTCP packet can be set to zero (see Section 6.2 of [RFC3550] as updated by [RFC8108]).

9) 支持减少 RTCP 最小间隔时间

Support for discontinuous transmission. RTP allows endpoints to pause and resume transmission at any time. When resuming, the RTP sequence number will increase by one, as usual, while the increase in the RTP timestamp value will depend on the duration of the pause. Discontinuous transmission is most commonly used with some audio payload formats, but it is not audio specific and can be used with any RTP payload format.

10) 支持不连续的传输

Ignore unknown RTCP packet types and RTP header extensions. This is to ensure robust handling of future extensions, middlebox behaviors, etc., that can result in receiving RTP header extensions or RTCP packet types that were not signaled. If a compound RTCP packet that contains a mixture of known and unknown RTCP packet types is received, the known packet types need to be processed as usual, with only the unknown packet types being discarded.

11) 忽略未知的 RTCP 包类型和 RTP 头扩展

Words

take a rain check】 字面意思是“拿一张雨票”。

短语起源来自美国的棒球文化，如果棒球比赛，因恶劣天气而不得不终止，官方将给观众交换券(check)，凭此券可以观看下一次的比赛。

🌧️ 由此衍生出了 take a rain check，用于表达“将约定改期”的情况下。

🍐️Thank you, but I have to take a rain check on your invitation.
谢谢你，但很抱歉我不能接受你的邀请，改天吧。

🍐️Would you like to have dinner with me tonight? 你愿意和我共进晚餐吗？

🍐️I'll take a rain check! I've got stuff to do. 改天吧，我有点事。