SIP协议简介（七）之修改会话（re-INVITE）

一个成功的INVITE请求会创建一个基于两个用户之间的对话，但是在会话过程中，我们有时候也需要对当前已经存在的通话进行修改，比如这个修改可以包括修改地址或者端口、增加媒体流、删除媒体流等等。这是通过发起新的INVITE请求来完成的，并且这个新的INVITE请求是基于建立会话所相同的对话的。在一个现存对话中发出INVITE请求就是re-INVITE。
注意，单个的re-INVITE请求可以同时更改对话和会话的参数。

此时UAC行为

在初次会话发起时我们发送INVITE之后，我们往往会对媒体层参数进行协商，在re-INVITE中，这个同样需要实现。假设UAS希望增进一个媒体流，那么UAC将会创建一个新的offer包含这个媒体流，并且发送INVITE请求给他的对方。特别需要注意的是，这个会话的全描述，也就是说初次会话发起时的INVITE中是如何描述的，此时也同样进行描述，而不只是变化部分需要传送。这个支持无状态的会话处理，并且支持错误恢复机制。当然，UAC可以发送一个re-INVITE请求而不包含会话描述，在这样的情况下，就是在这个re-INVITE的第一个可靠的非失败的应答中将会包含这个会话描述offer（就是携带了协商后的媒体信息的2xx应答）。
　　re-INVITE请求中的To,From,Call-ID,Cseq,Request-URI头域应当和正常的在对话中的请求构造方法一样。需要注意的是，在相同的对话中，UAC不能在上一个INVITE请求完成前（无论是通话中的哪一方发起的INVITE）再次发起一个新的INVITE。不过，UA可以在INVITE事务正在处理的同时，处理一个普通的事务。也可以在一个普通事务正在处理的同时来初始化一个INVITE事务。如果UA接收到一个针对re-INVITE的非2xx终结应答，则会话参数不能改变，应当就像没有收到过这个re-INVITE请求一样。注意，就像在12.2.1.2节一开始讲的那样，如果非2xx终结应答是一个481（Call/Transaction Does Not Exists）,或者一个408（Request Timeout）,或者完全没有re-INVITE请求的应答（也就是说从INVITE客户事务端返回一个超时），UAC会终止这个对话。发送re-INVITE请求的规则，以及针对re-INVITE请求产生的2xx应答而产生的ACK请求的发送规则，等同于初始的INVITE请求。

此时UAS行为

UAS在发送第一个INVITE的终结应答之前，收到第二个INVITE请求，并且这个请求的Cseq序列号大于第一个INVITE请求，那么就应当给第二个INVITE请求返回一个500（服务器内部错误）应答，并且必须包含一个Retry-After头域，这个头域中应当包含一个0－10秒的随机数。
如果UAS正在处理一个INVITE请求的时候又收到了一个在同一个对话上的INVITE请求必须返回一个491（Request Pending）应答给接收到的INVITE。
　　如果UA接收到一个对现存的对话的re-INVITE请求，那么就必须检查有关会话描述(session description)的版本标志（version identifiers）,或者，如果没有版本标志，那么就需要检查会话描述的正文看看有没有变化。如果会话描述改变了，UAS必须由此调整会话参数，在调整参数的时候可能会要求用户确认。
　　会话描述的版本可以用来提供给会议的新近加入者，增加或者删除媒体，或者由单点会议更改成为多方会议。如果新的会话描述是不能被UA接受的，UAS可以用返回一个488（Not Acceptable Here）来拒绝这个re-INVITE请求。这个响应应当包含一个Warning头域（用来提供给请求方，提供这个拒绝的原因）。如果UAS产生一个2xx应答，但是没有收到ACK,它应当产生一个BYE来结束这个对话。
　　UAS可以不产生180（Ringing）应答给re-INVITE，因为UAC一般不展示这个信息给用户。同样的，UAS可以增加一个Alert-Info头域或者一个由Content-Disposition“alert”的消息体来应答给re-INVITE来让UAC展示这个信息。
在使用时注意re-INVITE和初次会话发起时的INVITE形式保持一致
在真正的工程应用中，如果从完整性考虑，我们设计的出发点应该是保持尽可能全面地考虑到在会话过程中可能会遇到的情况，包括诸多不期望时间的发生，但是另外一个角度，我们也可以根据自己项目的需求，来砍掉一部分的功能，比如在一个使用场景只需要建立会话即可的项目中，我们大可不用考虑这种修改会话参数的情况；同时对于一些状态值得应答，也不必完全涉及到所有的应答码，结合自己的项目需要进行设计就可以了。这些协议是死的，但是如何使用是活的，大可不必过分复杂化，增加了项目开发的难度和时间。