一、引言
之前写过一篇博客《使用 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" 获取。
附-改造方案：
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
