RFC3261（13 会话）
13.1 概览
当UAC希望初始化一个会话（比如，audio,video或者游戏），它首先构造一个INVITE请求。这个INVITE请求一个服务器来建立一个会话。这个请求可能会由proxy层层转发，最后到达一个或者多个可能能够处理这个邀请的UAS。这些UAS需要反复查看用户是否接收这个邀请。然后UAS可以接收这个请求（也就是会话建立了），通过发送2xx应答。如果邀请被拒绝，根据拒绝的原因，3xx，4xx，5xx或者6xx应答将会发送。在发送终结应答之前，UAS可以发送一些临时应答（1xx）应答给UAC，以便UAC能够掌握建立会话的进度。
当收到了一个或者多个临时应答，UAC可能收到一个或者多个2xx应答或者一个非2xx终结应答。由于在INVITE终结应答之前，可能有不少时间，INVITE事务的可靠性机制和其他的请求不同（比如OPTIONS）。当UAC收到了终结应答，UAC需要给每一个INVITE的终结应答，发送一个ACK请求。发送ACK请求的步骤依赖于应答的类别。对于在300到699的终结应答，ACK是在transaction层处理的，并且遵循一系列规则（17节）。对于2xx应答，ACK是由UAC处理核心产生的。
INVITE的一个2xx应答会建立一个会话，同时也建立了一个基于发送INVITE请求的UA和产生2xx应答的UA之间的对话。因此，当从多个远程UA收到了多个2xx应答（可能由于INVITE的分支），每一个2xx建立一个不同的对话（dialog）。所有这些对话都是同一个呼叫的组成部分。
本节介绍了INVITE请求建立会话的详细过程。支持INVITE的UA也一定同时支持ACK,CANCEL和BYE。
13.2 UAC处理
13.2.1 创建一个初始化的INVITE
由于初始化的INVITE请求是一个对话外的请求，它遵循8.1.1节的步骤创建。除此之外还有专门针对INVITE的附加处理步骤。
在INVITE中应当包括一个Allow头域（20.5节）。它用来标志在这个INVITE建立的对话（dialog）中可以接受哪些方法。比如，一个UA可以在对话中接收和处理INFO请求[34]，那么在INVITE请求的Allow头域中应当列出这个INFO方法。在INVITE请求中应当包含Supported头域，这个头域包含了所有这个UAC支持的扩展部分。在INVITE中可以包含一个Accept头域（20.1节）。这个标志了UA在后续建立的对话中，能兼容的接收和发送的Content-Type。Accept头域对于支持不同会话描述格式的时候特别有用。
UAC可以通过包含一个Expire头域(20.19节)来限制请求的有效期限。如果Expire头域的时间到了还没有接收到INVITE的终结应答，UAC处理核心应当像9节描述的那样产生一个对INVITE请求的CANCEL请求，
UAC还可以根据需要增加Subject(20.36节)，Organization(20.25节)和User-Agent(20.41节)头域。这些头域都包含了INVITE的相关信息。
UAC可以给INVITE增加一个消息体。8.1.1.10节讲述了如何构造Content-Type头域来描述消息体。
包含会话描述的消息体有一些特别的规则――他们是基于某种协商机制的，它们对应的Content-Disposition头域值是“session”(会话的)。SIP使用一个请求/应答模型，UA发出一个会话描述，称作请求，里边包含了会话的描述。这个请求包含了期望的通信方式（比如audio，vidio，game），以及这些通信方式的参数（比如解码器等等），并且从应答方接收媒体信息的地址。对方UA会回应另外一个会话的描述，称之为应答，标志了能接受的通信方式，以及这些方式的参数。这个请求/应答的交换是在对话的上下文中进行的，所以如果一个SIP INVITE请求导致了多个对话，每一个对话都包含自己独立的请求/应答的交换。请求/应答模型规定了实现请求和应答的限制条件。（比如在上一个请求尚未处理完成情况下不能发起下一个请求）。这也导致了请求/应答在SIP消息中出现的位置限制。在这个规范中，请求和应答只能出现在INVITE、ACK请求及其应答中。请求和应答在使用中更进一步的限制。在初始化一个INVITE事务中，规则如下：
o 初始化请求必须在INVITE中，如果不在INVITE请求中，就必须在UAS回送给UAC的第一个非失败的可靠消息中。在这个规范中，这个应答就是2xx应答。
o 如果初始的请求是一个INVITE，那么应答必须是由UAS发送回给对应发出INVITE请求的UAC的可靠的非失败的消息。在本规范中，只有2xx应答对应这个INVITE请求。同样相同的应答可能在之前发送的临时应答中存在。UAC必须把它接收到的第一个会话描述当作是应答，并且必须忽略任何在初始INVITE请求中后续的应答中的会话描述。
o 如果初始的会话描述是在UAS回送给UAC的第一个可靠的非失败的的消息中，那么会话描述应答必须在这个消息的确认消息中（在本规范中，就是给2xx应答的ACK确认消息）
o 在发送或者接收到第一个请求的应答之后，UAC可以同样依据这样的问答方法产生后续的请求。但是只能在收到每一个请求的应答之后才能发起下一个请求。不能在上一个请求尚未收到应答的时候发起下一个请求。
o 当UAS发送或者接收到初始化的请求的时候，禁止在它给初始的INVITE请求的应答中产生后续的请求（协商会话描述请求）。这就意味着基于本规范的UAS在完成初始化的事务之前，不会产生任何会话描述请求。
具体来说，根据本规范，上边的规则分别定义了两种UA之间交换信息的方法。会话描述请求是在INVITE中，应答是在2xx（可能在1xx中也存在，具有相同的值）中，或者会话描述请求在2xx中，应答在ACK中。
所有支持INVITE请求的UA都必须支持两种交换方式。会话描述协议（SDP）(RFC 2327[1])在所有的UA中都必须得到支持，并且它的用法和请求/应答的构造必须遵循[13]中定义的步骤。
在上边讲述的会话请求/应答模型中，只能适用于在包头域Content-Disposition值是”session”的包体情况。因此，有可能INVITE和ACK请求中都包含一个包体信息（比如，INVITE包含一个photo（Content-Disposition:render）并且ACK包含一个会话描述(Content-Disposition:session)）。
如果Content-Disposition头域不存在，Content-Type 是application/sdp的包体实现就等同于Content-Disposition值为“session”，其他Content-Type的情况就是实现“render”。
当INVITE请求创建以后，UAC遵循对话外请求发送的步骤进行发送（8节）。这也就是创建一个客户事务并且由这个客户事务发送请求并且处理应答。
13.2.2 处理INVITE应答
当INVITE请求被发送给客户事务层进行处理后，UAC等待INVITE的应答。如果INVITE客户事务层返回一个超时而不是收到一个应答，那么这个TU就应当像收到一个408（请求超时）应答（8.1.3节）那样进行处理。
13.2.2.1 1xx应答
有可能在收到一个或者多个终结应答之前，UAC会收到0个或者1个或者多个临时应答。INVITE的临时应答会建立“early dialogs”（早期对话）。如果一个临时应答在To头域中有一个tag子顿，并且应答的dialog ID并不是已经存在的对话的ID，那么就应当遵循12.1.2节定义的步骤创建一个对话（早期对话）。
early dialog只会在下边这个情况中需要：如果一个UAC需要在完成初始的INVITE事务之前，给对方发送一个对话内的请求的时候，就需要early dialog。在临时应答中的头域可以在当对话是early state的时候都有效（也就是说，比如一个临时应答的Allow 头域包含的方法，在对话状态是early state的时候都是有效的。）
13.2.2.2 3xx应答
一个3xx应答可能包含一个或者多个Contact头域值，这个头域值提供了被叫方可能存在的地点。UAC可以根据3xx应答的状态码（21.3节）来决定是否尝试这些新的地址。
13.2.2.3 4xx,5xx,6xx应答
在INVITE请求中，可能会收到单个非2xx终结应答。4xx，5xx，6xx应答如果包含了Contact头域，那么这个头域值指示了错误的详细信息的解释地点。后续的终结应答（只有可能在发生错误的情况下），必须被忽略掉。
所有的早期对话都会由于接收到非2xx终结应答而结束。
一旦接收到了非2xx终结应答，UAC处理核心就认为INVITE事务结束了。INVITE客户事务处理生成对这个应答的ACK（参见17节）。
13.2.2.4 2xx 应答
单个INVITE请求可能会导致多个2xx应答返回给UAC，这是因为proxy可以分支。每一个应答都是由To中的tag参数来进行区分的，并且每一个应答都代表了一个独立的对话，具备单独的对话ID。
如果在2xx应答中的对话ID和一个现存的对话匹配，那么这个对话必须切换到“confirmed”状态，并且对话的路由集合必须基于2xx的应答进行重新计算（参见12.2.1.2）。如果不匹配，那么必须创建一个新的对话，这个对话具备”confirmed”状态，参见12.1.2的步骤进行创建。
注意在对话状态中，只有路由集合是需要重新计算的。其他部分比如对话内的最大序列号（远程的和本地的）等都不需要重新计算。路由集合只是由于需要向后兼容而需要重新计算。RFC 2543并没有要求在1xx应答中携带Record-Route头域回来，只在2xx请求中要求了。我们不能更新对话状态的全部部分，因为在早期对话（early dialog）中可能会存在对话内的请求，比如更改序列号等等。UAC核心必须为每一个2xx应答，产生一个ACK请求。除了在Cseq和身份认证相关的头域之外，ACK请求的头域的创建和在对话内的请求的创建方法一样（12节）。Cseq头域的序列号部分必须和需要确认的INVITE请求一样，但是Cseq的方法部分必须是ACK。ACK必须包含和INVITE请求相同的认证信息。如果2xx包含一个媒体协商请求（基于上述的规则），ACK必须在包体中包含一个媒体协商应答。如果2xx应答的媒体协商请求不能被接收，UAC核心必须在ACK中产生一个有效的会话应答，并且立刻发送一个BYE请求。
当ACK创建以后，[附件4]中规定的步骤用来检测对方地址，端口和transport。这个请求是直接交给通讯层进行通讯的，而不是交给一个客户事务层进行发送。这是由于UAC核心直接处理ACK的重发，而不是事务层进行重发的处理。每次收到一个重发的2xx终结应答的时候都必须发送一个ACK到通讯层。
UAC核心认为INVITE事务在接收到第一个2xx应答后的64×T1秒后完成。在这个时间点后，所有处于未建立连接状态的早期对话都会被终止。一旦UAC确认INVITE事务完成了，那么缺省认为不会收到新的2xx应答了。如果，在处理了INVITE请求的全部应答之后，UAC并不希望创建这个对话，那么UAC必须通过15节描述的那样发送BYE请求来结束对话。
13.3 UAS处理
13.3.1 处理INVITE
UAS核心从事务层收到INVITE请求。首先根据8.2节定义的步骤进行处理请求，8.2节中定义的是跟对话内外无关的请求的处理。如果处理顺利完成（没有产生应答），UAS核心根据如下步骤进行额外处理：
1、 如果INVITE请求包含一个Expires头域，UAS核心就设置一个时钟计数＝这个头域值。如果时钟到了，这个邀请就过期了。如果在UAS尚未产生终结应答的时候就超时了，那么487（请求终止）应答应当产生给UAC。
2、 如果请求是一个对话中的请求，12.2.2节定义的方法无关的处理步骤将首先进行处理。这个处理可能会影响到会话；14节讲述了细节。
3、 如果请求的To头域包含了一个tag，但是对话的ID与现存的任何一个对话都不匹配，那么UAS可能是由于崩溃而重新启动的，或者是由于接收到了本应当发送给另外一个UAS的请求（或者只是由于请求填写错误）。12.2.2节提供了这种情况的健壮性处理。
从这开始的处理将假定这个INVITE是在对话外的，并且INVITE请求的目的是建立一个新的会话。INVITE请求可能包含一个会话描述，在这种情况下是希望和UAS进行会话媒体的磋商。即使INVITE请求是对话外发出的，这个INVITE参与的用户也有可能正是那个会话中的参与方。这个是由于在多方会议中，某个正在会议中的用户，被其他参与方邀请参加。如果需要鉴别这样的情况，UAS可以使用会话描述来检查是否重复邀请。比如，SDP包含了会话的ID和版本号。如果这个用户本身就是会话中的一方，并且session参数包含的会话描述没有改变，UAS可能就悄悄接受这个邀请（就是说，在不提示用户的情况下发送2xx应答）。
如果INVITE并没有包含某个会话描述，UAS就是被邀请创建一个会话，并且UAC希望UAS来提供这个会话offer（初始的会话描述信息）。UAS必须在它给UAC的第一个非失败的可靠消息中提供这个offer。在本规范中，给INVITE请求的2xx应答中就应当提供这个offer。
UAS可以提示进度、接受、转发，或者拒绝这个邀请。在这些情况下，它通过按照8.2.6节描述的步骤建立应答。
13.3.1.1 提示进度
如果UAS不能马上接受或者拒绝邀请，那么它可以提示某种形式的进度给UAC（比如提示一个回铃声等等）。这是通过一个101到199的临时应答实现的。这些临时应答建立了早期对话（early dialog）（通过8.2.6和12.1.1）。如果UAS愿意，UAS可以发送多个临时应答。每一个临时应答都必须包含相同的dialog ID。这些临时应答都并非可靠传送的。
如果UAS打算延长一点时间来响应这个INVITE请求，它需要请求一个”extension”来防止proxy取消这个事务。proxy有权利来取消超过3分钟未完成的事务。要防止这个取消，UAS必须每分钟发送一个非100临时应答，防止由于1xx临时应答的非可靠传输导致的临时应答丢失。
如果呼叫处于等待状态（比如用户设置成为呼叫等待的）或者这个呼叫正在和PSTN电话系统进行通讯（PSTN系统允许呼叫没有应答），一个INVITE事务是可以被延长处理时间的。
13.3.1.2 INVITE请求转发
如果UAS决定转发这个呼叫，就需要发出3xx的应答。300（多重选择），301（永久转移），302（临时转移）应答中应当包含一个Contact头域，这个头域包含了一个或者多个标明需要重试的URI新地址。这个应答交给INVITE服务端事务层，由服务端事务层负责应答的重发。
13.3.1.3 INVITE请求的拒绝
拒绝INVITE请求的常见情景是被叫方不想或者不能在终端系统上接收这个呼叫。486（用户忙）应当在这样的情况下返回。如果UAS知道没有其他终端系统能够响应这个呼叫，就应当返回一个600（Busy Everywhere）。不过，通常情况下UAS是不太可能知道这个情况的，因此这个应答很少用。这些应答是交给INVITE服务端的事务层进行发送的，由这个事务层来保证应答的重发机制的。如果UAS拒绝的是INVITE请求包含的媒体磋商offer，UAS应当返回一个488（Not Acceptable Here）应答。这个应答应当包含一个Warning头域来解释为何offer被拒绝。
13.3.1.4 接受INVITE请求
UAS核心产生一个2xx应答。这个应答建立一个对话，然后遵循8.2.6节和12.1.1节的描述进行处理。
响应INVITE请求的2xx应答包含Allow头域和Supported头域，并且可能包含Accept头域。包含这些头域的目的是为了让UAC不需要再次请求就能够知道UAS的特性以及UAS的扩展支持。
如果INVITE请求包含了一个媒体磋商请求offer，并且UAS还没有发送应答，2xx应答中必须包含针对这个offer的应答。如果INVITE请求没有包含这个offer，而且UAS也尚未发出offer，2xx应答必须包含这个媒体磋商offer。
当应答构建好了以后，它会交给INVITE的服务端事务层进行发送。注意，INVITE的服务端事务将会由于收到这个终结应答并且交给通讯层进行发送而销毁。因此，有必要在没有收到ACK的时候，周期性的将应答直接交给通讯层进行发送。2xx交给通讯层进行发送的时间间隔是从T1秒开始，并且每次发送后就加倍，直到到达T2秒的时间间隔（T1和T2的时间间隔定义在17节）。当收到了针对这个应答的ACK请求之后，重发就终止了。这个与使用什么通讯协议来发送这个应答是无关的。
由于2xx的重发是端到端的，并且在UAS和UAC之间存在采用UDP通讯的节点。所以要保证通过这些节点进行可靠的传送，就必须采用间隔时间重发的机制，哪怕UAS本身的通讯机制是可靠的。
如果服务端对2xx应答的重发经过了64×T1秒还没有收到ACK请求，那么dialog就认为是confirmed，但是会话却应当终止。这个是用过15节描述的方法发送BYE请求来结束。
