"RFC 2833 RTP事件"连续事件和E"结束"位

Question

为什么我在E位为0时获得dtmf声音而在1为1时没有声音？(RTP数据包以无论哪种方式出现在wireshark中)

背景:

我可以发送一个RFC 2833 dtmf事件,如http://www.ietf.org/rfc/rfc2833.txt所述, 当未设置E位时获得以下行为:

如果7874556332111111145855885#3按下键,则会发送所有事件并显示在wireshark等程序中,但只有87456321458585#3声音.所以第一个键(我认为可能是一个单独的问题)和事件的任何重复(即11111)都听不到.

在上面链接文档的图3.9的3.9节中,它们给出了一个911示例,其中除了最后一个事件之外的所有事件都设置了E位.

当我为所有数字设置'E'位为1时,我从未发出声音事件.

我想到了一些可能的原因,但不知道它们是否是原因:

1)图2显示了96和97发送的有效载荷类型.我没有发送这些标题.在3.8节中,代码96和97被描述为"分别为冗余机制和电话事件有效载荷分配了动态有效载荷类型96和97"

2)在第3.5节"E:"中,"发送方可以延迟设置结束位,直到重新发送音频的最后一个数据包,而不是第一次传输"是否有人知道如何实际执行此操作？

3)我有一个单独的输出流,如果它可能干扰听到这个流,也会很奇怪.

4)还摆弄了时间戳间隔和RTP标记.

任何帮助是极大的赞赏.以下是相关领域的wireshark事件捕获示例:

6590 31.159045000 xx.x.x.xxx --.--.---.-- RTP EVENT Payload type=RTP Event, DTMF Pound # (end)
Real-Time Transport Protocol
 Stream setup by SDP (frame 6225)
  Setup frame: 6225
  Setup Method: SDP
 10.. .... = Version: RFC 1889 Version (2)
 ..0. .... = Padding: False
 ...0 .... = Extension: False
 .... 0000 = Contributing source identifiers count: 0
 0... .... = Marker: False
 Payload type: telephone-event (101)
 Sequence number: 0
 Extended sequence number: 65536
 Timestamp: 2000
 Synchronization Source identifier: 0x15f27104 (368210180)
RFC 2833 RTP Event
 Event ID: DTMF Pound # (11)
 1... .... = End of Event: True
 .0.. .... = Reserved: False
 ..00 0000 = Volume: 0
 Event Duration: 1000

请注意:如ietf.org/rfc/rfc2833.txt规范中所述,音量为零是最大的可获得级别:

"音量:对于DTMF数字和其他可表示为音调的事件,此字段描述音调的功率电平,在丢弃符号后以dBm0表示.功率电平范围为0到-63 dBm0.有效DTMF的范围是从0到0 -36 dBm0(必须接受);必须拒绝低于-55 dBm0(TR-TSY-000181,ITU-T Q.24A).因此,较大的值表示较低的音量.该值仅为DTMF数字定义.事件,它由发送者设置为零,并被接收者忽略." 问题是当"事件结束"位打开时.

Answer 1

我建议您从RFC 4733开始,原因有两个:

1. 它阻碍了RFC 2833.
2. 第5章是了解如何生成DTMF数字的重要来源.

以下是我对如何发送DTMF数字的理解:

• 发出启动数据包.它设置了M标志并清除了E标志.设置事件的时间戳.
• 发出一个或多个连续数据包(只要用户按下数字).他们的M和E旗帜被清除了.它们使用起始数据包中定义的时间戳,但它们的序列号和持续时间会增加(请参阅RFC的间隔).
• 发送结束包(当用户停止按下该数字时).它已清除M标志并设置其E标志.

为什么要为一个事件发送几个数据包？因为网络并不总是完美的,可能会发生一些损失:

• RFC声明(2.5.1.2."事件包的传输"):

  为了健壮,发送方应该定期重新发送"状态"事件.

• (2.5.1.4."最终数据包的重传"):

  每个事件和每个段的最终数据包应该
  以更新源使用的间隔发送总共三次.
  这确保即使最后一个数据包的实例丢失,也可以正确识别事件或段的持续时间.

至于你的问题:

如果按下按键7874556332111111145855885#3,则会发送所有事件并显示在wireshark等程序中,但只有87456321458585#3声音.所以第一个键(我认为可能是一个单独的问题)和事件的任何重复(即11111)都听不到.

没有WireShark跟踪,很难分辨出发生了什么,但我怀疑重复1数字会被忽略,因为连续事件之间没有区别; 第一个1数字被识别,其他数字被认为是事件的重传.