东莞市网站建设_网站建设公司_表单提交_seo优化

SIP环境下G.711A/G.711U负载架构与传输机制深度研究报告

1. 引言与背景综述

随着全球通信基础设施从电路交换（Circuit-Switched）向分组交换（Packet-Switched）的全面演进，基于IP的语音传输（VoIP）已成为现代通信的核心支柱。在这一复杂的协议栈与编码生态中，ITU-T G.711标准始终占据着不可撼动的基石地位。尽管宽带编码（如G.722、Opus）和低码率压缩编码（如G.729、G.723.1）在特定场景下表现优异，G.711凭借其极低的算法延迟、几乎为零的计算复杂度以及与传统PSTN（公共交换电话网）的无缝兼容性，依然是企业级SIP中继、运营商互联以及紧急呼叫服务的首选编码标准 。

本报告旨在对SIP（Session Initiation Protocol）环境下的G.711 A律（G.711A/PCMA）与μ \muμ律（G.711U/PCMU）的负载架构进行详尽的技术解构。报告将不仅局限于编解码原理的阐述，更将深入剖析其在SIP信令中的协商机制、SDP（Session Description Protocol）描述模型、RTP（Real-time Transport Protocol）封装细节、以及在以太网传输层面的带宽开销与流量工程特性。通过整合RFC标准文档、ITU-T建议书以及实际网络工程数据，本研究将揭示看似简单的64 kbit/s音频流背后的复杂协议交互与网络动力学。

2. 脉冲编码调制（PCM）的理论基础与数学模型

G.711本质上是脉冲编码调制（Pulse Code Modulation, PCM）的一种实现形式。理解G.711在SIP网络中的行为，首先必须深入其模拟信号数字化的数学原理。

2.1 采样定理与频带选择

G.711标准遵循奈奎斯特-香农采样定理（Nyquist-Shannon Sampling Theorem），该定理指出，为了无失真地恢复一个模拟信号，采样频率必须至少是信号最高频率的两倍。人类语音的主要能量和清晰度集中在300Hz至3400Hz的频带范围内。为了涵盖这一范围并留有保护频带（Guard Band）以防止混叠，传统电话系统定义了4kHz的有效带宽。因此，G.711采用8000Hz的采样率（即每秒8000次采样），采样周期为125微秒（μ s \mu sμs）1。

2.2 量化与对数压扩（Companding）

如果在8000Hz的采样基础上采用线性量化（Linear Quantization），为了保证小信号（低音量语音）的信噪比（SNR），需要非常高的位深（至少12-14位），这将导致极高的数据传输速率。然而，人耳对声音强度的感知遵循韦伯-费希纳定律（Weber-Fechner Law），即听觉系统对低强度信号的变化比对高强度信号的变化更为敏感——这是一种对数关系。

为了利用这一生理声学特性，G.711引入了非线性量化，即压扩（Companding = Compression + Expansion）。在编码端，大信号被压缩，小信号获得更多的量化级数；在解码端进行逆向扩展。这一机制使得8位（1字节）的样本能够实现相当于13位或14位线性PCM的动态范围，从而将比特率恒定在64 kbit/s（8000 samples/s × 8 bits/sample 8000 \text{ samples/s} \times 8 \text{ bits/sample}8000samples/s×8bits/sample）。

2.3 A律（A-law）与μ \muμ律（μ \muμ-law）的算法差异

G.711标准定义了两种互不兼容的压扩算法：A律和μ \muμ律。这种分裂源于历史上的地缘技术路径差异。

2.3.1μ \muμ律（G.711U / PCMU）

m u \\mumu律主要应用于北美（美国、加拿大）和日本。其设计初衷是提供略高于A律的动态范围。μ \muμ律将14位有符号线性PCM样本压缩为8位。

其连续压缩特性由以下公式定义：

F ( x ) = sgn ⁡ ( x ) ln ⁡ ( 1 + μ ∣ x ∣ ) ln ⁡ ( 1 + μ ) F(x) = \operatorname{sgn}(x) \frac{\ln(1 + \mu |x|)}{\ln(1 + \mu)}F(x)=sgn(x)ln(1+μ)ln(1+μ∣x∣)​

