文山壮族苗族自治州网站建设_网站建设公司_移动端适配_seo优化

SIP协议中静态负载（Static Payload）协商机制深度研究报告

1. 引言

在现代IP语音（VoIP）和统一通信（Unified Communications）架构中，会话发起协议（Session Initiation Protocol, SIP）与会话描述协议（Session Description Protocol, SDP）共同构成了媒体协商的基石。尽管随着WebRTC和高清语音（HD Voice）技术的兴起，基于OPUS、EVS等现代编解码器的动态负载协商机制日益受到关注，但在全球电信基础设施的核心层，静态负载（Static Payload）类型依然扮演着不可替代的角色。静态负载类型，特别是IANA注册表中的0-95号段，定义了包括G.711（PCMU/PCMA）和G.729在内的基础通信标准。

本报告旨在对SIP协议环境下的静态负载协商机制进行详尽的、百科全书式的技术分析。报告将深入探讨RTP/AVP配置文件的历史演变与RFC标准定义，剖析RFC 3264“提议/应答”（Offer/Answer）模型在静态负载场景下的具体运作逻辑，并重点研究G.711与G.729等关键编解码器的协商细节及其在异构网络互通中产生的复杂性。此外，本研究还将涵盖DTMF（双音多频）信号的伪静态协商问题、WebRTC环境下的互操作性挑战，以及基于Wireshark等工具的故障诊断方法论。通过对RFC标准文档、厂商实施指南及现网案例的综合研判，本报告揭示了静态负载机制在保障传统电信业务稳定性与适应新兴网络架构之间存在的张力与平衡。

2. 理论基础：RTP配置文件与负载类型分类

要理解SIP中的静态负载协商，首先必须从媒体传输层——实时传输协议（RTP）入手。RTP协议本身并不在数据包头中包含关于媒体采样率、通道数或编码格式的显式描述文本，而是依赖一个7位的“负载类型”（Payload Type, PT）字段来标识当前数据包的格式。这个7位字段允许128个不同的值（0-127），其具体含义由RTP“配置文件”（Profile）定义。

2.1 RTP/AVP配置文件（RFC 3551）

在VoIP领域，最核心的配置文件是RFC 3551定义的“用于音频和视频会议的RTP配置文件”（RTP Profile for Audio and Video Conferences with Minimal Control，简称RTP/AVP）2。该标准取代了早期的RFC 1890，确立了静态负载与动态负载的二元分类体系。

根据RFC 3551的定义，负载类型被划分为两个主要区间：

1. 静态负载类型（Static Payload Types, PT 0-95）：这一范围内的数值由互联网号码分配局（IANA）永久分配给特定的音频或视频编码格式。当通信双方使用静态负载类型时，编码的具体参数（如时钟频率、通道数、打包时长等）是隐式确定的，接收端无需通过SDP获取额外描述即可正确解码。例如，Payload Type 0在任何符合RTP/AVP标准的设备上都被默认为PCMU（G.711m u \\mumu-law），采样率为8000Hz，单声道。
2. 动态负载类型（Dynamic Payload Types, PT 96-127）：这一范围保留给没有固定静态分配的编码格式使用。此时，Payload Type数值与具体编解码器之间的映射关系是临时的，必须在每一次会话中通过SDP进行显式定义。

2.2 IANA注册表的演变与现状

在RTP协议发展的早期，IANA注册表中0-34号段被快速分配给了当时主流的音视频编码，如G.723（PT 4）、GSM（PT 3）、H.261（PT 31）等。然而，随着编解码器技术的爆炸式增长，有限的7位空间（仅128个值）迅速显得捉襟见肘。因此，IETF后续采取了“关闭注册”的策略，不再为新的编解码器分配静态Payload Type，而是强制要求使用动态协商机制。

尽管如此，存量的静态负载类型定义构成了现代通信网络的基准。无论网络边缘如何演进，核心网关、PSTN互通点以及大量的传统SIP硬终端依然严重依赖这些静态定义。表1总结了当前网络中最常见的静态负载类型分配情况。

表 1：关键静态负载类型分配表（基于RFC 3551与IANA注册数据）4

