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使用一個偶數埠)
組網架構
上級平臺（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君，讓監控變得更簡單***