为什么发出去的2833 RTP流不能收号

简介: 为什么发出去的2833 RTP流不能收号

对前段时间解决的收号问题做个复盘。


我开发的媒体服务器部署在某省,为电话用户提供媒体服务。前段时间我们现场交付同事联系我,有某总机电话,无法进行收号。


于是先请现场的同事进行了媒体抓包,我通过媒体包分析媒体包,发现DTMF部分的数据都传输过去了。


061e03ee0013435eaa72249d58dd4f65.png


但有两个RTP的HEADER地方不太一样。一个是DTMF发送的按键的第一个RTP流中的Marker,一个是DTMF发送按键时,它的Timestamp是不变的。


eb93e339e47c47bc88fb3b5d042e70f8.png

a4a271821da9496eb49fae24fc9d9903.png

eed6e242180042ceb03ee4a5bb08edef.png


于是进行排除法进行修改.


先是将Timestamp的发送算法就行了修改,发送DTMF时,同一个DTMF,Timestamp不变。 在公司测试okay后,在现场进行了升级。经过拨测总机还是收不到号。然后我就注意到了Marker。


然后继续修改MS,当DTMF发送第一个RTP包时,将Mark设置为True,后面设置为False。再次升级验证后,收号正常了。


后来我又查了下RFC 2833的规范说明。


Marker为True,表示DTMF的起始位。


Marker bit: The RTP marker bit indicates the beginning of a new    event.


f2607e153fd44aec912191b4b946125b.png

相关文章
|
Python
143 python网络编程 - UDP发送、接收数据
143 python网络编程 - UDP发送、接收数据
82 0
|
2月前
|
存储 XML JSON
【TCP】核心机制:延时应答、捎带应答和面向字节流
【TCP】核心机制:延时应答、捎带应答和面向字节流
75 2
|
网络架构
为什么udp流设置1316字节
为什么udp流设置1316字节
117 0
|
定位技术 开发工具 Windows
如何在RTSP/RTMP直播过程中加入SEI扩展数据发送和接收解析
在直播系统中,除了直播音视频之外,有时候还想从主播端发布文本信息等,这些信息可以不通过视频传输通道发送给用户播放端,但如果传输的数据想和视频保持精准同步,那最好的办法就是这些信息和视频数据打包在一起传输,并通过h264 sei方式就可以把数据放入h264 Access Unit中传输。
312 0
|
机器学习/深度学习 缓存
【计算机网络】数据链路层 : 后退 N 帧协议 GBN ( 滑动窗口 | 发送窗口长度 | “发送方“ 累计确认、超时机制 | “接收方“ 按序接收、确认帧发送机制 | 计算示例 )★(一)
【计算机网络】数据链路层 : 后退 N 帧协议 GBN ( 滑动窗口 | 发送窗口长度 | “发送方“ 累计确认、超时机制 | “接收方“ 按序接收、确认帧发送机制 | 计算示例 )★(一)
692 0
|
机器学习/深度学习
【计算机网络】数据链路层 : 后退 N 帧协议 GBN ( 滑动窗口 | 发送窗口长度 | “发送方“ 累计确认、超时机制 | “接收方“ 按序接收、确认帧发送机制 | 计算示例 )★(二)
【计算机网络】数据链路层 : 后退 N 帧协议 GBN ( 滑动窗口 | 发送窗口长度 | “发送方“ 累计确认、超时机制 | “接收方“ 按序接收、确认帧发送机制 | 计算示例 )★(二)
757 0