作者：独立观察员
目录 一、引言 二、项目渊源 三、软件使用及 SIP INVITE 流程 (一) 注册和心跳 (二) 直播 INVITE 四、注意事项 五、资源
一、引言之前写过一篇博客《使用 GB28181.Solution ZLMediaKit MediaServerUI 进行摄像头推流和播放》，里面是使用了 GB28181.Solution 工程的 GB28181.WinTool 测试程序来作为 SIP 服务器的，该程序界面上体现的功能是比较全的（不过本人只测试了直播功能）。实际上，好多功能本人用不到（比如云台控制、警报之类的），加上该程序代码有点纷繁复杂，而且似乎只能直播一个设备（未严格测试），所以想着参考该程序，自己写个简易的 SIP 服务器（UA），功能上只要求能够接受注册、发起直播请求等就行。
二、项目渊源GB28181.Solution 里使用了 SIPSorcery 开源项目的代码，本项目 SimpleSIPServer 也是从 SIPSorcery 的一个例子 SIPProxy 起头的，里面还有些其它的例子，有助于学习如何使用 SIPSorcery，大家可以看看：
SIPSorcery 的核心功能通过 NuGet 包引入，当前使用的是 v4.0.60-pre 版：
本项目还借用了 GB28181.Solution 中针对于 GB28181 进行扩充的实体定义（几个文件夹都拷过来了，以备不时之需），以及几个方法：
三、软件使用及 SIP INVITE 流程
(一) 注册和心跳
首先启动程序，在配置区按实际情况进行配置：
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 发过来时的值一致：
项目地址：https://gitee.com/DLGCY_GB28181/SimpleSIPServer
觉得好的同学，记得收藏点个赞！
