sip 事务、

1、dialog

       call-id,to-tag,from-tag

       只有收到200ok，dialog才正式创建，否则就是early，收到非回复会被取消，但是会回复ack，非200ok不会带to-tag

      就是不成功回复会不断重发,直道收到ack.

引用       http://network.51cto.com/art/201009/226948.htm

********************

SIP使用UDP传输协议来传送INVITE消息时，要使用逐 跳重传机制保证INVITE的最终传送，即用户代理UA和sip代理proxy都要保证INVITE到达下一跳，下一跳收到时会返回一个临时应答 （proxy返回100Trying，UA返回100Trying和180ringing），代理在限定时间内收不到应答即会重传INVITE。

临时应答（100~199）用于阻止逐跳INVITE重传，没有端到端的可靠传输，也就是说当被叫方返回180应答时，如果在路径中途丢失，也不会重传。

最终应答（200~699）能被保证到达它们想要去的目的地。

成 功应答（200~299）被可靠地传送到呼叫方UA，但不是使用逐跳重传机制。只有呼叫方UA能为最终成功应答发送一个ACK（直接发送到被叫方UA）， 如果成功应答在路径中途丢失或者UA发出的ACK丢失，那么被叫方会在限定时间内收不到ACK时重新发送最终应答，直到收到ACK的确认。

非成功最终应答（300~699）使用和INVITE一样的逐跳机制。被叫方用户代理将持续重传非成功应答（给前一跳），直到收到ACK为止（proxy也可以为非成功应答发送ACK）。

***********************************

引用http://www.ideawu.net/blog/archives/1001.html

*******************************

Client: 定期重复发送 INVITE 直到收到响应。
Server：收到 INVITE 后，定期重复发送响应，直到收到 ACK。
Client：收到响应后回复 ACK，认为会话已经建立。这时如果再次收到响应，回复一个 ACK。
Server：收到 ACK，认为会话已经建立。这时如果再次收到 INVITE 或者 ACK，丢弃。

里面有两个“定期发送”，其实就是超时重传的意思。当然，超时重传有最终次数限制。

程序看到上面的话，实现起来就简单了。

**********************************

register的过程，callid 和 from-tag不变好像？？

 

2、transaction

      branch

     invite的非200回复会导致ack的branch和invite相同，200的就是新的branch

    bye发送，无需超时重发

     register的每次注册都是新的branch，注册不成功的后发送的register更新branch

 

3、cseq  小于2的31次访

      在客户端register的过程,注册成功或不成功,都会增加,从1开始一直增加。如果重发过程中，重发次数达到32后会增加。

      message都是20，不变化。

      invite、ack是相同的，bye增加