这种分配机制隐含了一个深刻的技术哲学：对于最基础、最通用的能力（如G.711），协议追求“最小控制开销”（Minimal Control），即在没有任何信令交换的最坏情况下，接收端依然可能通过盲猜Payload Type 0或8来还原音频。这种鲁棒性设计是SIP/RTP体系能够取代传统电路交换网络的关键因素之一。

3. 协商机制详解：RFC 3264与SDP语义

SIP协议本身主要负责信令的路由与会话的建立，而媒体能力的具体协商则由封装在SIP消息体中的SDP协议完成。RFC 3264定义的“提议/应答”（Offer/Answer）模型详细规定了通信双方如何就静态负载达成一致。

3.1 静态负载在SDP中的表达语法

在SDP报文中，媒体行（m= line）是协商的核心。对于静态负载类型，m=行直接列出终端支持的Payload Type数值，顺序通常代表优先级。

典型SDP Offer示例：
v=0
o=UserA 2890844526 2890844526 IN IP4 192.168.1.1
c=IN IP4 192.168.1.1
m=audio 49170 RTP/AVP 18 0 8 101
在此示例中，发起方（Offerer）宣称其音频端口为49170，传输协议为RTP/AVP，并支持四种格式：G.729（18）、PCMU（0）、PCMA（8）以及动态的telephone-event（101）。

a=rtpmap属性的隐式与显式之争：
对于动态负载（96-127），RFC标准强制要求必须包含a=rtpmap属性来定义Payload Type与编码名称的映射（例如 a=rtpmap:101 telephone-event/8000）。然而，对于静态负载（0-95），a=rtpmap属性是可选的（Optional）9。
根据RFC 3551，接收到m=audio… 0的终端应当依据标准默认知道0对应PCMU/8000/1。然而，在实际部署中，这种“隐式定义”常常导致互操作性问题。部分严格的SIP网关（尤其是涉及H.323互通的Cisco CUBE或Oracle SBC）可能会拒绝不包含显式rtpmap的静态负载Offer，或者在未收到显式描述时采用错误的默认参数。因此，现代VoIP的最佳实践（Best Practices）强烈建议即使是静态负载，也应在SDP中完整包含a=rtpmap描述，以消除歧义并提高系统的兼容性。

3.2 提议/应答模型的匹配规则

RFC 3264为静态负载的协商制定了严格的逻辑规则，这些规则确保了会话双方能够收敛到一个共同的媒体格式集：

1. 子集选择原则（Subset Selection）：应答方（Answerer）在构建SDP Answer时，其m=行中列出的Payload Type列表必须是Offer中列表的一个子集。Answerer不能凭空添加Offer中未出现的静态负载类型。如果Offer只包含G.711（0, 8），Answerer即使支持G.729（18），也不能在Answer中加入18，否则会导致协商失败或单通。
2. 对称性原则（Symmetry）：对于静态负载类型，Payload Type数值具有全局唯一性。如果Offer中使用PT 0表示PCMU，Answerer若接受该格式，也必须使用PT 0来表示PCMU。这与动态负载不同，在动态负载中，虽然不推荐，但理论上允许双方使用不同的Payload Type数值映射同一编解码器（例如一方用96表示Opus，另一方用97表示Opus）。静态负载的这种强对称性简化了DSP（数字信号处理）资源的分配，但在遇到非标准实现时缺乏灵活性。
3. 拒绝机制：如果Answerer不支持Offer中的任何一个静态负载类型，它必须拒绝该媒体流（通常通过将端口置为0），或者发送488 Not Acceptable Here响应，触发Offerer重新发起协商。

4. 核心静态编解码器的协商深度解析

虽然IANA分配了数十个静态类型，但在现网流量中，PCMU（0）、PCMA（8）和G.729（18）占据了绝对主导地位。对这三种编解码器协商机制的深入理解，是掌握SIP静态负载协商的关键。

4.1 G.711 (PCMU/PCMA) - Payload Type 0 与 8

G.711是电信级语音质量（Toll Quality）的基准，采用64kbps的脉冲编码调制（PCM）。它分为m u \\mumu-law（主要用于北美和日本）和A-law（主要用于欧洲和世界其他地区）两种压缩算法。

