RFC3261 SIP协议---- invite

UAC初始化一个会话
1、创建一个invite请求
创建invite请求除了之前的6个必须包含的头域外，invite请求还应该包含：
Allow头域：指出了在一个对话中，什么样的方法可以被处理。
Support头域：指出了UAC可以支持的扩展方法有哪些。
Accept头域：指出了那些content-type是UAC支持的。
Expires头域：指出了一个invite消息的有效期限。如果expire头域的时间期限已经到了，UAC还没有收到invite的响应，那么就应该发送一个cancel请求。
Content-type：用来指出本次会话的消息体类型是什么。
一个UAC的invite还可以包含Subject头域、Organization头域、Uesr-Agent头域。这些头域都是用来说明这个invite消息的。一个invite消息的消息体，是sip消息对要初始化的会话的描述，包括要是用什么流媒体协议、什么方式编解码等等。
在两个UA之间建立会话的时候，首先要进行磋商的是两个UA都能支持的消息正文格式。这个磋商的内容可以是在invite请求中，也可以是在回复的2xx应答中，也可以实在回复的ack确认中。无论是建立会话成功的2xx，还是其他的3xx，4xx的回复，UAC都需要回复一个ack的应答。

2、invite请求的应答
    当UAC发送了一个invite请求后，UAC等待invite请求的应答消息到来。下面就是应答消息的分类：
    1xx应答（临时应答）：
        0个或是多个临时应答消息会在一个或是多个应答消息之前到来，invite的临时应答可以创建一个“早期会话”
    3xx应答（重定向应答）：
        一个3xx应答可能包含一个或是多个contact头域，它指明了重定向的地址，UAC可以根据这些地址来重新发送invite消息。
    4xx、5xx以及6xx应答：
        一个非2xx的应答都会包含一个contact头域，这个头域包含了错误的原因。当UAC收到这个非2xx的应答后，UAC认为这个invite请求结束，并发送ack做为这个应答的回应。
    2xx应答（请求成功应答）：
        UAC发出一个invite请求，可能会收到多个2xx的应答，这是因为分支代理的原因。每个2xx应答是根据To头域中的tag来进行区分的，每个2xx应答都是一个会话。

UAS处理invite
1、UAS首先要根据之前说过的头域判定来进行判断，如果顺利处理成功，那么UAS还要做如下的判断：
（1）如果一个invite包含了一个expire头域，那么UAS要判断是否超时，如果已经超时，那么发送487应答指出请求已经终止了。
（2）。。。。未完待续
2、提示进度
如果UAS不能马上接受或则是拒绝邀请，那么它可以提示某种形式的进度给UAC。这个提示是通过101~199临时应答来实现的。这些应答建立了“早期的会话”。临时应答都并非可靠传输，那么如果UAS想要延长应答时间，就需要一个extension来防止代理服务器取消这个事务。
3、请求重定向
如果代理服务器决定重定向这个invite请求，那么就要进行3xx的应答。300（多重选择）、301（永久转移）、302（临时转移），这个应答应该包含一个contact头域来指明新的发送地址。
4、拒绝请求
拒绝invite请求常见于被叫方不愿意接听或者不能再这个终端上接听。如果UAS知道没有其他终端系统能够接听这个请求，那么UAS则返回一个600（busy everywhere），不过通常UAS不会知道这个的。更常见的是UAS拒绝了invite的关于媒体磋商的请求，UAS返回一个488错误（Not acceptable here），这个488的应答应该包含一个Warning头域，用来解释为什么拒绝。
5、接受请求2xx
响应UAC的请求的2xx应答中，包含了Allow头域与Supported头域，并且可能包含Accept头域。包含这些头域的目的在于为了不让UAC再次请求就能知道对方的特性以及支持的扩展。
如果invite请求中包含了一个媒体磋商offer，并且UAS没有进行应答，那么2xx就要针对这个offer进行应答。如果invite没有包含媒体磋商的offer，而且UAS也未发出之类的offer，那么2xx要包含一个媒体磋商的offer。