SIP协议简介（二）之会话建立的详细过程（INVITE）

SIP是基于一个类似HTTP协议的请求应答的通讯模式。每一个通讯都包含对某个功能的请求，并且起码需要一个应答。在这个应答中，通信双方的Alice的软电话发送一个含有通信双方的Bob的SIP URI抵制的INVITE通讯请求。INVITE是一个SIP请求的例子，表示请求方（Alice）希望服务方（Bob）应答。INVTE请求包含一系列的包头域（Header fields）。包头中包含很多属性并且包含了传输消息的附加信息。在INVITE中有如下的字段：呼叫的唯一标志、目的地址、Alice的地址、Alice和Bob建立会话的类型。
　　在上一篇文章中，通过图片的形式描述了一个会话发起的过程，在会话发起时，主叫方会发送INVITE信令来发起建立会话的请求，这个信令的基本内容如下：　　
　　往往会结合SDP这个会话描述协议来描述整个媒体的会话参数，比如说音视频的编码格式、音视频的编码码率、音视频的采样率、视频的分辨率等等。这个可以通过SIP的消息正文来描述，可以通过其他定义的协议在正文中进行描述。有一种是会话描述协议（Session Descripotion Protocol SDP）（RFC2327[1]）。这个SDP消息通过SIP的消息中传送，就像通过附件发送EMAIL一样，或者说通过HTTP传输的网页一样。
　　在文本消息的第一行，包含了请求的类型（INVITE）。在这行之后的是这个请求的头域。这个例子中包含了最少需要的头域集合。简单介绍一下：

VIA域包含了Alice接收发送请求的服务器地址（pc33.atlanta.com）。同样这个包含了一个分支参数来标志Alice和这个服务器的会话事务。
TO域包含了显示姓名（Bob）和一个SIP或者SIPS URI（sip：bob@biloxi.com）请求将首先传输到这个URI中。显示姓名（Display names）在RFC 2822中描述。
From域也同样包含一个显示姓名（Alice）和一个SIP或者SIPS URI（sip:alice@atlanta.com）这个URI用来标志请求的原始发起者。
这个域也包含了一个TAG参数，这个TAG参数是一个随机字串（1928301774），是软电话（softphone）在URI上增加的一个随机串。用来做标志用途的。
Call_ID包含一个全局的唯一标志，用来唯一标志这个呼叫，通过随机字串和softphone的自己名字或者IP抵制混和产生的。通过TO TAG, FROM TAG和CALL-ID完整定义了Alice和Bob之间的端到端的SIP关系，并且表示这个是一个对话性质的关系。
CSEQ或者Command Sequence包含了一个整数和一个请求名字。这个Cseq数字是顺序递增的。每当对话中发起一个新的请求都会引起这个数字的顺序递增。
Contact域包含一个SIP或者SIPS URI用来表示访问Alice的直接方式，通常由用户名和一个主机的全名（Fully Qualified Domain Name FQDN）组成。当FQDN作为首选的时候，许多终端用户由于不会由名字登记（而导致不能访问Alice的主机），所以IP地址是可选的。
VIA域告诉大家本请求发送到哪里并且应答到哪里，Contract域告诉大家将来的请求将发送到哪里（奇怪…不是Alice发起的么，将来的请求应该是Bob才对啊）。
Max-Forwards:最大转发数量限制了通讯中转发的数量。它是由一个整数组成，每转发一次，整数减一。
Content－type包含了消息正文的描述（比如前面提到的application/sdp）
Content-length:包含消息正文的长度（字节数）