• 静态绑定的绝对性：在SIP协商中，PT 0 永远代表PCMU，PT 8 永远代表PCMA。这种绑定关系是如此稳固，以至于许多基于硬件的DSP芯片直接通过检查RTP包头的PT字段是否为0或8来切换解码算法，完全忽略SDP中的其他参数。
• Packetization Time (ptime) 的影响：虽然编码格式是静态的，但打包时长（ptime）是可协商的。G.711默认通常为20ms（即每个RTP包包含160字节载荷）。如果SDP中a=ptime:30被提议，双方需调整打包策略。静态负载协商的简单性有时会掩盖ptime不匹配带来的问题，导致语音断续或延迟增加。
• WebRTC环境下的挑战：尽管WebRTC标准（RFC 8866等）要求强制支持G.711以保证互通性，但Chrome等浏览器的WebRTC协议栈在处理“低数值”Payload Type时曾存在历史缺陷。由于浏览器更倾向于使用96-127的动态范围，早期的WebRTC实现有时会尝试将G.711映射到动态Payload Type（如110），这严重破坏了与传统SIP设备的互通性，因为传统设备通常只认PT 0/8。

4.2 G.729 - Payload Type 18 与 Annex B 的复杂性

G.729（8kbps）是带宽受限环境下的首选编解码器。虽然它被分配了静态Payload Type 18，但其协商过程比G.711复杂得多，主要归因于“附件B”（Annex B）的存在。

4.2.1 Annex B 参数的语义

G.729标准包含多个附件，其中Annex A（G.729a）是简化算法版，与标准G.729兼容；而Annex B定义了静音压缩（VAD/CNG）机制。在SDP中，G.729的协商通过fmtp属性中的annexb参数进行细粒度控制 17：

• a=fmtp:18 annexb=yes：表示支持或启用VAD（静音检测）。
• a=fmtp:18 annexb=no：表示禁用VAD，要求全速率持续传输。
• 隐式默认值：如果SDP中未包含annexb参数，RFC 4856规定默认隐含annexb=yes。

4.2.2 协商不对称与单通故障

G.729 Annex B的协商是SIP互通中最著名的陷阱之一。RFC 7261详细描述了这种不对称场景：

• 场景分析：假设Offerer发送G.729（隐含annexb=yes），而Answerer虽然支持G.729但不支持VAD，因此回复annexb=no。
• 理想行为：根据RFC 3264和7261，双方应降级协商结果，即整个会话应以annexb=no（关闭VAD）运行。
• 实际故障：许多老旧的SIP实现将Payload Type 18视为一个原子能力，忽略了fmtp参数的协商逻辑。Offerer可能忽略Answer中的annexb=no，继续在静音时停止发送RTP包（启用VAD）。而Answerer（期待持续流）在检测到RTP流中断时，可能误判为网络故障或挂断，导致通话中断或单向音频（One-way Audio）18。

这一现象揭示了静态负载协商的一个深层矛盾：Payload Type的静态性掩盖了编解码器行为的动态可配置性。虽然“18”这个数字是静态的，但其背后的行为（是否开启VAD）却是通过SDP动态协商的，这种混合机制大幅增加了实现的复杂度。

4.3 静态类型的动态重载（Dynamic Overloading）

在极少数特殊场景下，工程师可能会在SDP中看到将静态Payload Type映射到动态范围的操作。例如：
m=audio… 96
a=rtpmap:96 PCMU/8000
这种做法通常是为了规避某些硬件对PT 0的硬编码行为，或者是为了在同一会话中同时支持不同参数配置的同一种编码（例如一个流用PT 0表示20ms打包的PCMU，另一个流用PT 96表示30ms打包的PCMU）。虽然RFC 3551允许这种“重载”（Overriding），但在实际互通中极易导致混乱，因为许多只遵循“最小控制”原则的接收端会直接忽略96的定义，或者无法理解为何标准PCMU没有出现在PT 0上。

5. 伪静态的动态负载：DTMF (RFC 2833/4733)

