1 UAC的处理
1.1 创建初始IVITE请求
初始的IVITE可以带有消息体。SIP使用提供/回答模型来进行会话协商，即提供者发送一些提议的媒体信息，而另一方可以回应选择的媒体信息（不一定在发送来的媒体中选择）。而提供/回答的交互是在对话中进行的，所以初始请求可能造成多个独立的对话。
而提供/回答模型有多个限制，如在这个规范下，提供和回答媒体信息只能存在于INVITE和回应及ACK中。
作为初始的请求，还有以下限制：(该限制在以后的扩展中已经被修改，详见draft-ietf-sipping-sip-offeranswer-04.txt)
1）初始提供媒体信息可以出现于INVITE，否则只能在2**回应中。
2）如果提供媒体信息在INVITE中，回答媒体信息可以出现在1**或2**回应中，1**中的媒体信息只是2**的拷贝。
3）如果初始提供媒体信息出现在2**回应中，则回答媒体信息必须在对2**回应的ACK中。
4)UAC不能在一个媒体提供信息正在进行处理过程中提出新的一个媒体提供信息(即不能在没收到回答媒体信息之前发送新的提供媒体信息)。
5）在一个事务之中UAS只能提供一次媒体信息，而UAC无此限制。
注：以上的限制仅作用于Content-Disposition头字段为session时（如果该字段缺失，则Content-Type字段为application/sdp时Content-Disposition头字段为session，其它时候为render）。
1.2 处理IVITE回应
2 UAS的处理
2.1 处理INVITE消息
注：此节中所说的INVITE消息均为初始化会话的INVITE。
如果INVITE中不包含会话描述，则UAS应在2**的回应中加上会话描述，转变为了媒体提供信息方。
对于INVITE的处理，UAS可以回应处理、接受、重定向或者拒绝。
2.1.1 处理
如果UAS暂时无法回应请求，则可以选择回应处理中消息，特别是回铃消息。该类消息可以发送任意多次，但不是可靠性传送（无ACK回应）。
代理服务器在处理事务时，如果一段时间内没有消息回应的话则会取消该事务，而该类消息可以用于延续事务生命（除100外）。
2.1.2 拒绝
如果INVITE提供媒体信息，而UAS无法接受的话回应488，这类消息应该包括一个Warning消息头。
2.1.3 接受
2**回应中应该包括Allow和Supported消息头，可能包括Accept消息头。这些告诉UAC在呼叫过程中允许的特性。
如果作为回答媒体信息方，之前的回应中没有回答媒体信息，则在2**中必须包含媒体信息。
如果2**没有ACK的回应，虽然建立起了对话，但也应发送BYE来结束会话。
二 会话的修改
在《理解对话》一章中说过，通过目标更新请求可以修改对话（如修改对话的远端目标）。而此节主要讲的是如何修改会话，如地址、端口、增减媒体流等。这些是通过在同一对话中发送INVITE消息来实现的，即re-INVITE（该消息可以同时修改会话和对话）。UAC和UAS都具有re-INVITE功能。
1 UAC行为
同样的提供-回应模型同样适用于re-INVITE消息。re-INVITE同样可以不带有媒体描述信息，而随后的处理（包括ACK响应）跟普通INVITE一样。
不过媒体信息提供方应该修改会话版本（如果存在的话）。
跟普通INVITE不同的是，因为是在同一对话会中发送的INVITE消息，所以是点到点的交互。即re-INVITE不会衍生（fork），Request-URI不是AOR(addressof record)，而是对话目标。
虽然UA可以同时建立多个事务，但在同一个对话中只允许一个事务存在，除非旧事务正处在completed、confirmed或者terminated状态中。
2 UAS行为
如果收到的新的INVITE消息中的CSeq序号比旧的要小，则回应500且带有Retry-After消息头。
三 会话的结束
对话内BYE的发送可以结束跟该对话相关的会话（如re-INVITE的协商失败，则关闭新和旧的对话及会话）。而BYE的发送必须在建立对话之后，而建立对话之前取消则应使用CANCEL方法。UAC可以在对话初始和确定状态时发送BYE，而UAS只能在对话确定状态时发送BYE。而且UAS在对话确定状态时，只能在收到对2**的ACK或事务超时的时候才能发送BYE。
一般来说，呼叫发起方在最终回应未到之前使用CANCEL来结束，而最后回应到了之后使用BYE方法；被叫方只适用BYE方法，当被叫摘机之后，2**将被产生所以只能等ACK到来之后才能发送BYE。
认识委托)
高效算法)
)
)
