接SIP协议规范RFC3261中文分享-24，继续UAS Processing。

13.3 UAS Processing

13.3.1 Processing of the INVITE

UAS core将会从事务层收到INVITE请求。它首先执行的是请求处理流程，参考Section 8.2，这个流程适用于内部请求和dialog的外部请求。

假设那些流程完成执行步骤没有生成响应，此UAS core还会执行其他的步骤：

1. 如果此请求是一个INVITE请求，这个INVITE请求包含一个Expires header的话，UAS core设置一个定时器，并且定时器时长表示了header的值。当触发定时器以后，这个请求会被认为超时。如果这个请求超时是在UAS已生成最终响应之前，487 (Request Terminated)响应应该被生成。

2. 如果此请求是一个mid-dialog 请求的话，需要根据各自method独立处理流程描述的来处理，具体的处理流程首先采用 Section 12.2.2。它也可能修改会话，Section 14 提供了更多细节。

3. 如果请求在To header中有一个tag标签，但是dialog identifier不能匹配任何已存dialogs，UAS 可能已经崩溃，已重启，或者不同的UAS可能收到了请求（可能是失败的UAS）。在这种情况下，Section 12.2.2 提供了一个指南确保获得一个稳定的处理流程。

从这里开始的流程和后续的流程假设此INVITE是一个dialog外部的请求，并且其目的是为了创建一个新会话。

此INVITE可能包含一个会话描述，这种情况是UAS出现在一个这个会话的offer消息中。这是非常可能的，用户已经是那个会话中的一个参与方，甚至于此INVITE是一个dialog外部的INVITE。这种情况可以发生在多播会议，用户被其他参与方邀请加入会议中。 如果需要的话，此UAS可以在会话描述中使用 identifiers来检测重复身份。

例如，SDP 包含一个会话ID和在origin (o)行的版本号。如果此用户已经是会话中的一员，并且包含了在会话描述的会话参数没有任何改变，UAS 可以接受这个INVITE请求（发送一个2xx响应，无需提示此用户）。

如果此INVITE没有包含任何的会话描述，UAS最终被邀请加入一个会话中，并且UAC已经被要求由UAS提供会话offer消息。此INVITE必须在它的第一个非失败可靠性消息中提供此offer返回到此UAC端。在此规范中，就是一个对此INVITE的2xx响应消息。

UAS能够指示处理状态，接受，转发和拒绝此邀请的能力。在这些所有场景中，UAS通过流程来构建一个响应消息，流程的处理方式参考Section 8.2.6。

13.3.1.1 Progress

如果UAS不能马上应答请求的话，它可以选择对UAC指示一些呼叫状态（例如，指示电话正在振铃）。这个指示状态通过发送一些临时响应来实现，临时响应取值介于101和199之间。这些临时响应创建早期的dialogs，因此需要遵从Section 12.1.1 章节的内容，和 Section 8.2.6章节的内容。一个UAS只要它愿意，它可以发送多个临时响应。多个临时响应中的每个临时响应必须表示同一dialog ID。 不过，这些响应不是可靠传输实现的。

如果UAS期望一个延迟时间来应答这个INVITE，它将需要请求一个拓展时间防止代理取消这个事务。 当在一个事务中，响应之间的时间间隔超过三分钟，代理有取消事务的选择权。为了防止代理权限事务，UAS必须每分钟发送一个非100的临时响应来应对丢失临时响应的可能性。

当用户被执行了呼叫停靠或者配合PSTN网络工作时（例如没有应答呼叫，进入了IVR流程），INVITE事务可以在这个拓展的时间段继续执行下去。

13.3.1.2 The INVITE is Redirected

如果UAS决定转发此呼叫时，需要发送一个3xx响应。一个300 (Multiple Choices)，301 (Moved Permanently)或302 (Moved Temporarily)应该包含一个Contact头，这个contact头包含一个或者多个新地址的URLs，这些新地址将会在

转发呼叫中使用。这个响应被传输到INVITE服务器事务层，事务层处理它的重传。

13.3.1.3 The INVITE is Rejected

经常看到的场景是系统呼叫方不能启动或不能再进行额外的呼叫。在这种状态下，应该符合一个486 (Busy Here)。如果UAS知道，无任何系统端资源来接受呼叫时，一个600 (Busy Everywhere)响应应该被返回。但是，好像UAS知道这种情况，因此通常不会使用响应。响应被传递到INVITE 服务器端事务层，事务层将处理重传流程。

UAS 应该返回一个488 (Not Acceptable Here)响应，实际上，UAS通过一个拒绝的offer来实现，这个offer包含在INVITE中。这样的响应应该包括一个告警头域值，这个值解释offer被拒绝的原因。

13.3.1.4 The INVITE is Accepted

UAS core产生一个2xx响应消息。这个响应创建了一个dialog，因此按照Section 12.1.1 的处理流程来执行，另外还有Section 8.2.6流程。

对INVITE的一个2xx响应应该包含Allow头和Supported头，并且可能包含Accept 头。包括这些头的话，无需侦测UAS功能，在呼叫期间允许UAC决定UAS所提供的功能和其拓展。

如果INVITE请求包含一个offer消息，并且UAS还没有发送answer消息的话， 2xx响应必须包含一个answer消息。如果此INVITE没有包含offer消息的话，如果UAS还没有发送offer的话，2xx 必须包含一个offer消息。

一旦响应构建后，响应会被传递到INVITE 服务器事务层。注意，INVITE 服务器事务收到最终响应，传递到传输层后，INVITE服务器事务将被销毁。因此，直到ACK抵达之前，事务层定期直接发送响应消息到传输层是非常必要的。2xx响应被传递到传输层，同时携带一个定时器，定时器从T1秒开始计算，然后针对每个重传定时器时间翻倍计算，直到T1定时器时间设置到了T2秒。（T1和T2定义在Section 17）。当收到针对此响应的ACK请求后，响应重传退出。这里，如何退出不取决于发送响应所使用的传输协议。

因为2xx通过端对端被重传，因此，在UAS和UAC之间可能有多个hops，这些hops支持的UDP。为了保证经过这些hops的可靠传输，尽管在UAS的传输是可靠性，响应消息也需要定期重传。

如果在64*T1秒内，服务器端没有收到ACK，服务器重发这个2xx响应，此dialog是被确认的，但是，此会话应该结束。结束会话使用BYE请求消息，具体描述在Section 15章节。