在SIP通信中，除了语音流，带内信令（如按键音）的传输同样关键。DTMF（Dual-Tone Multi-Frequency）的传输标准经历了从RFC 2833到RFC 4733的演进。严格来说，DTMF属于“命名电话事件”（Named Telephone Events），并不属于音频波形编码，因此它必须使用动态Payload Type。

5.1 动态中的“事实标准”

由于DTMF事件（Event）本质上不是连续的音频采样，无法复用静态的音频Payload Type。RFC标准要求DTMF使用动态范围（96-127）。
然而，为了减少协商的不确定性，业界形成了一个强大的事实标准（De Facto Standard）：Payload Type 101。
在绝大多数SIP抓包中，我们都能看到如下配置：
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
尽管101是动态范围的数值，但它在实际工程中几乎被视为“准静态”负载类型。

5.2 96、97与101的互操作性灾难

尽管101是主流，但并非所有厂商都遵循这一默契。

• Cisco IOS行为：早期Cisco网关和CUBE经常默认使用PT 101，但在某些版本或与其他H.323设备互通时，可能会回退到PT 96或97。
• 华为/中兴设备：在某些软交换局点配置中，华为设备可能默认使用PT 97。
• 协商死锁：依据RFC 3264，如果Offerer提议101，Answerer应该接受101，或者在Answer中指定自己期望的接收PT（例如97）。RFC允许收发方向使用不同的PT（非对称）。然而，许多中间件（如IVR服务器、转码器）的DSP资源是按对称流设计的，如果Alice发101，Bob发96，可能会导致DTMF检测失败，表现为用户无法通过IVR菜单。

故障排查案例：在Wireshark中，经常观察到RTP流中混合了Payload Type 18（语音）和Payload Type 101（DTMF）。如果SDP协商结果显示一方期望97而另一方发送101，这便是典型的DTMF协商失败。解决此类问题通常需要在SBC（会话边界控制器）上进行强制的Payload Type重写（Rewrite）或规范化。

6. 高级SIP场景下的静态负载交互

静态负载的协商并非孤立发生，它深受SIP呼叫流程模式的影响。

6.1 早期提议（Early Offer）与延迟提议（Delayed Offer）

• 早期提议 (Early Offer)：呼叫方在初始INVITE消息中即携带SDP。这是推荐模式，因为它允许被叫方在振铃前就明确知道是否支持主叫的静态负载（如G.711），从而避免“媒体剪切”（Clipping，即通话开始头几秒无声）26。
• 延迟提议 (Delayed Offer)：初始INVITE不带SDP。被叫方必须先接听（发送200 OK），并在200 OK中携带自己的SDP Offer。主叫方在ACK中携带SDP Answer。
  • 静态负载的风险：在延迟提议模式下，如果被叫方（此时充当Offerer）在200 OK中只提供了G.729（PT 18），而主叫方只支持G.711（PT 0），此时信令上呼叫已经建立（200 OK已发），但媒体协商却注定失败。这会导致呼叫立即掉线或进入静默状态。因此，依赖静态负载的传统设备在延迟提议模式下极其脆弱。

6.2 媒体重协商与Glare

在通话过程中，可能会发生媒体参数的变更（例如从音频升级到视频，或传真业务切入）。

• Glare现象：当双方几乎同时发起Re-INVITE以修改媒体参数时，会发生Glare。RFC 3264规定IP地址较小的一方回退。
• 静态负载的持久性：在重协商过程中，静态负载类型的映射关系通常保持不变。但是，如果一个动态Payload Type（如96）在初始呼叫中被映射为iLBC，在重协商中绝对禁止将其重新映射为Opus。必须为新编码分配一个新的动态数值（如97）。这种规则防止了飞行中（in-flight）的RTP包被错误解码。

7. WebRTC与现代互操作性

WebRTC的引入对基于静态负载的SIP生态造成了冲击。

7.1 动态范围耗尽与静态区间的冲突

Chrome浏览器内置了Opus, G.711, G.722, iSAC, VP8, VP9, H.264, AV1等大量编解码器，加上RTX（重传）、FEC（前向纠错）等机制，所需的Payload Type数量极易超过动态范围（96-127）所能提供的32个空槽位。

