sip re-invite 详解

因为2字头应答在端到端之间重发，UAS和UAC之间的转发可能通过UDP。为了
保证转发的可靠性，就算UAS使用可靠的传输层，也要周期性的重发应答。

如果服务端重发2字头应答64*T1秒还未收到一个ACK，对话状态转换为确认，但
应当终止会话。使用BYE请求来终止会话.

1. 修改一个已建立的会话

一个成功的INVITE请求(见13章)在两个用户代理间既建立了对话，又使用
“提议/回答”模型建立了会话。12章解释了如何使用一个目的地更新请求修改
一个已有对话(例如，改变对话的对方目的地URI)。本章描述如何修改一个会话。
这些修改涉及到改变地址或端口号，增加一个媒体流，删除一个媒体流，等等。
这些修改通过在建立会话的同一个对话内发送一个新的INVITE来实现。在已有的
对话中发送一个INVITE被称为re-INVITE.

注意，单个re-INVITE可以同时修改对话及会话参数。

主叫方和被叫方都可以修改已有会话。

UA对媒体流失败的检测是一个本地策略问题，但是不建议自动生成re-INVITE或
BYE来避免网络阻塞引起的失败问题。无论何种情况，如果要自动发送消息，都
应当有随机的间隔。

注意，上一段是针对自动生成re-INVITE和BYE。如果遇到媒体流失败，用户
挂机，UA应当正常地发送BYE请求。

UAC机理

适用于INVITE会话描述的“提议/回答”模型(13.2.1节)同样适用于re-INVITE。
所以，UAC如果想增加一个媒体流，就要建立一个包含该媒体的新的提议，放入
INVITE请求并发送给对方。要注意，发送的不是会话描述的更改部分，而是
整个会话描述。这是为了支持不保持会话状态的各种构件的处理，也是为了
支持容错和恢复的能力。当然，UAC也可以发送不带会话描述的re-INVITE，
这种情况下，对re-INVITE的第一个可靠应答将包含提议(本协议是指2字头应答)。

如果会话描述格式能够区分版本号，提议应当表明会话描述的版本是否改变。

re-INVITE的To，From，Call-ID，CSeq，和Request-URI的设定遵照构建对话内
请求相同规则，见12章。

对于re-INVITE，UAC可以选择不加入一个Alert-Info域或Content-Disposition域
为“alert"”的消息体，因为UAS通常不会基于收到的re-INVITE而警示用户。

INVITE可以分支，而re-INVITE则不能分支。因此只有一个最终应答。re-INVITE
永不分支的原因在于，其Request-URI可以确定已建立对话的目的地是一个UA实体，
而不是用户的一个地址记录。

注意，在同一个对话中，当一个INVITE事务还在处理中(不论方向如何)，UAC决不
能新建一个INVITE 事务。

1. 如果有一个正在处理的INVITE客户端事务，TU在新建INVITE事务前必须
等待，直到事务完成或终止。

2. 如果有一个正在处理的INVITE服务端事务，TU在新建INVITE事务前必须
等待，直到事务完成或终止。

但是，UA可以在处理INVITE事务时新建普通的事务，也可以在处理普通事务时
新建INVITE事务。

如果UA收到re-INVITE的非2字头的最终应答，会话参数必须保持不变，就象没有
发出re-INVITE。注意如同12.2.1.2节中规定，如果非2字头的最终应答是481(对
话/事务不存在)，或408(请求超时)，或根本没收到re-INVITE的应答(即INVITE
客户端事务返回超时)，UAC将终止对话。

如果UAC收到re-INVITE的491应答，就应当启动一个值为T的定时器。T值选择
如下：

1. 如果UAC是对话ID中Call-ID的所有者(即该UAC产生的该值)，T是在2.1
到4秒间随机数，步长为10ms.

2. 如果UAC不是对话ID中Call-ID的所有者，T是在0到2秒间的随机数，步长
为10ms.

当定时器到点，如果UAC仍然需要改变会话，就应当再次尝试发送re-INVITE，
例如，如果对话已经被BYE挂断，就不会重发re-INVITE.

重发re-INVITE,以及产生对2字头应答的确认ACK，都和初始INVITE中的处理一样
(13.2.1节)。

14.2 UAS机理

13.3.1节描述了区分re-INVITE和初始INVITE的步骤，以及如何处理re-INVITE.

同一个对话中，如果UAS在发出第一个INVITE的最终应答前收到第二个INVITE，且
第二个CSeq序列号较小，则UAS必须给第二个INVITE返回500(服务器内部错误)，
并且必须包含Retry-After域，值为0-10秒的随机数。

如果UAS发出的INVITE正在被处理时，收到一个同一对话的INVITE，则必须对该
INVITE返回491(请求待定)应答。

如果UA收到一个已有对话的re-INVITE，必须检查会话描述中的任何版本标识符，
如果没有版本标识符，则检查会话描述内容，看是否有变化。如果会话描述有
变化，UAS必须相应调整会话参数，这可能需要用户的确认。

会话描述的版本可以用来提供一系列能力，如介绍新的会议参与者，增加或
删除媒体，和将点到点会话变成多点会议。

如果不能接受新的会话描述，UAS可以拒绝re-INVITE，并返回488(这儿不接受)
应答。应答；应当包含一个Warning域。

如果UAS产生了一个2字头应答，但没有收到ACK，UAS应当产生一个BYE来终止对话。

对于re-INVITE，UAS可以选择不产生180(响铃),因为UAC通常不将该信息告诉用户。
同样的理由，UAS可以选择不使用Alert-Info域或Content-Disposition为“alert”
的消息体。

如果UAS在2字头应答中提供提议(因为INVITE没包含提议)，就应当象建立新的呼叫
一样构建提议，更新已有会话的提议必须符合相同的约束(如果是SDP，就如[13]
所述)。也就是说，提议应当包含UA所愿支持的所有媒体格式和类型。UAS必须保
证会话描述包含之前的会话描述中被对方所支持的媒体格式和类型。这是为了避免
对方拒绝会话描述。当然，如果这不被UAC接受，UAC应当生成携带合法会话描述的
回答，然后发出BYE来终止会话。