一、引言

之前寫過一篇博客《使用 GB28181.Solution ZLMediaKit? MediaServerUI 進行攝像頭推流和播放》，里面是使用了?GB28181.Solution 工程的?GB28181.WinTool 測試程序來作為 SIP 服務器的，該程序界面上體現的功能是比較全的(不過本人只測試了

二、項目淵源

GB28181.Solution?里使用了?SIPSorcery?開源項目的代碼，本項目?SimpleSIPServer?也是從 SIPSorcery 的一個例子 SIPProxy 起頭的，里面還有些其它的例子，有助于學習如何使用 SIPSorcery，大家可以看看：

SIPSorcery 的核心功能通過 NuGet 包引入，當前使用的是 v4.0.60-pre 版：

本項目還借用了?GB28181.Solution 中針對于 GB28181 進行擴充的實體定義(幾個文件夾都拷過來了，以備不時之需)，以及幾個方法：

三、軟件使用及 SIP

(一) 注冊和心跳

首先啟動程序，在配置區按實際情況進行配置：

SIP 服務器默認端口為 5060，DeviceId 目前來說不重要，媒體服務器的一些配置可參考引言中提到的文章(本文還是使用?ZLMediaKit?作為流媒體服務器)。

啟動服務主要是配置 SIP 通道，然后附加一些事件的處理方法：

攝像頭配置好 SIP 服務器后，會周期性地嘗試注冊和發送心跳到配置的 SIP 服務器 IP:Port。

這樣我們啟動服務器后，就能收到注冊請求(REGISTER)了。當然，這次是運氣比較好，一下就收到了注冊請求，通常還會有先收到一段時間的心跳請求然后才收到注冊請求的情況。收到注冊請求后，我們先回了個 100 Trying 消息(應該是非必需的)，表示正在處理，處理完成后，又回了個 200 OK 消息，如下圖：

回應心跳請求也是用 200 OK，有說法是不要回應未注冊的心跳，我在本程序里也加了這個開關，不過測試中好像和回應的情況沒什么區別，大家可以自己試試。

抓包列表如下：

(二) 直播 INVITE

設備(攝像頭)注冊成功后，展開 “連入的客戶端” 區域，并點擊選中一項，然后就可以點擊 “請求開始直播”：

程序發送 INVITE 請求，然后攝像頭依次響應 100 Trying、101 Dialog Establishement 中間狀態，最后回復 200 OK：

收到 200 OK 后，程序需要發送 ACK 請求，然后攝像頭收到后就可以進行推流(RTP/PS)了：

可以看到 PS 流有個?SSRC (同步源標識)，這個是用來區分流的，由本程序在發出 INVITE 時附帶，生成和發送的時候是 10 進制，此處顯示為 16 進制：

由上圖還可看到，本程序依據?ZLMediaKit 的播放地址規則(使用了十六進制形式的 SSRC)，直接生成了播放地址，使用 PotPlayer 打開鏈接即可播放：

支持發起多個直播請求(多個設備)，使用?MediaServerUI?查看：

停止直播就是發送 BYE 指令：

(電腦 C 盤突然空間不足了，抓包失敗)

四、注意事項

開發過程中遇到這樣一個情況：

IPC(網絡攝像頭) 回復 200 OK 后，程序發送 ACK 消息過去，但是 IPC 不認，還是繼續回復 200 OK，幾次之后就 BYE 了。

經過流媒體服務器?Monibuca?的作者指導，得知原因是，CallId 要和 200OK 的 CallId 一致。另外，這個通信過程中直接使用 IPC 的設備編號就行，不一定要使用通道編號(GB28181.WinTool 是使用通道編號)。

實際上，RFC 3261 中說：

The combination of the To tag, From tag, and Call-ID completely defines a peer-to-peer SIP relationship...

也就是 INVITE 整個通信過程中，由 FromTag、ToTag 和 CallId 三者一起唯一確定一個 SIP 的點對點關系，也就是說 ACK 和 BYE 兩個請求中，這三者要和 200 OK 發過來時的值一致：

五、資源

SIP 指令抓包數據：關注微信公眾號 "獨立觀察員博客" 后回復 "SIP" 獲取。

附-改造方案：

總結

以上是生活随笔為你收集整理的服务器发布的项目请求摄像头权限,使用 WPF 版简易 SIP 服务器向 GB28181 摄像头发送直播请求...的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。