1實時點播信令流程
平臺點播實時視頻到關閉視頻這個過程，上下級平臺信令交互分爲五個步驟，點播請求視頻信令由上級平臺發起。通過wireshark抓包發現信令如下：
信令包爲SIP包（Session Initiation Protoocal），傳輸層使用UDP協議。
點播流程：
①上級平臺向下級發送INVITE請求，請求實時視頻
②下級平臺回覆200OK
③上級平臺回覆ACK確認
④關閉視頻，上級向下級平臺發送BYE請求，請求關閉視頻
⑤下級平臺回覆200OK
2點播信令流程詳解
2.1上級發送INVITE請求
上級平臺（192.168.2.2爲平臺對接網關）向下級（192.168.1.1爲平臺對接網關）發送invite請求，請求國標編碼爲44140302001310131077的這路攝像機視頻。
①Call-ID：唯一標識這次的點播流程，即這次點播的五條信令中的Call-ID都是相同的。
②s=Play：說明請求的是實時視頻。
③c= IN IP4:此字段的IP地址爲自己平臺的流媒體服務器，通過此字段告知對方流媒體的地址（192.168.2.30）。
2.2下級回覆200OK
下級平臺收到invite點播請求後，回覆200OK允許請求，並在提供流媒體服務器信息，即通過c=IN IP4字段通知上級平臺自己的流媒體服務器地址是多少（192.168.1.1）。
2.3上級回覆ACK確認
上級平臺收到200OK信息後，會發送ACK進行確認，然後雙方的流媒體服務器就會進行碼流傳輸。碼流包傳輸分爲基於TCP和UDP協議這兩種方式。
①碼流基於UDP傳輸
下級平臺收到ACK包後，流媒體服務器（即192.168.1.1）主動向上級流媒體（即192.168.2.30）發送視頻流。
②碼流基於TCP傳輸
由於TCP協議是可靠傳輸，需要先通過三次握手建立連接，作爲TCP客戶端的流媒體向TCP服務端流媒體發起TCP請求建立連接，連接建立後下級平臺流媒體繼而開始發送視頻流。
2.4上級發送BYE請求關閉視頻
上級平臺關閉視頻，上級網關主動向下級網關發送BYE信令，請求關閉視頻。
①碼流基於UDP
2.5下級回覆200OK同意關閉視頻
下級網關收到BYE請求後，回覆200OK同意關閉視頻，然後流媒體服務器開始停止發送視頻流，停止發送視頻流又分爲基於TCP和UDP這兩種情況。
①碼流基於UDP傳輸
下級網關回復200OK後，下級流媒體主動停止發送視頻流。
②碼流基於TCP傳輸
下級網關回復200OK後，流媒體服務器之間通過四次揮手斷開連接，此過程由作爲TCP客戶端的流媒體服務器主動發起斷開TCP連接請求。
3實時點播總結
平常在排查實時視頻點播失敗的問題時，可通過查看對接網關日誌或者抓包來分析整個點播流程，定位出哪個信令步驟出錯。如果信令回覆都正常，則在流媒體之間抓碼流包分析碼流包是否正常。例如在實際環境中就遇到信令回覆正常但是視頻點播無圖像的情況，通過抓碼流包發現下級平臺實際發送視頻流的流媒體服務器IP與網關信令中回覆的流媒體服務器IP不一致，導致視頻點播無圖像。