sip.js初探
前言
项目中我们有个通过浏览器进行人工外呼的需求，这边就涉及了一些voip相关的技术栈。使用freeswitch作为软交换平台，sip（会话初始协议）来作为信令的载体，结合webrtc等相关技术实现浏览器端拨打电话的需求。sip.js是使用javascript对sip协议进行了封装，它恰恰也是结合了webrtc来帮助我们快速构建浏览器端音视频的实时传输。
关于sip协议
sip如同我们熟悉的http协议一样，是一个基于文本的应用层信令控制协议，它也是采用了请求/响应的方式进行通信。常见的请求消息包括:
- INVITE：表示主叫用户发起会话请求
- ACK：客户端向服务器端证实它已经收到了对INVITE请求的最终响应
- BYE：表示终止一个已经建立的呼叫（呼叫结束）
- CANCEL：表示在收到对请求的最终响应之前取消该请求，对于已完成的请求则无影响。
除此之外，还有其他的一些请求类型，但是并不常用，常见的基本上就是这4种。当收到请求后，服务端需要作出响应，例如客户端发起INVITE请求后，服务端开始建立会话，此时会依次发送以下响应消息，表示当前会话状态：
- 100试呼叫（Trying）
- 180/183表示正在外呼，此时可以有振铃或者早起媒体。180和183的区别，可参考这篇文章
- 200成功响应
这时候客户端需要返回一个ACK表示已成功建立会话。这里的3种响应消息，只代表着一通电话正常建立的情况，还有一些标识错误的消息，例如401未授权、486线路忙等等，可以看到其和http非常像，有标识码和描述信息。不过要注意，sip只是用于创建、修改和释放一个或多个参与者的会话，具体的选择何种会话类型、语音编解码信息、负载信息等需要通过sdp（会话描述协议）来控制。上面提到的183或是200响应状态，均会携带sdp信息，用于建立媒体通道，关于sdp报文格式，可以参考这篇文章。
深入sip.js
sip.js使用javascript对sip协议进行了封装，我们上面提到过sip只是用来控制会话的建立和修改，它并不提供会话描述、会议控制等功能，这些是通过sdp来进行描述的。并且它也不能提供媒体通道的建立，在浏览器端建立媒体通道，我们最容易想到的就是webrtc，sip正是通过webrtc来进行媒体通道的建立。有关webrtc的相关学习，我们可以参考这个。学习过webrtc之后我们知道，webrtc的客户端之间是通过建立RTCPeerConnection（简称pc）来实现音视频数据流的传输。在建立pc之前，也需要去交换一些媒体信息，我们称之为signaling过程。signaling用来交换三种信息：
- 连接控制信息：初始化或者关闭连接报告错误。
- 网络配置：对于外网，我们电脑的 IP 地址和端口。
- 多媒体数据：使用什么编码解码器，浏览器可以处理什么信息。
而webrtc已经提供api让我们快速生成这些媒体数据，即pc的createOffer方法和createAnswer方法，而他们生成的数据恰恰就是上面提到的sdp格式的文本。因此我们可以得出结论，webrtc也是通过sdp来进行媒体数据的交换，从而建立媒体通道的。至于为什么会分createOffer方法和createAnswer方法，是因为signaling采取了一种offer/answer的方式，类似于请求/问答，发起方发送offer，应答方发送answer，双方交换媒体信息之后才会完成signaling，从而建立pc。媒体数据的交换可以采取多种传输方式，sip.js中默认使用的是websocket进行传输。举个例子可以让大家更加清晰得明白使用sip.js之后一通会话的建立过程：
- 客户端发起invite请求，invite中携带了客户端的媒体数据，通过createoffer方法封装成sdp报文，一并传输给服务端
- 服务端收到请求（我们是用freeswitch），解析sdp，发起呼叫，同时向客户端发送呼叫状态的响应，如100、183、200，在183和200的时候均会携带服务端sdp，区别在于200是真正建立的通话，183可能会携带早期媒体等信息。
- 客户端默认情况会解析200状态所携带的sdp信息，至此完成signaling过程，媒体通道建立，开始对话。
总结
通过以上的介绍，我们可以看出sip和webrtc的关系，它们其实负责实现不同的功能，但又可以非常好的结合在一起构建更强大的应用。sip主要负责会话的创建和管理，而webrtc用于建立媒体通道，从而实现浏览器端音视频流的传输，而sip.js正是将两者结合，从而帮助大家快速开发出大型web端的会话应用。本文只对sip.js的原理进行部分解读，并没有介绍如何使用这些技术，具体还需要参考文档或是可以阅读源码获得更多的信息。