|
sip 事务的概念：一个sip 请求以及由它触发的一系列应答（包括临时应答和一个最终应答）。 sip 请求有6种（核心规范定义的，也有扩展），也叫6个方法(Method 字段标识)：INVITE, ACK, OPTIONS, BYE, CANCEL, REGISTER sip 请求的格式包括请求行(如INVITE sip:192.168.101.30 SIP/2.0)，sip 应答的格式包括状 态行(如SIP/2.0 100 Trying)；sip 应答的状态码从100到699，其中100~199是临时 (provisional)应答。 INVITE 请求是三次握手机制，其他请求都采用两次握手机制。 CANCEL 请求用于取消悬而未决的事务，我的理解是一方发出INVITE，但是另一方始终没 有做出应答，发出200OK 消息（超过了默认的振铃时长），那么UAC 会自动发出一个 CANCEL 请求，UAS 返回200OK，并且同时发出487状态码的应答，UAC 再对收到的487 消息发出ACK 确认，即最开始的INVITE 和487以及ACK 构成三次握手。 OPTIONS 请求用于询问服务器的性能情况，包括这个服务器所支持的方法（可能会有扩展 方法）和会话描述协议。 代理服务器的三种类型：保留呼叫状态代理、保留状态代理、不保留状态代理。这三种类型 的代理在处理能力和所占用资源上有差别，在代理分发中我们采用网络核心无状态，而在流 量较小的网络边界采用智能性高的保留（呼叫）状态服务器处理路由。 sip 消息编码采用文本方式（即使用字符串），相对的是二进制的编码方式，前者易于调试和 扩展，后者则有利于节省带宽。 sip 标题头： CALL-ID 字段用于标识一个特定邀请以及与这个邀请相关的所有后续事务（即标识一个会 话），比如一方发起邀请加入一个国际象棋的会话，那么INVITE 请求以及应答， BYE 请求 以及应答都共享一个CALL-ID，因为这两个事务都属于一个特定邀请。而两个用户之间可 以同时存在多个邀请（比如在下象棋的同时发起聊天的邀请），那么一个邀请中的后续事务 将通过这个邀请特有的CALL-ID 来区分，如一方发出BYE 消息来结束聊天，但是下棋仍然 进行中，那么另一方将根据BYE 消息的CALL-ID 来确定要结束的究竟是哪一个会话。 CSeq 字段是用来给同一个会话中的事务进行排序的。可以理解为，会话由CALL-ID 来标 识，会话中的事务则由CSeq 标识。除了ACK 请求和CANCEL 请求，INVITE 之后的请求 中CSeq 字段的数字是最初请求(INVITE)的CSeq 递增的结果。而ACK 和CANCEL 请求 则拥有与它所确认（取消）的请求相同的CSeq 数字部分，只是方法名不同。 (sip 标题头续) Contact 字段是被呼叫方发送200OK 消息时带上的，包含了被叫方的真实IP，这样sip 服务 器在路由第一个INVITE 请求之后就可以被卸载掉（越过），不再需要存在于信令路径中。 Recode-Route 和Route 字段是用来使sip 服务器保留在每次请求中，不被绕过。 Record-Route 字段由信令路径上的服务器添加（每经过一个信令路径上必须存在的代理， 就添加一个Record-Route 标题头），maddr 参数包含该代理的IP 地址。被叫方发出的 200OK 应答包含Record-Route 和Contact 字段（Record-Route 可能有多个），呼叫方收 到200OK 后根据这两个字段创建用于后续请求的Route 标题头（可能有多个）， 其包含的 是信令路径上的下一跳的下一跳的（hehe，有点别扭，不过意思是对的）真实IP。 To 字段总是包含被呼叫方的地址（通过sip 代理时是公用地址，点对点时是真实ip），要 注意的是区别该标题头和sip 消息请求行中的Request-URI。To 在信令路径中不会被代理 改变，然而Request-URI 包含的是信令路径中下一跳的地址，因此在路途中被每个代理改 变。 Via 字段存储所有处理请求的代理地址（包括用户代理和sip 代理），它可以用来检测路由 循环，也用于使应答消息经过请求消息来时相同的路径（方向相反）。因此， 在请求消息发 送时，via 标题头的数量是随着跳数逐渐增加的，而应答消息返回时，via 标题头的数量则 逐渐递减（每经过一跳则剥离一个有它自己地址的Via 标题头）。 (sip 标题头完) sip 消息可能含有消息体（一个或多个），通常是会话描述符，也可以是照片或其他附件。一 般情况下，消息体只对UA 有意义，因此可被端到端加密。有时候，sip 代理处于控制的原 因也需要检查被交换媒体的信息。 INVITE 事务： 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）。 CANCEL 事务： CANCEL 事务与INVITE 事务都是逐跳事务，但是处理方法不同，路径上的每一个代理收到 CANCEL 请求时，都会发送一个最终应答来响应（而不是发出临时应答），并且向下一跳发 送一个CANCEL 请求。
|
|
|