　　这个也是任何一个信令中不可或缺的内容。由于softphone并不知道bob或者bob的sip服务器biloxi.com在哪里，所以softphone发送INVITE请求到Alice的sip服务器,atlanta.com。这个atlanta.com SIP服务器应该已经在Alice的softphone中配置了，或者可以通过DHCP获得。atlanta.com SIP服务器是一台代理服务器。代理服务器接收SIP请求并且根据请求转发。在这个例子中，代理服务器接收到INVITE请求，并且回送一个100（Trying）应答给Alice的softphone。100（Trying）应答表示INVITE请求已经收到，并且代理服务器正在转发INVITE请求。
　　SIP的应答是通过一个三位数的数字表示的。SIP应答同样包含TO、FROM、Call-ID，CSEQ和在VIA中的分支参数，这个参数使得Alice的softphone可以把请求和应答关联起来。atlanta.com代理服务器收到INVITE请求之后，就去找biloxi.com可能通过DNS服务来找提供这个biloxi.com的SIP服务器。最后，转发INVITE请求到biloxi.com或者能到达biloxi.com的代理服务器。在转发请求之前，atlanta.com代理服务器会在via头上增加一个一段包含自己抵制的值（INVITE已经包含了Alice的的地址VIA域）。biloxi.com代理服务器收到这个INVITE请求并且返回一个100（Trying）应答给atlanta.com代理服务器标志这它已经收到这个请求并且正在处理这个请求。这个代理服务器通过查询数据库，通常叫做地址服务，这个服务中包含了bob的当前ip地址。biloxi.com代理服务增加另一段包含自己地址的VIA头域并且发送它到bob的sip 电话。
　　Bob的SIP电话接收到INVITE请求并且提醒bob有一个从Alice的呼入，这样bob可以决定是否响应这个呼入。这个意思就是：bob的电话响了。bob的sip电话发送一个180（Ringing）回应，这个回应将通过两个代理服务器原路返回给Alice。每一个代理服务器通过via头域决定该把这个应答发送给哪里，并且在发送之前把自己的地址从头上拿走。虽然DNS和定位服务在路由最初的INVITE请求，180（ringing）响应可以简单返回给发起者而不需要查找发起者在哪里，并且不需要在代理服务器保留状态，同时，每一个转发INVITE的代理也可以得到INVITE的每一个应答，这样的特性也非常有用。
　　当Alice的softphone收到180（Ringing）应答的时候，它提示Alice,可能是通过一个回铃音，或者屏幕上的一个消息提示。Bob决定响应这个呼叫。当他拿起电话，他的SIP电话发送200（OK）回应给发送者，表示这个电话已经接起来了。这个200（OK）包含了一个消息体，这个消息体包含SDP媒体描述，这个媒体描述包含Bob希望和Alice建立何种媒体连接。同样，SDP消息也是两段交换：Alice发送一个给Bob，Bob发送一个回给Alice。这个两段的交换提供基本的兼容性协商，并且基于简单的SDP提出/应答交换模型。如果Bob不想响应这个呼叫或者正在响应别的呼叫，一个错误的响应会代替正常的200（OK）回送出去，这样，就不会有连接建立。
　　当正常情况发生时，200（OK）应答通过两个代理并且发送到Alice的softphone上，Alice的softphone收到这个应答，停止振铃，并且标志电话Bob已经接听。最后，Alice的电话发送一个确认消息，ACK，到Bob的SIP电话来确认接收到了这个最后的200（ok）应答。在这个例子中，ACK信号是直接由Alice的softphone发送到Bob的SIP phone上，跨过了两个代理服务器。这是因为两个端点（Alice和Bob）通过INVITE/200(OK)的请求应答包中的Contact包头域都知道互相之间的地址了，这个地址是最开始发起INVITE请求的时候所不知道的。所以，不需要两个代理服务器再查找对方的地址了，所以代理服务器不参与接下来的通话流了。这就完成了一个完整的使用INVITE/200/ACK 三方握手来建立SIP会话的过程。会
　　现在，Alice和Bob的媒体会话开始了，他们通过发送刚才建立会话所交换的SDP包中约定的互相明白的媒体包来进行会话。一般情况下，端到端的媒体包和SIP信号控制包通过不同的通讯路径来发送。
注意：在这个过程中，其实通信的双方就可以进行媒体会话层的协商，比如具体整个通信双方采用什么样的音视频格式，Alice端采用什么格式来进行编码，Bob端采用什么类型解码等，这个都可以在这个协商过程中敲定下来，具体采用什么样的机制，各自根据自己的需求进行设计即可。在进行代码实现的时候，可以去找exosip开源库，同时在媒体层进行会话参数协商时，自行设计实现对相关信令的解析。在这里，主要给大家介绍基本的通信链路搭建的过程，涉及到具体项目的内容，不进行讲述。