其中μ = 255 \mu = 255μ=255，− 1 ≤ x ≤ 1 -1 \le x \le 1−1≤x≤1。
在数字实现中，m u \\mumu律处理流程包含一个关键步骤：零电平处理。m u \\mumu律算法允许存在正零和负零，但在实际传输中，静音（零输入）通常被编码为0xFF而不是0x00。这是因为标准规定在传输前对所有位进行反转，以确保持续的信号密度，利于T1线路的时钟恢复。因此，在Wireshark抓包中观察到的静音PCMU载荷通常由连续的FF字节组成。

2.3.2 A律（G.711A / PCMA）

A律主要应用于欧洲、中国、南美及世界其他大部分地区。其设计更注重计算机处理的简便性。A律将13位有符号线性PCM样本压缩为8位。

其压缩曲线在原点附近是线性的，而在较高幅度处是对数的，公式如下：

F ( x ) = { sgn ⁡ ( x ) A ∣ x ∣ 1 + ln ⁡ ( A ) if ∣ x ∣ < 1 A sgn ⁡ ( x ) 1 + ln ⁡ ( A ∣ x ∣ ) 1 + ln ⁡ ( A ) if 1 A ≤ ∣ x ∣ ≤ 1 F(x) = \begin{cases} \operatorname{sgn}(x) \frac{A |x|}{1 + \ln(A)} & \text{if } |x| < \frac{1}{A} \\ \operatorname{sgn}(x) \frac{1 + \ln(A |x|)}{1 + \ln(A)} & \text{if } \frac{1}{A} \leq |x| \leq 1 \end{cases}F(x)={sgn(x)1+ln(A)A∣x∣​sgn(x)1+ln(A)1+ln(A∣x∣)​​if∣x∣<A1​ifA1​≤∣x∣≤1​
其中A = 87.6 A = 87.6A=87.6。

A律的一个显著特征是它在小信号处提供了稍好的信噪比（SQNR），但动态范围略小于m u \\mumu律。在位级操作上，A律仅反转偶数位（bit 1, 3, 5, 7）。静音通道在A律下通常编码为0xD5（因为0输入映射到某一级并通过偶数位反转产生0xD5）。

2.4 互操作性挑战

由于量化曲线不同，PCMA与PCMU不能直接混用。如果通过PCMU解码器播放PCMA流，声音将严重失真且音量异常。因此，跨区域呼叫（例如从中国致电美国）必须在网关或SBC（会话边界控制器）处进行转码（Transcoding）。由于两者都是基于样本的查表转换，这种转码几乎不引入延迟，计算开销极低。

3. SIP信令与SDP协商机制详解

在VoIP呼叫建立阶段，SIP（RFC 3261）负责信令控制，而SDP（RFC 4566）承载于SIP消息体中，负责媒体能力的协商。G.711的协商看似简单，实则包含严格的规范约束。

3.1 SIP INVITE请求剖析

一个典型的SIP INVITE请求包含了呼叫双方的逻辑寻址信息。

• Request-URI:指定呼叫的目标地址。
• Via Header:记录请求经过的路由路径，用于响应消息的回送。
• Call-ID:唯一标识一个SIP对话（Dialog）。对于同一通电话的G.711媒体流，SDP协商可能发生多次（如Re-INVITE进行呼叫保持），但Call-ID保持不变。
• User-Agent:标识发起方的软硬件信息（如Avaya SIP Softphone或Cisco IOS），这对于排查G.711实现兼容性问题至关重要。

3.2 SDP Offer/Answer 模型中的G.711

SDP采用Offer/Answer模型（RFC 3264）来确定双方共同支持的媒体格式。

3.2.1 媒体行（m-line）与静态负载类型

G.711拥有IANA分配的静态负载类型（Static Payload Type），这是其区别于现代编码（如Opus, G.711.0）的重要特征。

• Payload Type 0:严格对应PCMU(G.711μ \muμ-law, 8000Hz, 单声道)。
• Payload Type 8:严格对应PCMA(G.711 A-law, 8000Hz, 单声道)。

一个典型的SDP Offer片段如下：

代码段

m=audio 16482 RTP/AVP 8 0 101
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=ptime:20

在此例中：

• m=audio 16482 RTP/AVP 8 0 101 表示发送方希望在UDP端口16482接收音频，首选PCMA（8），次选PCMU（0），并支持DTMF信号（101）。
• 虽然a=rtpmap:8 PCMA/8000对于静态负载类型在技术上是可选的（因为PT 8的定义是固定的），但在实际工程中，为了最大化兼容性并明确时钟频率，现代SIP栈几乎总是包含此行。
• 优先级逻辑：m行中负载类型的顺序决定了优先级。如果SBC或网关配置了特定的编解码策略（例如强制使用低带宽编码），它可能会在转发SDP时重写此列表，剥离G.711或改变其顺序。

3.2.2 打包时长（ptime）协商

a=ptime:20 属性定义了打包时长（Packetization Time），即每个RTP数据包中包含的音频时长，单位为毫秒。

• 默认值：20ms是VoIP行业的通用标准。
• 计算关系：
  • 采样率 = 8000 Hz。
  • 20ms时长 =0.020 t i m e s 8000 = 160 0.020 \\times 8000 = 1600.020times8000=160个样本。
  • G.711位深 = 8 bit (1 byte)。
  • 负载大小 = 160 Bytes。
• 协商非对称性：RFC 3264规定ptime是发送方的属性，但在实际会话中，如果一方发送ptime:20而另一方发送ptime:30，大多数DSP（数字信号处理器）可以处理非对称的打包时长，但某些严格的传统设备可能会出现缓冲区欠载（Underrun）或溢出（Overflow）。

3.2.3 动态负载类型与G.711.0

与标准G.711不同，G.711.0（无损压缩扩展）必须使用动态负载类型（通常在96-127之间）。

• SDP示例：m=audio 20000 RTP/AVP 98 配合 a=rtpmap:98 G711-0/8000。
• 这是因为G.711.0没有分配静态PT。在SDP协商中，必须明确映射PT值到编码名称，并且可能包含额外的格式参数（fmtp）来指定压缩律（A律或μ \muμ律）。

4. RTP传输层架构与封装细节

一旦SIP协商完成，语音数据将通过RTP协议（RFC 3550）进行传输。RTP为G.711流提供了实时性所需的序列号、时间戳和同步源标识。

4.1 RTP头部结构及其对G.711的意义

RTP头部固定为12字节，这对于仅有160字节负载的G.711数据包来说，是不可忽视的开销（占比约7%）。

字段深度解析:

• Version (V=2):协议版本。
• Padding §:对于G.711语音流，此位通常为0。如果加密算法要求块对齐，可能会置1并添加填充字节。
• Extension (X):通常为0。但在某些高级监控场景（如RTCP-XR）中可能会使用扩展头。
• CSRC Count (CC):混音器（Mixer）使用此字段。点对点呼叫中为0。
• Marker (M):标记位。这是G.711流中最具争议的字段之一。
  • 规范用法：RFC 3551建议在静音抑制（Silence Suppression）开启时，Talkspurt（语音段）的第一个数据包将M位置1，其余置0。这通知接收端的抖动缓冲区（Jitter Buffer）复位或重新同步。
  • 实际工程问题：许多实现（尤其是老旧网关）会错误地在所有包上置1，或者从不置1。高级媒体服务器（如rtpengine）通常忽略M位，主要依赖时间戳连续性来判断流状态，以避免错误的缓冲区复位导致音频断裂。
• Payload Type (PT):承载SIP协商的结果（0或8）。如果RTP流中的PT与SDP协商不一致（例如协商了PT 8却收到了PT 0），大多数DSP会丢弃数据包或产生严重噪音。
• Sequence Number (16 bits):用于检测丢包和乱序。在G.711 20ms模式下（50pps），序列号每约21分钟循环一次（65536 / 50 / 60 65536 / 50 / 6065536/50/60）。
• Timestamp (32 bits):关键的时序信息。
  • 对于G.711，时钟频率固定为8000Hz。
  • 每个20ms数据包的时间戳增量应严格为160(8000 × 0.020 8000 \times 0.0208000×0.020)。
  • 抖动（Jitter）的计算完全依赖于接收时间与此时间戳的偏差。
• SSRC (32 bits):同步源标识符，随机生成，用于区分同一会话中的不同流（如在会议混音场景中）。

4.2 负载封装 (Payload Packing)

G.711的RTP负载极其简单：直接将PCM样本按时间顺序排列。

• 没有额外的头部（不同于iLBC或Opus的特定负载头）。
• 字节序：由于G.711是8位样本，不存在字节序（Endianness）问题。但如果涉及16位线性PCM转换，则需注意网络字节序（Big-Endian）。

5. 带宽开销分析与网络流量工程

在规划VoIP网络时，仅仅计算编解码器的比特率（64 kbps）是严重的错误。必须考虑完整的协议栈开销，尤其是在以太网（Layer 2）层面。

5.1 协议栈开销层级分解

以标准的20ms G.711数据包为例，分析其在物理线缆上的真实占用。

1. Voice Payload (L7):
   • 大小: 160 Bytes。
   • 速率:64.0 kbps。
2. RTP Header:
   • 大小: 12 Bytes。
   • 累计包长: 172 Bytes。
3. UDP Header:
   • 大小: 8 Bytes。
   • 累计包长: 180 Bytes。
4. IP Header (IPv4):
   • 大小: 20 Bytes (无Option)。
   • 累计包长: 200 Bytes。
   • L3带宽:200 × 8 × 50 = 80.0 kbps 200 \times 8 \times 50 = 80.0 \text{ kbps}200×8×50=80.0kbps。
   • 分析：IP/UDP/RTP 带来了25%的额外开销（16kbps）。
5. Ethernet Frame Overhead (L2):
   这是最容易被忽略的部分。
   • MAC Header:14 Bytes (6 Dest + 6 Src + 2 Type)。
   • FCS (CRC):4 Bytes。
   • Preamble (前导码):7 Bytes (物理层同步，Wireshark不可见)。
   • SFD (帧首定界符):1 Byte (Wireshark不可见)。
   • Inter-Frame Gap (IFG/IPG):12 Bytes (帧间最小空闲时间，9.6微秒)。
   • L2总开销:14 + 4 + 7 + 1 + 12 = 38 14+4+7+1+12 = 3814+4+7+1+12=38Bytes。
   • (注：若使用802.1Q VLAN Tag，需额外增加4 Bytes)。

5.2 真实带宽计算表（以太网环境）

下表展示了不同打包时长对G.711最终带宽需求的影响。

深度洞察：

• 20ms 标准配置下，G.711实际占用带宽接近100 kbps，而非64 kbps。在计算WAN链路（如MPLS专线）容量时，必须使用95.2 kbps作为基准，而非64 kbps，否则会导致严重的拥塞丢包。
• PPS 压力：10ms打包虽然降低了10ms的算法延迟，但将路由器和防火墙的PPS处理压力翻倍（从50pps增至100pps），且带宽暴增至126.4 kbps，通常不建议在公网环境使用。

5.3 压缩RTP (cRTP) 的作用

在低速串行链路（如卫星链路或旧式帧中继）上，RFC 2508定义的cRTP可以将40字节的IP/UDP/RTP头压缩至2-4字节。

• 对于20ms G.711，开启cRTP后，单包大小降为160 + 4 + 38 = 202 160 + 4 + 38 = 202160+4+38=202Bytes（假设L2开销不变，实际链路层开销可能不同）。
• 带宽降为约80.8 kbps。
• 代价是路由器的CPU利用率显著上升，因为需要维护每条流的压缩状态上下文。

6. 高级功能与互操作性扩展

6.1 静音抑制（VAD）与舒适噪音（CNG）

为了节省带宽，SIP协商中可启用VAD（Voice Activity Detection）。

• 机制：当说话人停止发声，发送端停止发送RTP包，或仅发送低频的**SID（Silence Insertion Descriptor）**帧。
• G.711附录II：定义了G.711专用的DTX（不连续传输）机制。
• CNG负载：在SDP中通常协商为 a=rtpmap:13 CN/8000。接收端根据收到的CN包生成模拟背景噪音，避免听者误以为通话断线。
• 争议：在高质量G.711连接中，VAD常被禁用（a=vad:no），因为VAD的启动延迟可能导致语音“切头”（Clipping），且背景噪音的突变会降低主观体验（MOS分）。

6.2 丢包隐藏（PLC）

G.711作为波形编码，对丢包非常敏感。丢失一个20ms的包会产生明显的爆破音。

• G.711附录I：标准化了PLC算法。当检测到序列号不连续时，解码器通过分析前一个包的波形频率和相位，合成一个“修补”包来填补空隙。
• 效果：带有PLC的G.711可以容忍约1-2%的随机丢包而保持可接受的清晰度；无PLC的实现只要超过0.5%丢包率即可感知到质量下降。

6.3 G.711.0 无损压缩

RFC 7655 定义的G.711.0是一个重要的技术演进。

• 原理：它是一种无损压缩算法，专门针对G.711的PCM样本进行熵编码。解码后的数据与原始G.711样本逐位一致（Bit-exact）。
• 优势：可以在不损失任何语音质量的前提下，减少约40-50%的带宽（取决于语音内容的熵）。
• 应用：主要用于SBC之间的骨干网传输。SBC将G.711转为G.711.0进行长途传输，在边缘解压回G.711交付给终端，终端无需支持G.711.0。
• 限制：G.711.0不应与VAD同时使用，且其不仅压缩语音，也能有效无损压缩经过G.711透传的Modem信号。

6.4 传真与DTMF处理

• DTMF:虽然G.711可以带内传输DTMF音频，但压缩（尤其是A/μ \muμ律转换）可能导致频率失真。SIP通常协商RFC 2833/4733（telephone-event, PT 101）来将按键作为独立的数据包传输，而非音频波形。
• Fax:传真机发出的模拟信号可以通过G.711透传（Pass-through）。但这要求网络极度稳定（低抖动、无丢包）且必须禁用VAD和回声消除（EC）。更可靠的方式是T.38，但在T.38协商失败时，G.711透传是标准的回退机制。

7. 常见故障与排查策略

7.1 单通（One-way Audio）

• 现象：一方听不到声音。
• G.711特定原因：由于G.711流量较大（50pps），某些防火墙的“UDP泛洪攻击保护”阈值如果设置过低，会误判G.711流为攻击并丢弃。
• NAT问题：SDP中声称的IP（Connection Information c=）是内网IP，而RTP流实际来自NAT后的公网IP。如果SBC没有开启“RTP Latching”或“Symmetric RTP”功能，将无法正确转发音频。

7.2 机器人音（Robotic Voice）与咔塔声

• 机器人音：通常是由于网络抖动（Jitter）超过了接收端Jitter Buffer的容量，导致大量丢包，PLC算法频繁介入合成语音，产生金属质感的假声。
• 咔塔声（Clicks）：可能是时钟漂移（Clock Drift）。如果发送端声卡时钟是8001Hz，接收端是7999Hz，每秒会有2个样本的差值。累积一段时间后，缓冲区会溢出或欠载，导致丢弃或插入一段静音，形成周期性的咔塔声。

7.3 转码噪声

• A/m u \\mumu律转换错误：如果配置错误导致A律流被当做m u \\mumu律解码（反之亦然），语音将变得极度嘈杂且音量忽大忽小。通过Wireshark播放流并手动切换解码格式可以轻易诊断此类问题。

8. 结论与展望

尽管通信技术日新月异，G.711 A/m u \\mumu律凭借其“简单即是美”的哲学，依然是全球VoIP网络的通用语言。对于SIP工程师而言，掌握G.711不仅仅是知道“64k”这个数字，更需要深刻理解其从对数压扩原理、SDP协商细节、RTP封装结构到以太网物理开销的全链路行为。

在未来的网络演进中，G.711.0无损压缩技术将扮演更重要的角色，它在保持G.711通用性和质量优势的同时，解决了其带宽效率低下的痛点。同时，随着全光网和5G的高带宽普及，G.711作为一种无压缩、低延迟的编码，在对实时性要求极高的交互式应用中仍将保持其核心地位。

参考文献引用说明：
本文档分析基于RFC标准文档及行业技术白皮书，引用来源包括：
6 关于G.711及G.711.0的IETF RFC标准。
4 关于SIP/SDP协商机制。
1 关于PCM压扩算法原理。
2 关于网络带宽开销计算。
3 关于互操作性与故障排查。

引用的著作

1. G.711 - Wikipedia, 访问时间为 十二月 28, 2025， https://en.wikipedia.org/wiki/G.711
2. VoIP Bandwidth Calculation, 访问时间为 十二月 28, 2025， https://www.cs.ru.ac.za/courses/honours/rtmm/software/52-voip-bandwidth.pdf
3. Answer Processing and Examples - Oracle Help Center, 访问时间为 十二月 28, 2025， https://docs.oracle.com/en/industries/communications/session-border-controller/8.1.0/acliconfiguration/answer-processing-and-examples.html
4. Understanding SIP Traces - Simwood Support Centre, 访问时间为 十二月 28, 2025， https://support.simwood.com/hc/en-gb/articles/115012366987-Understanding-SIP-Traces
5. The Anatomy of an INVITE Request | Tao, Zen, and Tomorrow - WordPress.com, 访问时间为 十二月 28, 2025， https://andrewjprokop.wordpress.com/2014/04/21/the-anatomy-of-an-invite-request/
6. RFC 7655: RTP Payload Format for G.711.0, 访问时间为 十二月 28, 2025， https://www.rfc-editor.org/rfc/rfc7655.html
7. RTP payload formats - Wikipedia, 访问时间为 十二月 28, 2025， https://en.wikipedia.org/wiki/RTP_payload_formats
8. Understanding the SIP Protocol - VoIPmonitor.org, 访问时间为 十二月 28, 2025， https://www.voipmonitor.org/doc/Understanding_the_SIP_Protocol
9. How to Negotiate OPUS Dynamic Codec IDs with sipp Scenarios - Sipfront, 访问时间为 十二月 28, 2025， https://sipfront.com/blog/2023/09/sipp-and-opus-negotiating-a-dynamic-codec-id/
10. rtpmap lines - webrtcHacks, 访问时间为 十二月 28, 2025， https://webrtchacks.com/wp-content/themes/parament/custom-pages/sdp/32.html
11. Voice Attributes - Dialogic, 访问时间为 十二月 28, 2025， https://www.dialogic.com/webhelp/csp1010/8.4.1_ipn3/vdac_chap_-_voice_attributes.htm
12. Codec Information and Bandwidth Calculations, 访问时间为 十二月 28, 2025， https://kb.clearlyip.com/XCast/Codec-Information-and-Bandwidth-Calculations.html
13. Calculating VoIP Bandwidth - Global Knowledge, 访问时间为 十二月 28, 2025， https://www.globalknowledge.com/us-en/resources/resource-library/articles/calculating-voip-bandwidth/
14. RTP Payload Format for G.711.0 - Tech-invite, 访问时间为 十二月 28, 2025， https://www.tech-invite.com/y75/tinv-ietf-rfc-7655-2.html
15. RTP Payload Format for G.711.0, 访问时间为 十二月 28, 2025， https://www.potaroo.net/ietf/all-ids/draft-ietf-payload-g7110-01.html
16. What is the basic structure of an RTP message? - Tencent Cloud, 访问时间为 十二月 28, 2025， https://www.tencentcloud.com/techpedia/102515
17. Real-time Transport Protocol - Wikipedia, 访问时间为 十二月 28, 2025， https://en.wikipedia.org/wiki/Real-time_Transport_Protocol
18. Header Format of RTP A Made Easy Tutorial, 访问时间为 十二月 28, 2025， http://siptutorial.net/RTP/header.html
19. RFC 5391 - RTP Payload Format for ITU-T Recommendation G.711.1 - IETF Datatracker, 访问时间为 十二月 28, 2025， https://datatracker.ietf.org/doc/html/rfc5391
20. [MS-RTPME]: RTP Packets - Microsoft Learn, 访问时间为 十二月 28, 2025， https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-rtpme/6689841c-82c3-422b-bbc0-7af4e023580c
21. One Way Audio - Continues Marker bit - Google Groups, 访问时间为 十二月 28, 2025， https://groups.google.com/g/rtpengine/c/_aWesG6Yz_U
22. RFC 3952 - Real-time Transport Protocol (RTP) Payload Format for internet Low Bit Rate Codec (iLBC) Speech - IETF Datatracker, 访问时间为 十二月 28, 2025， https://datatracker.ietf.org/doc/html/rfc3952
23. Codec Bandwidth Calculation G711/G729 - voiceonbits.com, 访问时间为 十二月 28, 2025， https://voiceonbits.com/2010/08/15/codec-bandwidth-calculation-g711g729/
24. Ethernet frame - Wikipedia, 访问时间为 十二月 28, 2025， https://en.wikipedia.org/wiki/Ethernet_frame
25. Concept of IFG (Interframe Gap) in Ethernet communication ~ Reasons why IFG is necessary ~ - Semiconductor business -Macnica, 访问时间为 十二月 28, 2025， https://www.macnica.co.jp/en/business/semiconductor/articles/microchip/135075/
26. VoIP Bandwidth Requirements: How Much Do I Need? - Vonage, 访问时间为 十二月 28, 2025， https://www.vonage.com/resources/articles/voip-bandwidth/
27. Business VoIP Phones: Guide to Power over Ethernet and Port Speeds - OnSIP, 访问时间为 十二月 28, 2025， https://www.onsip.com/voip-resources/voip-fundamentals/business-voip-phones-guide-to-power-over-ethernet-and-port-speeds
28. RFC 5391: RTP Payload Format for ITU-T Recommendation G.711.1, 访问时间为 十二月 28, 2025， https://www.rfc-editor.org/rfc/rfc5391.html