• 溢出效应：当动态范围耗尽时，WebRTC引擎可能会尝试使用IANA未分配的静态范围（35-95）作为动态负载使用。
• 互通性断裂：传统的SIP网关通常硬编码了0-95为“保留”或“静态”区域。当它收到一个PT=35的RTP包时，可能会因为查不到静态定义而直接丢弃，即使SDP中对其进行了正确的rtpmap定义。这迫使SBC在WebRTC网关处必须进行复杂的Payload Type映射和过滤。

7.2 G.711的WebRTC转码困境

虽然WebRTC支持G.711，但其首选Opus（动态PT 111）。当WebRTC终端呼叫传统SIP终端（仅支持PT 0）时，SBC必须进行转码或透传。

• 如果SBC决定透传，必须确保SDP Offer中包含PT。
• 如果SBC决定转码（Opus <-> G.711），则SBC面向SIP侧必须严格伪装成PT 0的发送者。任何试图将G.711映射到动态PT的行为都可能导致传统话机无声。

8. 厂商实施差异与故障排查

不同厂商对RFC标准的理解差异是静态负载协商问题的根源。

8.1 厂商行为分析

• Cisco CUBE:Cisco设备在处理rtp-nte（DTMF）时，经常出现SDP协商了PT 101，但实际RTP流中发送PT 96的Bug（如CSCte81777）。此外，Cisco支持“非对称负载”（Asymmetric Payload）配置，允许收发使用不同PT，这虽然符合RFC，但常令不支持此特性的对端设备崩溃。
• Asterisk:Asterisk作为著名的开源PBX，其PJSIP协议栈对静态负载的支持较为灵活，能够通过配置文件强制指定允许的Codecs。但在处理G.729 Annex B时，Asterisk曾存在无法正确解析annexb=no导致转码失败的问题。

8.2 Wireshark取证分析方法

使用Wireshark进行故障定位是解决静态负载问题的终极手段。

1. 过滤器技巧：
   • 过滤SDP协商：sip.sdp.media.format 或直接搜索 sip contains “m=audio”。
   • 过滤特定负载类型的RTP包：rtp.p_type == 0 （查找PCMU包）或 rtp.p_type == 101 （查找DTMF包）34。
2. RTP流分析（RTP Stream Analysis）：
   • Wireshark能够自动关联SIP信令与RTP流。如果信令中协商了G.711（PT 0），Wireshark会自动用G.711解码器播放音频。
   • Payload Mismatch检测：如果Wireshark显示RTP流的PT为18，但播放出来的声音是巨大的白噪声，这通常意味着Wireshark（或接收端）错误地用G.711（PT 0）的算法去解码了G.729的数据。这表明SIP信令与实际RTP流不一致。
3. SSRC与序列号分析：
   • 当Payload Type在通话中发生切换（例如从PT 0切换到PT 101发送DTMF，再切回PT 0），RTP序列号（Sequence Number）应保持连续递增。如果观察到Payload Type切换的同时序列号发生跳变或SSRC改变，这通常意味着DSP复位或发生了错误的流切换，会导致明显的音频卡顿。

9. 结论

SIP协议中的静态负载协商机制是一个在历史包袱与现代需求之间寻求平衡的技术产物。虽然IETF已经明确转向全动态协商的未来，但PCMU（0）、PCMA（8）和G.729（18）作为电信基础设施的“通用语”，将在未来数十年内继续存在。

本报告的研究表明，静态负载的“静态”是相对的。在G.729 Annex B的参数协商、DTMF的101事实标准、以及WebRTC对Payload Type范围的挤压中，静态负载展现出了复杂的动态特征。对于网络架构师和VoIP工程师而言，单纯依赖“PT 0等于PCMU”的简单认知已不足以应对复杂的现网环境。必须深入理解RFC 3264的匹配规则、显式rtpmap的重要性以及厂商实现的细微差异，才能构建出真正健壮的互操作网络。

在向EVS、AV1等下一代编解码器演进的过程中，静态负载将逐渐退化为兼容性回退方案，但其设计哲学——即在最小信令开销下保证基本通信能力的理念，仍将对未来的协议设计产生深远影响。

参考文献索引：
本报告引用的数据与技术细节基于以下RFC标准与研究片段：

1

引用的著作

