项目中我们有个通过浏览器进行人工外呼的需求，这边就涉及了一些voip相关的技术栈。使用freeswitch作为软交换平台，sip（会话初始协议）来作为信令的载体，结合webrtc等相关技术实现浏览器端拨打电话的需求。sip.js是使用javascript对sip协议进行了封装，它恰恰也是结合了webrtc来辅佐我们快速构建浏览器端音视频的实时传输。

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使用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的道理进行部分化读，并没有介绍如何使用这些技术，具体还需要参考文档或是可以阅读源码获得更多的信息。