SDP Offer/Answer 模型与 DTMF rtpmap/fmtp 不匹配
SDP Offer/Answer model with DTMF rtpmap/fmtp mismatch
想象一个报价 SDP，它有一行“m”，其中包含标记为 sendrecv 的 DMTF 的编解码器 8 和 101：
m = audio 35904 RTP/AVP 8 101
a = rtpmap:8 PCMA/8000
a = rtpmap:101 telephone-event/8000
a = fmtp:101 0-15
a = sendrecv
得到一个答案 SDP 的回答，其中一行“m”包含编解码器 8，但 DTMF 为 120，并且类似地标记为 sendrecv:
m = audio 1235 RTP/AVP 8 120
a = rtpmap:8 PCMA/8000
a = rtpmap:120 telephone-event/8000
a = fmtp:101 0-15
a = sendrecv
来自 RFC 3264:
For streams marked as sendrecv in the answer, the "m=" line MUST
contain at least one codec the answerer is willing to both send and
receive, from amongst those listed in the offer. The stream MAY
indicate additional media formats, not listed in the corresponding
stream in the offer, that the answerer is willing to send or
receive (of course, it will not be able to send them at this time,
since it was not listed in the offer).
RFC3264 以上部分，证明在应答 SDP 中发送不同的 DTMF fmtp(120 到 101) 符合 RFC3264，因为编解码器 8(G711a) 与报价 SDP 匹配。
DTMF 信令是否正常或是否可能存在 DTMF 问题？
感谢任何反馈。
总的来说：
RTP 负载类型编号 0-95 标识静态媒体编码。例如。有效负载类型 8 表示时钟频率为 8000 Hz (RFC3551). As such, this description doesn't have to (but should) be included in the media format description of the SDP offer/answer, using the "a=rtpmap:" and "a=fmtp:" attributes (RFC4566) 的 PCMA 音频。
有效负载类型编号 96-127 是动态的。这些可用于协商未包含在静态列表中的编码。使用这些数字之一时，媒体格式描述中必须包含编码规范以指定确切的编码参数。
协商双方可以选择自己的动态负载类型编号来表示相同的媒体编码，这不一定是相同的编号。当一方已经将特定的动态有效载荷类型编号分配给另一种编码时，这可能很有用。在您的示例中，一方在 m-line 中使用 101，另一方使用 120，但这些数字表示相同的媒体编码（请参阅“a=rtpmap:”行）。每一方都告诉对方“当您使用编码 X 发送 RTP 时，您必须在 RTP 数据包中包含有效负载类型编号 Y headers。
负载类型编号包含在RTP数据包的PT字段中headers (RFC 3550)
在这种情况下:
答案中的“a=fmtp:”属性将 101 指定为负载类型编号而不是 120。这意味着它不适用于 telephone-events 负载并且没有关于哪个 DTMF 的可用信息支持事件 (RFC 4733)。我认为这是一个实现错误，fmtp 属性旨在应用于 telephone-events 有效负载。
这表明您应该期待 DTMF 问题。但它也可以正常工作。试一试...
想象一个报价 SDP，它有一行“m”，其中包含标记为 sendrecv 的 DMTF 的编解码器 8 和 101：
m = audio 35904 RTP/AVP 8 101
a = rtpmap:8 PCMA/8000
a = rtpmap:101 telephone-event/8000
a = fmtp:101 0-15
a = sendrecv
得到一个答案 SDP 的回答，其中一行“m”包含编解码器 8，但 DTMF 为 120，并且类似地标记为 sendrecv:
m = audio 1235 RTP/AVP 8 120
a = rtpmap:8 PCMA/8000
a = rtpmap:120 telephone-event/8000
a = fmtp:101 0-15
a = sendrecv
来自 RFC 3264:
For streams marked as sendrecv in the answer, the "m=" line MUST contain at least one codec the answerer is willing to both send and receive, from amongst those listed in the offer. The stream MAY indicate additional media formats, not listed in the corresponding stream in the offer, that the answerer is willing to send or receive (of course, it will not be able to send them at this time, since it was not listed in the offer).
RFC3264 以上部分，证明在应答 SDP 中发送不同的 DTMF fmtp(120 到 101) 符合 RFC3264，因为编解码器 8(G711a) 与报价 SDP 匹配。
DTMF 信令是否正常或是否可能存在 DTMF 问题？
感谢任何反馈。
总的来说：
RTP 负载类型编号 0-95 标识静态媒体编码。例如。有效负载类型 8 表示时钟频率为 8000 Hz (RFC3551). As such, this description doesn't have to (but should) be included in the media format description of the SDP offer/answer, using the "a=rtpmap:" and "a=fmtp:" attributes (RFC4566) 的 PCMA 音频。
有效负载类型编号 96-127 是动态的。这些可用于协商未包含在静态列表中的编码。使用这些数字之一时，媒体格式描述中必须包含编码规范以指定确切的编码参数。
协商双方可以选择自己的动态负载类型编号来表示相同的媒体编码，这不一定是相同的编号。当一方已经将特定的动态有效载荷类型编号分配给另一种编码时，这可能很有用。在您的示例中，一方在 m-line 中使用 101，另一方使用 120，但这些数字表示相同的媒体编码（请参阅“a=rtpmap:”行）。每一方都告诉对方“当您使用编码 X 发送 RTP 时，您必须在 RTP 数据包中包含有效负载类型编号 Y headers。
负载类型编号包含在RTP数据包的PT字段中headers (RFC 3550)
在这种情况下:
答案中的“a=fmtp:”属性将 101 指定为负载类型编号而不是 120。这意味着它不适用于 telephone-events 负载并且没有关于哪个 DTMF 的可用信息支持事件 (RFC 4733)。我认为这是一个实现错误，fmtp 属性旨在应用于 telephone-events 有效负载。
这表明您应该期待 DTMF 问题。但它也可以正常工作。试一试...