一旦INVITE传递到INVITE的客户端事务，UAC将会等待此INVITE的响应。如果此INVITE的客户端事务返回一个超时而不是一个响应，此响应是TU如果已收到了一个408（Request Timeout）响应的话，它充当一个响应，此响应就像在Section 8.1.3讨论的一样。

　　在收到一个或者多个最终响应之前，可能抵达零，一个或者多个临时响应。对一个INVITE请求来说，临时响应能够创建“early dialogs”。如果在临时响应的TO中有一个tag标签的话，并且如果此响应的dialog ID 不能匹配已存在的dialog，将创建一个新的dialog，创建流程在Section 12.1.2中定义。

　　仅需要early dialog的状态是，初始INVITE事务完成之前，如果UAC需要在其dialog中对其peer发送一个请求，UAC才需要early dialog。只要此dialog在早期状态的话，临时响应中出现header头域是可以接受的，例如，在临时响应中的Allow 头包含methods，当处理状态在早期状态时，这些methods可以用在此dialog中。

　　一个3xx响应可以包含一个或者多个Contact头，这些contact头提供新的地址，这些地址是被呼叫方可达地址。根据3xx状态码的不同（Section 21.3），UAC可能选择去尝试这些不同的新地址。

　　针对INVITE消息，可能收到一个单个非-2xx最终响应。4xx，5xx和6xx响应中可能包含一个Contact头域值，此值表示一个位置，此处发现关于错误的其他信息。后续最终响应（在错误条件下仅抵达的）必须被忽略。

　　在收到非-2xx最终响应的回复以后，所有早期dialogs将会结束。

　　已经收到非-2xx最终响应后，UAC core认为INVITE事务已完成。此INVITE客户端事务处理会针对此响应来处理ACKs生成（see Section 17）。

　　因为分叉代理的原因，一个单INVITE请求的多个2xx响应会抵达UAC端。每个响应通过To头中的标签参数加以区别，每个响应代表一个不同的dialog，这些dialog具有不同的dialog identifier身份确认消息。

　　如果在2xx响应中断dialog identifier匹配了当前存在的dialog的dialog identifier，此dialog必须被迁移到"confirmed" 确认状态，并且，在此dialog的路由组必须被重新计算，其算法基于2xx响应，按照的Section 12.2.1.2流程来处理。否则，在"confirmed" 状态中的一个新dialog必须重构，构建流程按照Section 12.1.2处理。

　　注意，只有一小部分的状态需要重新计算，这部分状态是route set。在此dialog中其他状态部分例如最高序列号的部分（远端或者本地的）无需重新计算。route set 部分的计算仅为了支持向后兼容。RFC 2543 没有在1xx响应中强制执行Record-Route头的检查，只有在2xx支持。，因为，可能在早期的dialog中，mid-dialog请求已经被发送出去，并且可能执行了其他的修改，例如修改了序列号，因此，我们不能更新整个dialog的状态。

　　UAC core 必须对每个从事务层收到的2xx生成一个ACK请求。除了认证需要的CSeq和头域，Ack请求的头域构建方式和任何在dialog中的一样（Section 12)。CSeq 头的序列号必须和INVITE确认的一样，但是CSeq method 必须是ACK。就像INVITE一样，ACK必须包含同样的安全信息。如果2xx包含一个offer消息（基于上面的规则），此ACK必须在其消息体中传递一个answer消息。如果在2xx响应中的offer没有被接受，UAC core必须在ACK中生成一个有效的answer消息，并且马上发送一个BYE。

　　一旦ACK构建好以后，使用[4]中的处理流程来决定目的地地址，端口和传输方式。但是，为了传输流程，请求将会直接传递到传输层，而不是传输到客户事务层。这是因为UAC core处理ACK的重传，不是事务层处理。每次ACK抵达触发2xx最终响应的重新传输ACK必须被传递到客户传输层。

　　第一个2xx响应收到以后，UAC core认为INVITE 事务完成了64*T1秒的定时。在这一时间点，所有没有切换到已创建状态的早期dialog都将结束。一旦认为INVITE 事务被UAC core完成， 则无更多新的2xx响应会到达。

　　如果，对INVITE确认了任何2xx响应，UAC core不想继续那个dialog，然后，UAC必须发送一个BYE请求结束此dialog，处理方式在Section 15讨论。