DZ先生怪谈国标案例10——论国标视频流端口奇偶性

自述

今天DZ先生主讲的案例是关于国标视频流端口奇偶性的，DZ先生在处理这个问题之前已经知道国标视频流端口定义为偶数，只是在我所负责大平台中，网闸把我的视频流端口改为了奇数，虽然业务一直正常，直到这次遇到严格规范的视频流端口的架构，网闸导致了我的平台信令报错。DZ先生我曾经多次与网闸交锋，虽然保持着**的记录，但他们的言行，和服务态度让我决定利用这次机会再战一回。说问题之前想给大家介绍下国标RTP视频流端口奇偶数定义：
在RFC  1889  的第10章中讲述到
10. RTP over Network and Transport Protocols
RTP relies on the underlying protocol(s) to provide demultiplexing of RTP data and RTCP control streams. For UDP and similar protocols, RTP uses an even port number(RTP使用一个偶数端口) and the corresponding RTCP stream uses the next higher (odd) port number. If an application is supplied with an odd number for use as the RTP port, it should replace this number  with the next lower (even) number.（如果一个应用提供的RTP端口为奇数，它应该被替换掉用比它低一点的偶数，这边应该是相当于奇数-1后的偶数）

组网架构

上级平台（192.168.1.1）------------（192.168.1.254）网闸（10.1.1.254）------------（10.1.1.1）下级平台

问题描述：

上级平台浏览下级平台的录像信令报错。

回放信令抓包分析（上下级平台互抓）

上级抓下级invite报文：
v=0
o=32028159031327200061 0 0 IN IP4 192.168.1.2
s=Playback
u=32028159031327200061:17577
c=IN IP4 192.168.1.2------------------媒体收流地址
t=1541738382 1541743573
m=video 24930 RTP/AVP 96-------24930为收流端口偶数

下级抓上级invite报文：
v=0
o=32028159031327200061 0 0 IN IP4 192.168.1.2
s=Playback
u=32028159031327200061:17577
c=IN IP4 10.1.1.254------------------媒体收流地址
t=1541738382 1541743573
m=video 17413 RTP/AVP 96-------17413为收流端口奇数

分析总结：

上级平台浏览录像向下级发送invite报文，告知下级平台的收流端口为偶数端口，网闸在进行转发invite报文的时候，将收流端口改为了奇数端口。此时需要网闸按照国标定义将收流端口改为偶数。（现实中，经过网闸整改后，业务恢复正常）

DZ先生个人官方微信

***关注DZ君，让监控变得更简单***