app网站建站系统下载厦门网站建设高级课程

app网站建站系统下载,厦门网站建设高级课程,宣传 网站建设和政务公开,福田网站制作报价SIP协议中SDP媒体协商机制的深度剖析与全景研究报告 1. 绪论#xff1a;SIP与SDP的架构共生关系 在现代IP通信#xff08;VoIP#xff09;和统一通信#xff08;UC#xff09;架构中#xff0c;会话发起协议#xff08;Session Initiation Protocol, SIP#xff09;作…SIP协议中SDP媒体协商机制的深度剖析与全景研究报告1. 绪论SIP与SDP的架构共生关系在现代IP通信VoIP和统一通信UC架构中会话发起协议Session Initiation Protocol, SIP作为控制平面的核心信令协议承担着会话的建立、修改和终止功能。然而SIP协议本身在设计上保持了高度的“媒体无关性”即它并不直接定义媒体流的编码格式、传输地址或带宽参数。这一职责被完全剥离并委托给了会话描述协议Session Description Protocol, SDP。SIP与SDP的结合通过RFC 3264定义的“提议/应答模型”Offer/Answer Model构成了现代通信网络的基石。本报告旨在提供一份详尽的、专家级的技术分析深入探讨SIP协议中SDP媒体协商的所有细节。我们将不仅局限于协议语法的解析更将深入到协议交互的深层逻辑、状态机转换、以及在复杂网络环境下的互操作性挑战。报告将涵盖从基础的编解码协商到高级的NAT穿越ICE、媒体安全性DTLS-SRTP、多路复用BUNDLE/RTCP-Mux以及联播Simulcast等前沿技术。1.1 信令与媒体的分离原则SIP与SDP的分离设计体现了分层架构的精髓。SIP负责“谁在与谁通信”以及“通信的上下文是什么”如Dialog ID, Call-ID而SDP负责“通信的内容是什么”以及“如何传输这些内容”。这种分离使得SIP可以灵活地支持语音、视频、即时消息MSRP、屏幕共享甚至游戏会话而无需修改信令协议本身。然而这也引入了复杂性信令路径Signaling Path与媒体路径Media Path往往不同步且通过SDP描述的媒体参数必须在两个异构的端点User Agents, UAs之间达成精确的一致任何参数的误解都可能导致单通、媒体质量下降或会话建立失败。2. 提议/应答模型Offer/Answer Model的理论基础与运作机制RFC 3264 定义的提议/应答模型是SIP使用SDP进行协商的操作指南。它规定了两个实体如何通过交换SDP消息来达成对多媒体会话的共同视图。2.1 核心状态机与原子性原则提议/应答交换是一个原子操作。一个完整的交换周期包括一个“提议”Offer和一个“应答”Answer。提议Offer发起方Offerer生成一个SDP列出它希望使用的媒体流类型音频、视频等、每种媒体流支持的编解码器列表按优先级排序、以及它准备接收媒体的IP地址和端口。应答Answer接收方Answerer收到提议后必须生成一个SDP应答。应答必须对提议中的每一个媒体流m行做出响应。如果接收方接受某个流它会填写自己的接收端口和选定的编解码器如果拒绝它必须将该流的端口设置为0。深层洞察这种原子性意味着如果应答由于某种原因如信令超时或SDP语法错误未能成功送达或被处理整个会话的状态必须回滚到提议之前的状态。这在SIP中通常表现为事务的失败如收到4xx/5xx响应此时User Agent Client (UAC) 必须假设会话参数未发生任何变更。2.2 单播会话中的非对称性与方向性在单播Unicast会话中提议/应答模型展现出显著的非对称性特征这是理解SIP媒体流向的关键。地址与端口的独立性提议中的 c 行和 m 行端口描述的是提议方希望接收媒体的地址和端口而不是发送地址。同理应答中的地址和端口是应答方希望接收媒体的地方。这意味着一个双向的音频通话实际上是由两个独立的单向RTP流组成的它们可以在网络层面上走完全不同的路由。编解码器选择的约束提议方列出的是能力集Capabilities而应答方进行的是选择集Selection。RFC 3264 规定应答中的每一个媒体流所列出的编解码器列表必须是提议中对应列表的子集。这意味着应答方有权决定最终使用的编码格式但这必须在提议方支持的范围内。2.3 上下文维护与版本控制SIP通过Dialog对话机制维护会话上下文而SDP内部则通过 oOrigin行中的版本号来维护媒体状态的上下文。Origin行格式ousername sess-id sess-version nettype addrtype unicast-address。版本控制机制sess-id 在整个会话生命周期内保持不变唯一标识该SDP会话对象。而 sess-version 是一个递增的整数。每当会话参数发生变更如Hold、增加视频、切换Codec发起方必须在新的提议中增加该版本号。一致性检查接收方UASUser Agent Server会检查接收到的SDP版本号。如果收到的版本号低于当前已知版本通常视为乱序包而忽略如果版本号不变但SDP内容变了则违反协议规范可能导致未定义的行为。3. SDP协议在SIP中的解剖学结构与语法细节SDPRFC 4566采用文本格式由一系列 typevalue 行组成。在SIP中SDP作为消息体Message Body承载Content-Type通常设为 application/sdp。3.1 会话级描述Session-Level Description会话级参数作用于整个多媒体会话或作为媒体级参数的默认值。字段描述与细节分析RFC参考v协议版本。目前必须为0。这是SDP解析器的第一个检查点非0版本将导致解析失败。6o所有者/创建者与会话标识。如前所述sess-version 的管理对于处理重协商Re-INVITE至关重要。若SIP信令中发生Glare冲突UAS通过比较版本号来决定处理逻辑。6s会话名称。RFC要求必须存在但在SIP VoIP呼叫中通常无实际意义常设为 s- 或 sSIP Call。5c连接信息。包含网络类型IN、地址类型IP4/IP6和连接地址。若在会话级定义则作为所有媒体流的默认接收地址。关键点在现代多宿主Multi-homed设备或支持ICE的场景中c 行地址往往只是一个fallback地址实际传输地址由ICE候选者决定。3t时间描述。格式 tstart-time stop-time。在SIP建立的实时会话中几乎总是设为 t0 0表示会话是持久的直到显式终止BYE。5a会话属性。如 agroup:BUNDLE 或 aice-ufrag 等全局性控制参数。33.2 媒体级描述Media-Level Description每个媒体流以 m 行开始后续跟随该流特有的属性。语法结构mmedia port proto fmt…media媒体类型常见为 audio, video, application (用于DTLS/SCTP通道或屏幕共享), message (用于MSRP)。port接收媒体的传输层端口。端口为0的特殊含义当一个应答中的 m 行端口被设为0时表示拒绝该媒体流。该流在后续的会话中被视为“禁用”但为了保持SDP结构的对齐该 m 行不能被删除只能被置为端口0。proto传输协议决定了媒体栈的行为。RTP/AVP: 经典的UDP传输RTP无加密。RTP/SAVP: 安全RTPSRTP通常配合SDES使用。UDP/TLS/RTP/SAVP: 用于WebRTC表示RTP封装在SRTP中SRTP封装在DTLS中DTLS封装在UDP中。fmt格式列表即Payload Types (PT)。这是一个整数列表对应于 artpmap 中的定义。静态PT如0 (PCMU), 8 (PCMA), 18 (G.729)。这些在RFC 3551中有唯一定义可以省略 artpmap但建议保留以防歧义 11。动态PT范围96-127。这些必须通过 artpmap 显式定义。例如Opus、H.264、VP8等现代编解码器均使用动态PT。3.3 属性行Attributes a的深度解析属性行极大地扩展了SDP的语义分为值属性Value Attribute, aattr:value和标志属性Property Attribute, aflag。artpmap将PT映射到编码名称、时钟频率和通道数。示例artpmap:111 opus/48000/2。注意对于Opus虽然时钟频率标为48000但在RTP时间戳计算时总是使用48kHz无论实际采样率如何 12。afmtp格式特定参数。这是SDP中最复杂的部分完全取决于Codec的定义。例如H.264的 profile-level-id 和 sprop-parameter-sets或Opus的 useinbandfec 12。方向属性asendrecv, asendonly, arecvonly, ainactive。机制这些属性控制媒体流向。在呼叫保持Call Hold场景中发起保持方发送 asendonly只发不收通常发静音或保持音乐被保持方响应 arecvonly 14。默认值如果未指定默认为 asendrecv。aptime打包时长Packetization Time单位毫秒。影响决定了每个RTP包承载多少毫秒的语音。常用值为20ms。如果设为10ms包头开销IP/UDP/RTP Headers会显著增加带宽占用如果设为60ms或更高会增加端到端延迟影响实时性。互操作性问题常发生于一端强行要求20ms而另一端只能发30ms的场景 15。4. SIP中提议/应答的交互模式与RFC 6337规范RFC 3264定义了SDP的协商逻辑但并未规定这些SDP应该放在哪个SIP消息中。RFC 6337 填补了这一空白定义了六种合法的交互模式旨在解决“Glare”冲突和状态不一致问题 16。4.1 六种标准交互模式模式提议载体 (Offer)应答载体 (Answer)典型应用场景与分析模式 1INVITE 请求2xx 响应 (如 200 OK)早期提议 (Early Offer)。最标准的呼叫流程。UAS在振铃前就能知道UAC的能力利于早期媒体的建立。模式 22xx 响应ACK 请求延迟提议 (Late Offer)。UAC在INVITE中不带SDP。通常用于3PCC场景网关需要先确认出局电路后再协商媒体。缺点是媒体建立延迟大可能导致开头语音丢失。模式 3INVITE 请求可靠的1xx 响应 (如 183)早期媒体 (Early Media)。结合RFC 3262 (100rel)允许在话路接通前建立双向媒体通道如彩铃、交互式语音应答IVR。模式 4可靠的1xx 响应PRACK 请求极其罕见。当INVITE无SDP延迟提议且UAS需要在接通前发送媒体时使用。UAS在183中发OfferUAC在PRACK中回Answer。模式 5PRACK 请求200 PRACK 响应在早期对话Early Dialog期间修改媒体参数如媒体流重定向。模式 6UPDATE 请求200 UPDATE 响应会话更新。可在对话建立前或建立后使用。常用于QoS预留确认或Session Timer刷新以及在不重新触发振铃的情况下修改媒体。4.2 早期提议 vs 延迟提议的深度对比早期提议 (Early Offer)优势呼叫建立速度快支持复杂的媒体流预协商。劣势UAC必须预留所有可能的资源即便最终协商失败。SBC行为会话边界控制器SBC通常倾向于将延迟提议转换为早期提议SBC在收到无SDP INVITE时向核心网侧发送带默认SDP的INVITE以保证核心网内部的统一性 17。延迟提议 (Delayed Offer)优势允许UAS如PSTN网关先确定物理电路再根据电路能力生成SDP。劣势媒体路径必须等到ACK发送后才能打通。若ACK丢失会导致单通或无声 18。4.3 冲突处理Glare Handling当通信双方几乎同时发起重协商请求如双方同时发送re-INVITE就会发生“Glare”。RFC 3261 规则如果UAC发送了INVITE但尚未收到最终响应此时收到对方的INVITE必须返回 491 Request Pending。退避算法收到491后双方根据Call-ID的大小生成不同范围的随机定时器0-2秒或2-4秒超时后重试。这确保了冲突最终能被解决 16。5. 编解码器协商的深层细节5.1 动态负载类型Dynamic Payload Types的协商陷阱RTP协议要求动态PT96-127必须显式定义。一个常见的误区是认为双方必须使用相同的动态PT数值。事实PT数值在RTP包头中仅具有本地意义Local Significance。场景UAC Offer: maudio… 97, artpmap:97 opus/48000。UAS Answer: maudio… 100, artpmap:100 opus/48000。结果UAC发给UAS的RTP包头PT为100UAS的接收意愿UAS发给UAC的RTP包头PT为97UAC的接收意愿。这是完全合法的。互操作性风险某些劣质的终端实现或老旧网关会强制要求PT数值对称导致媒体不通。5.2 H.264 视频协商的复杂性H.264的协商主要依赖 afmtp 中的参数其中最关键的是 profile-level-id 和 packetization-mode 13。profile-level-id 解析例如 42e01f。42 (十六进制) Baseline Profile。1f (十六进制) Level 3.1。协商逻辑双方必须协商出一个“最大公约数”。如果Offer是High ProfileAnswerer只支持BaselineAnswerer必须在Answer中降级为Baseline。如果Level不匹配通常协商为较低的Level。packetization-mode打包模式mode0 (Single NAL): 一个RTP包只能装一个NAL单元。效率低不支持高清因为高清帧通常大于MTU。mode1 (Non-interleaved): 允许FU-A分片。高清视频必须使用此模式。不对称风险如果UAC只支持Mode 1发高清而UAS只支持Mode 0老设备协商将失败视频无法建立。最佳实践是Offer中同时包含Mode 0和Mode 1的Payload Type条目例如PT 98对应Mode 1PT 99对应Mode 0 22。5.3 Opus 编解码器的高级特性Opus作为WebRTC的首选音频编码其SDP参数直接影响音质和带宽 12。useinbandfec1开启带内前向纠错。在丢包率高的网络下解码器可以利用包内的冗余信息恢复丢失的上一帧数据。这对于VoIP质量至关重要。dtx1开启不连续传输Discontinuous Transmission。在静音期停止发送RTP节省带宽但可能被某些VAD语音活动检测算法误判为断线。stereo1 vs sprop-stereo1区分“我能接收立体声”和“我实际发送的是立体声”。6. NAT穿越与ICE机制RFC 5245/8445在公网环境中NAT网络地址转换破坏了端到端的连接性。SIP/SDP引入了交互式连接建立Interactive Connectivity Establishment, ICE来解决此问题 24。6.1 候选者Candidates收集与SDP属性ICE通过在SDP中添加 acandidate 属性来交换所有可能的传输地址。Host Candidate:本地网卡IP。Srflx (Server Reflexive):通过STUN服务器获取的公网映射IP。Relay:通过TURN服务器获取的中继IP。SDP格式acandidate:foundation component protocol priority ip port typ type…component: 1代表RTP2代表RTCP。priority: 计算公式通常倾向于Host Srflx Relay以保证路径最短、成本最低 26。6.2 ICE 协商流程收集阶段UAC在发送INVITE前先向STUN/TURN服务器发起请求收集所有Candidate。交换阶段将Candidates封装在SDP Offer中发送。连通性检查Connectivity Checks双方收到对方SDP后形成候选者对Candidate Pairs。通过STUN Binding Request进行打洞测试。提名Nomination控制方通常是Offerer根据检查结果提名一对最优的Candidate Pair用于媒体传输。Trickle ICE传统的ICE需要收集完所有Candidate才发Offer导致起呼延迟可能长达数秒。Trickle ICE允许先发送包含Host Candidate的SDP后续通过INFO或UPDATE消息逐步推送新收集到的Srflx/Relay Candidates显著缩短首屏时间 27。7. 媒体安全性SDES 与 DTLS-SRTPSIP媒体加密主要由两种标准主导传统的SDES和现代的DTLS-SRTP。7.1 SDES (RFC 4568)SDESSecurity Descriptions通过SDP属性直接交换SRTP密钥。语法acrypto:tag crypto-suite key-params…示例acrypto:1 AES_CM_128_HMAC_SHA1_80 inline:PS1uQCVeeCFCanVmcjkpPywjNWhcYD0mXXtxaVBR安全隐患密钥以明文形式存在于SIP信令中。如果SIP信令未通过TLS加密或者中间的Proxy/SBC不可信媒体密钥就会泄露Hop-by-Hop安全性。尽管如此由于实现简单它在企业内网和老旧SIP Trunk中仍广泛使用 11。7.2 DTLS-SRTP (RFC 5764)DTLS-SRTP是WebRTC的强制标准通过媒体通道本身进行密钥协商实现了真正的端到端加密E2EE。机制SDP中不传输密钥只传输DTLS证书的指纹Fingerprint。SDP属性afingerprint:SHA-256 hash_value 和 asetup:actpass (Offer方) / active / passive (Answer方)。握手流程ICE打通后双方在UDP媒体通道上进行DTLS握手。SRTP的主密钥Master Key由DTLS握手导出SIP代理服务器无法获取该密钥因此无法窃听媒体 28。8. 传输层多路复用技术为了减少NAT端口映射的消耗Pinhole Exhaustion和简化ICE处理现代SIP广泛采用多路复用技术。8.1 RTCP-Mux (RFC 5761)传统RTP使用偶数端口RTCP使用RTP端口1。RTCP-Mux允许RTP和RTCP复用同一个端口。协商Offerer添加 artcp-mux。如果Answerer支持必须在应答中也包含该属性。效果每个媒体流节省一个端口。对于大规模并发网关这能节省50%的端口资源 31。8.2 BUNDLE (RFC 8843)BUNDLE扩展允许将音频、视频、数据通道全部绑定在同一个5元组IP/Port/Proto上传输。SDP语法会话级agroup:BUNDLE mid1 mid2…媒体级amid:id 标识每个流。协商逻辑Offerer建议BUNDLE。Answerer如果接受会将所有媒体流的端口设为相同即BUNDLE地址。区分流既然端口相同接收方如何区分音频和视频答案是依靠RTP包头中的SSRC同步源标识符或Payload Type。这对于WebRTC至关重要因为它极大减少了ICE连接检查的数量 33。9. 高级协商场景与状态控制9.1 呼叫保持Call Hold呼叫保持的标准做法RFC 3264是通过改变媒体流方向。保持操作发起方发送re-INVITE将媒体属性设为 asendonly。这隐含地告诉对方“请停止发送媒体给我但我可能会发给你如保持音乐”。响应操作接收方回 200 OKSDP中对应流设为 arecvonly。取回Retrieve发起方再次发re-INVITE设为 asendrecv。历史遗留问题早期RFC 2543使用 c0.0.0.0 来表示Hold。现代设备必须能兼容这种写法将其解释为Hold请求 14。9.2 DTMF 传输方式协商DTMF双音多频的传输有三种方式需要在SDP或配置中协调。In-band (带内音频):将按键音作为普通音频编码传输。缺点在有损压缩如G.729下会失真导致接收端检测失败。RFC 2833 / 4733 (RTP Event):业界标准。将按键事件编码为特殊的RTP包Payload Type通常为101。SDP协商afmtp:101 0-15。优点不受音频编码压缩影响抗丢包能力强通过冗余重发。SIP INFO:通过SIP信令发送DTMF。缺点可能会比RTP音频慢导致“声画不同步”且增加了信令服务器负担 37。9.3 联播Simulcast与RID在视频会议中发送端可能需要同时发送高清和标清两路流供MCU多点控制单元根据接收端能力转发。机制RFC 8853 定义了 asimulcast 属性。RID (Restriction Identifier):RFC 8851 定义了 arid用于在BUNDLE管道中精细区分和限制不同的RTP流如分辨率、帧率限制。示例asimulcast:send ridhi;ridlo配合 arid:hi send pt97;max-width1280 39。10. 常见互操作性问题与排查指南在多厂商设备混网中SIP/SDP互操作性问题频发。以下是典型案例与分析Codec 排序与锁定某些UAS会忽略Offer中的Codec顺序强行选择自己偏好的Codec。而某些UAC如果收到的Answer中第一个Codec不是它期望的可能会直接拆线。建议网关和SBC应具备Codec重新排序和转码Transcoding能力。PTIME 不匹配某些硬终端强制发送20ms包但SDP中未协商或者忽略对方 aptime:30 的请求。这会导致接收端Jitter Buffer溢出或下溢产生爆音。单通One-way Audio常见于NAT穿越失败。SDP中的 c 地址是内网IP且未部署ICE或SBC进行拓扑隐藏和地址修正。MTU 问题当SDP包含大量CandidateICE或大量Codec时SIP包大小可能超过以太网MTU1500字节导致UDP分片。如果网络中有防火墙拦截分片包INVITE就会丢失。建议启用SIP over TCP/TLS或使用Compact Header减小包大小。11. 结论SIP协议中的SDP媒体协商机制是一个精密复杂的体系。它不仅涉及基础的格式定义更通过提议/应答模型、ICE、DTLS-SRTP、BUNDLE等扩展协议解决了网络连通性、安全性和资源效率等核心问题。对于从事通信系统设计与运维的专业人员而言深入理解每一个属性背后的RFC规范及其在异常场景下的行为是构建高可用、高质量VoIP网络的关键。附录关键数据表与RFC映射表 1SIP SDP 关键RFC规范总览功能领域关键RFC作用描述基础模型RFC 3264定义 Offer/Answer 状态机与原子性规则基础语法RFC 4566定义 SDP 的文本格式与字段含义交互模式RFC 6337规范 SIP 中 Offer/Answer 的 6 种交互场景可靠性RFC 3262定义 PRACK 机制保障临时响应中的 SDP 传输NAT穿越RFC 8445定义 ICE 流程替代旧版 RFC 5245安全性RFC 4568定义 SDES (acrypto)基于信令交换密钥安全性RFC 5764定义 DTLS-SRTP基于媒体通道交换密钥多路复用RFC 5761定义 RTCP-Mux (artcp-mux)多路复用RFC 8843定义 BUNDLE (agroup:BUNDLE)表 2常见 SDP 属性与业务功能映射属性 (Attribute)关联业务功能典型配置值示例asendonly呼叫保持 (Hold)asendonly (MOH源端)aptime带宽与延迟优化aptime:20 (标准VoIP)afmtpDTMF 传输afmtp:101 0-15 (RFC 2833)afmtpH.264 模式协商packetization-mode1 (高清视频)afingerprintWebRTC 安全互通SHA-256 Hashamid流绑定与识别amid:audio-stream报告结束引用的著作RFC 3264: An Offer/Answer Model with Session Description Protocol (SDP), 访问时间为 十二月 28, 2025 https://www.rfc-editor.org/rfc/rfc3264.htmlInformation on RFC 3264 - » RFC Editor, 访问时间为 十二月 28, 2025 https://www.rfc-editor.org/info/rfc3264Session Description Protocol - Wikipedia, 访问时间为 十二月 28, 2025 https://en.wikipedia.org/wiki/Session_Description_ProtocolRFC 2327 - SDP: Session Description Protocol - IETF, 访问时间为 十二月 28, 2025 https://www.ietf.org/rfc/rfc2327.txtSIP - The Offer/Answer Model - Tutorials Point, 访问时间为 十二月 28, 2025 https://www.tutorialspoint.com/session_initiation_protocol/session_initiation_protocol_the_offer_answer_model.htmUnderstanding Session Description Protocol (SDP) | Tao, Zen, and Tomorrow, 访问时间为 十二月 28, 2025 https://andrewjprokop.wordpress.com/2013/09/30/understanding-session-description-protocol-sdp/A Session Description Protocol (SDP) Offer/Answer Mechanism to Enable File Transfer RFC 5547 - IETF Datatracker, 访问时间为 十二月 28, 2025 https://datatracker.ietf.org/doc/rfc5547/SDP Messages Tutorial - Session Description Protocol - GetStream.io, 访问时间为 十二月 28, 2025 https://getstream.io/resources/projects/webrtc/basics/sdp-messages/Example DTLS-SRTP Flows - Oracle Help Center, 访问时间为 十二月 28, 2025 https://docs.oracle.com/en/industries/communications/session-border-controller/9.3.0/configuration/example-dtls-srtp-flows.htmlRFC 8841: Session Description Protocol (SDP) Offer/Answer Procedures for Stream Control Transmission Protocol (SCTP) over Datagram Transport Layer Security (DTLS) Transport - » RFC Editor, 访问时间为 十二月 28, 2025 https://www.rfc-editor.org/rfc/rfc8841.htmlUnderstanding Media In SIP Session Description Protocol(SDP) - Teraquant, 访问时间为 十二月 28, 2025 https://teraquant.com/understand-media-sip-session-description-protocol/Opus negotiation for the practical man - Giacomo Vacca, 访问时间为 十二月 28, 2025 https://www.giacomovacca.com/2016/09/opus-negotiation-for-practical-man.htmlSIP Video Profile Bandwidth, Flow Control and Intraframe Request Use Cases Proposed Best Practices, 访问时间为 十二月 28, 2025 https://www.mplify.net/wp-content/uploads/2020/09/IMTC1015_22003_1.pdfModern Video-Conferencing Systems: Understanding Attributes of the Session Description Protocol | Webex Blog, 访问时间为 十二月 28, 2025 https://blog.webex.com/engineering/understanding-session-description-protocol-attributes/Toolpack:Profile SDP Description - TB Wiki, 访问时间为 十二月 28, 2025 https://docs.telcobridges.com/wiki/Toolpack:Profile_SDP_DescriptionRFC 6337: Session Initiation Protocol (SIP) Usage of the Offer …, 访问时间为 十二月 28, 2025 https://www.rfc-editor.org/rfc/rfc6337.htmlSDP Insertion for (Re)INVITEs - Oracle Help Center, 访问时间为 十二月 28, 2025 https://docs.oracle.com/cd/E95618_01/html/sbc_scz810_acliconfiguration/GUID-EF1DC771-C3A9-4BBF-932D-6AB068E6B635.htmSIP: 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-d686cedbb6caSIP Early Offer vs Delayed Offer - Knowledge Club Europe, 访问时间为 十二月 28, 2025 https://www.knowledgeclub.net/2022/08/sip-early-offer-vs-delayed-offer/Modern Video-Conferencing Systems: Understanding SDP Offer/Answer Negotiation, 访问时间为 十二月 28, 2025 https://blog.webex.com/engineering/understanding-sdp-offer-answer-negotiation/Modern Video-Conferencing Systems: Negotiating H.264 in SDP | Webex Blog, 访问时间为 十二月 28, 2025 https://blog.webex.com/engineering/modern-video-conferencing-systems-h264-sdp/H.264 Packetization Mode - Oracle Help Center, 访问时间为 十二月 28, 2025 https://docs.oracle.com/cd/E80921_01/html/esbc_ecz740_configuration/GUID-EAF152B8-EABC-48CF-A9CF-3F3B8830E688.htmHow to set up SDP for High quality Opus audio - Stack Overflow, 访问时间为 十二月 28, 2025 https://stackoverflow.com/questions/33649283/how-to-set-up-sdp-for-high-quality-opus-audioInteractive Connectivity Establishment - Wikipedia, 访问时间为 十二月 28, 2025 https://en.wikipedia.org/wiki/Interactive_Connectivity_EstablishmentInformation on RFC 5245 - » RFC Editor, 访问时间为 十二月 28, 2025 https://www.rfc-editor.org/info/rfc5245ICE: the ultimate way of beating NAT in SIP - openSIPS, 访问时间为 十二月 28, 2025 https://opensips.org/pub/events/2010-05-04_Amoocon_Rostock/ice-100604153615-phpapp02.pdfWebRTC General Basics | Background Information | Nabto Developer Docs, 访问时间为 十二月 28, 2025 https://www.nabto.com/docs/developer/webrtc/guides/webrtc-basics.htmlRFC 5764 - Datagram Transport Layer Security (DTLS) Extension to Establish Keys for the Secure Real-time Transport Protocol (SRTP) - IETF Datatracker, 访问时间为 十二月 28, 2025 https://datatracker.ietf.org/doc/html/rfc5764Understanding SDES vs DLTS-SRTP - Google Groups, 访问时间为 十二月 28, 2025 https://groups.google.com/g/discuss-webrtc/c/MP-1sCrOljASRTP using DTLS Protocol - AudioCodes, 访问时间为 十二月 28, 2025 https://techdocs.audiocodes.com/session-border-controller-sbc/mediant-800-sbc/user-manual/version-760/Content/UM/SRTP-using-DTLS-Protocol.htmdraft-ietf-avtcore-5761-update-06 - Session Description Protocol (SDP) Offer/Answer Clarifications for RTP/RTCP Multiplexing, 访问时间为 十二月 28, 2025 https://datatracker.ietf.org/doc/draft-ietf-avtcore-5761-update/06/RFC 5761: Multiplexing RTP Data and Control Packets on a Single Port, 访问时间为 十二月 28, 2025 https://www.rfc-editor.org/rfc/rfc5761.htmlInformation on RFC 8843 - » RFC Editor, 访问时间为 十二月 28, 2025 https://www.rfc-editor.org/info/rfc8843RFC 8843: Negotiating Media Multiplexing Using the Session Description Protocol (SDP), 访问时间为 十二月 28, 2025 https://www.rfc-editor.org/rfc/rfc8843.htmlSIP Hold – With RFC6337 - Nick vs Networking, 访问时间为 十二月 28, 2025 https://nickvsnetworking.com/sip-hold-with-rfc6337/SIP Call Hold Scenarios - Avaya Documentation, 访问时间为 十二月 28, 2025 https://documentation.avaya.com/bundle/AdministeringAvayaIPOfficePlatformManagerR11_1/page/Hold_Scenarios.htmlRFC 2833: DTMF Interworking - Oracle Help Center, 访问时间为 十二月 28, 2025 https://docs.oracle.com/en/industries/communications/session-border-controller/8.4.0/configuration/rfc-2833-dtmf-interworking.htmlHoping for some assistance understanding DTMF. : r/VOIP - Reddit, 访问时间为 十二月 28, 2025 https://www.reddit.com/r/VOIP/comments/2s6m1s/hoping_for_some_assistance_understanding_dtmf/Information on RFC 8853 - » RFC Editor, 访问时间为 十二月 28, 2025 https://www.rfc-editor.org/info/rfc8853RFC 8851: RTP Payload Format Restrictions, 访问时间为 十二月 28, 2025 https://www.rfc-editor.org/rfc/rfc8851.html