1. Payload Types and Formats - GNU ccRTP Manual, 访问时间为 十二月 28, 2025， https://www.gnu.org/software/ccrtp/doc/manual/html/Payload-Types-and-Formats.html
2. RTP payload formats - Wikipedia, 访问时间为 十二月 28, 2025， https://en.wikipedia.org/wiki/RTP_payload_formats
3. RFC 3551 - RTP Profile for Audio and Video Conferences with Minimal Control - IETF Datatracker, 访问时间为 十二月 28, 2025， https://datatracker.ietf.org/doc/html/rfc3551
4. Real-Time Transport Protocol (RTP) Parameters - Internet Assigned Numbers Authority, 访问时间为 十二月 28, 2025， https://www.iana.org/assignments/rtp-parameters
5. Dynamic Payloads | FreeSWITCH Documentation, 访问时间为 十二月 28, 2025， https://developer.signalwire.com/freeswitch/FreeSWITCH-Explained/Codecs-and-Media/Dynamic-Payloads_3375552/
6. rtp-parameters.txt - Internet Assigned Numbers Authority, 访问时间为 十二月 28, 2025， https://www.iana.org/assignments/rtp-parameters/rtp-parameters.txt
7. RFC 3264 – An Offer/Answer Model with the Session Description Protocol (SDP) - IETF, 访问时间为 十二月 28, 2025， https://www.ietf.org/rfc/rfc3264.txt
8. RFC 3264 - An Offer/Answer Model with Session Description Protocol (SDP), 访问时间为 十二月 28, 2025， https://datatracker.ietf.org/doc/html/rfc3264
9. RFC 4566 - SDP: Session Description Protocol - IETF Datatracker, 访问时间为 十二月 28, 2025， https://datatracker.ietf.org/doc/html/rfc4566
10. Modern Video-Conferencing Systems: Understanding Attributes of the Session Description Protocol | Webex Blog, 访问时间为 十二月 28, 2025， https://blog.webex.com/engineering/understanding-session-description-protocol-attributes/
11. Understanding Media in SIP Session Description Protocol (SDP) – Original - Teraquant, 访问时间为 十二月 28, 2025， https://teraquant.com/understand-media-sip-session-description-protocol-original/
12. Payload Types for Standard Audio and Visual Encodings - Oracle Help Center, 访问时间为 十二月 28, 2025， https://docs.oracle.com/cd/E80921_01/html/esbc_ecz740_configuration/GUID-F48DF31A-53F6-4C05-BE42-ED4C48B63B2B.htm
13. SIP - The Offer/Answer Model - Tutorials Point, 访问时间为 十二月 28, 2025， https://www.tutorialspoint.com/session_initiation_protocol/session_initiation_protocol_the_offer_answer_model.htm
14. [Sip-implementors] overloading static RTP payload types with dynamic payload types, 访问时间为 十二月 28, 2025， https://lists.cs.columbia.edu/pipermail/sip-implementors/2009-August/023409.html
15. Session Description Protocol (SDP) Negotiation With Examples - Teraquant, 访问时间为 十二月 28, 2025， https://teraquant.com/session-description-protocol-negotiation-examples/
16. PSA: usage of rtp payload types in the range 35-65 in webrtc.org/chrome - Google Groups, 访问时间为 十二月 28, 2025， https://groups.google.com/g/discuss-webrtc/c/w1SY3bozdvs/m/jX5KhuF4AwAJ
17. G.729 - Wikipedia, 访问时间为 十二月 28, 2025， https://en.wikipedia.org/wiki/G.729
18. draft-ietf-mmusic-sdp-g273-g729-00, 访问时间为 十二月 28, 2025， https://datatracker.ietf.org/doc/html/draft-ietf-mmusic-sdp-g273-g729
19. RFC 7261: Offer/Answer Considerations for G723 Annex A and G729 Annex B - » RFC Editor, 访问时间为 十二月 28, 2025， https://www.rfc-editor.org/rfc/rfc7261.html
20. Avaya Knowledge - CM: RTP payload changes from G.711/G.729 to DynamicRTP-Type-125 mid stream, 访问时间为 十二月 28, 2025， https://support.avaya.com/kb/public/SOLN312417&group=UG_PUBLIC
21. RFC 7655: RTP Payload Format for G.711.0, 访问时间为 十二月 28, 2025， https://www.rfc-editor.org/rfc/rfc7655.html
22. CSCte81777 - CUBE SIP rtp-nte payload does not match what is negotiated in SDP - Cisco Bug, 访问时间为 十二月 28, 2025， https://bst.cisco.com/quickview/bug/CSCte81777
23. RTP-NTE Payload Type - Cisco Community, 访问时间为 十二月 28, 2025， https://community.cisco.com/t5/ip-telephony-and-phones/rtp-nte-payload-type/td-p/2727364
24. Hoping for some assistance understanding DTMF. : r/VOIP - Reddit, 访问时间为 十二月 28, 2025， https://www.reddit.com/r/VOIP/comments/2s6m1s/hoping_for_some_assistance_understanding_dtmf/
25. Dynamic Payload Type Interworking For DTMF and Codec Packets For SIP-to-SIP Calls, 访问时间为 十二月 28, 2025， https://www.scribd.com/document/464099710/Dynamic-Payload-Type-Interworking-for-DTMF-and-Codec-Packets-for-SIP-to-SIP-Calls
26. Difference between Early Offer and Late Offer. - Cisco Learning Network, 访问时间为 十二月 28, 2025， https://learningnetwork.cisco.com/s/question/0D53i00000XTzqHCAT/difference-between-early-offer-and-late-offer
27. SIP Early Offer vs Delayed Offer - Knowledge Club Europe, 访问时间为 十二月 28, 2025， https://www.knowledgeclub.net/2022/08/sip-early-offer-vs-delayed-offer/
28. SIP: Understanding Early Offer, Delayed Offer, and Early Media | by Krishnakumar PG, 访问时间为 十二月 28, 2025， https://pgkrishna.medium.com/sip-understanding-early-offer-delayed-offer-and-early-media-d686cedbb6ca
29. Early Offer versus Delayed Offer SIP Invites : - 46 Labs, 访问时间为 十二月 28, 2025， https://support.46labs.com/support/solutions/articles/156000368953-early-offer-versus-delayed-offer-sip-invites
30. the range of dynamic rtp payload types is exhausted [42222327[ - WebRTC, 访问时间为 十二月 28, 2025， https://bugs.webrtc.org/12194
31. WebRTC Codecs - What’s supported? - GetStream.io, 访问时间为 十二月 28, 2025， https://getstream.io/resources/projects/webrtc/advanced/codecs/
32. The Vagaries of DTMF Payload Negotiation - Asterisk, 访问时间为 十二月 28, 2025， https://www.asterisk.org/the-vagaries-of-dtmf-payload-negotiation/
33. Help Debugging RFC4733 DTMF - Asterisk Community, 访问时间为 十二月 28, 2025， https://community.asterisk.org/t/help-debugging-rfc4733-dtmf/74602
34. How to Analyze SIP Calls in Wireshark - Yeastar Support, 访问时间为 十二月 28, 2025， https://support.yeastar.com/hc/en-us/articles/360007606533-How-to-Analyze-SIP-Calls-in-Wireshark
35. SIP Troubleshooting using Wireshark - Upspir, 访问时间为 十二月 28, 2025， https://upspir.com/sip-troubleshooting-using-wireshark/
36. Does Wireshark check the RTP payload type when extracting audio, 访问时间为 十二月 28, 2025， https://osqa-ask.wireshark.org/questions/3578/does-wireshark-check-the-rtp-payload-type-when-extracting-audio/
37. HOWTO:: Call Quality Troubleshooting - Bicom Systems, 访问时间为 十二月 28, 2025， https://support.bicomsystems.com/support/solutions/articles/67000731742-howto-call-quality-troubleshooting
38. Information on RFC 3551 » RFC Editor, 访问时间为 十二月 28, 2025， https://www.rfc-editor.org/info/rfc3551
39. 9.2. Playing VoIP Calls - Wireshark, 访问时间为 十二月 28, 2025， https://www.wireshark.org/docs/wsug_html_chunked/ChTelPlayingCalls.html