SIP进阶-Wireshark使用及实例分析.docVIP

SIP进阶 ----wireshark使用及实例分析 一、SIP会话概念： Call-ID：一个会话的唯一标识 CSeq：对应一个序号+请求方法，例如60 INVITE，对应的响应也需要和这个CSeq一致，每次不同的事务CSeq都需要+1，uac和uas独立计算 Branch：会话中一个事务的唯一标识，一个事务简单说就是请求+响应，按标准必须以z9hG4bK开头，一般来说所有的请求的Branch都是不一样的，除了两个特殊的：CANCEL和针对非2xx响应的ACK需要和其取消的请求有一致的Branch From tag：会话中uac标识 To tag：会话中uas标识 以call_id.pcapng中的例子讲解： 1. [Call-ID]从最初的INVITE到最后BYE结束通话，整个算同一个会话，所以这中间的其他请求（I帧请求和Session Timer更新也是包含在这个会话当中）和响应都是同一个Call-ID： 2. [Branch]初始INVITE、uas响应的100/422、uac的ACK确认是一个事务，Branch应该一样，这里ACK因为是对422（非2xx）响应的，所以Branch也一致 接下来的INVITE、uas响应的180/200是一个事务，而ACK是针对200ok（2xx）的，所以是一个单独的Branch 会话过程中的INFO和UPDATE和对应的响应都是不同的Branch，最后的BYE和200又是一次事务，整个会话结束 3. [From tagTo tag]整个会话过程中From tag和To tag都是唯一的 4. [Cseq]uac和uas的CSeq独立计算二、wireshark使用技巧 1. column设置 我认为以下的column信息是必要的 颜色规则 不同的协议，不同的服务器可以用颜色区分，按各自喜好设置 数据过滤 ip.addr/ip.src/ip.dst eth.addr/eth.src/eth.dst udp.port/udp.srcport/udp.dstport sip.Via.branch/sip.Call-ID/sip.CSeq/sip.Method rtp.p_type/rtp.ssrc Follow TCP/UDP Stream Decode As Preference--Protocols SSL H.264 payload RTP EVENT三、实例分析（信令部分） 连续两个新的事务请求（reinvite_transaction.pcap） 事务1的CSeq为107 INVITE，事务2的CSeq为108 INVITE，处理事务必须是按顺序来，事务1未处理完成，所以处理事务2的响应500 Internal Server Error，并告知Warning: 399 GS Previous INVITE is not completed or terminated，响应和请求的匹配关系需要通过 Call-ID和CSeq来判断 多个会话和事务的区分（transaction.pacpng） 数据中包含了多个会话，其中注册以及后面的重注册算同一会话，可以按条件sip.Call-ID == 859539580-5060-1@BJC.BGI.BCI.BBJ来过滤 后面的呼叫又是一次会话，按条件sip.Call-ID == 703915166-5060-2@BJC.BGI.BCI.BBJ或者sip.from.tag == 281597148|| sip.to.tag == as44a1d5bd都可以过滤，因为同一会话的from tag和to tag都是唯一的 主叫和被叫的Branch和CSeq分开独立统计的，主叫这边一共有6个不同Branch，如下黑色选中部分，被叫有2个 From tag和To tag整个会话中都是固定的，也是用于标识整个会话的 INVITE请求中只携带From tag，而To tag需要对方响应带上，sipp官方的uac.xml中初始INVITE tag=[call_number]这里的tag是自己随机生成的，而在To里面不带tag值 再看uas.xml中的响应 再看uac后续的ACK和BYE uac获取到uas的tag后使用[peer_tag_param]填入到To域中 注意：sipp使用时分号”;”不用写，[remote_port][peer_tag_param]，虽然实际数据是需要分号的。 3. IP Call失败：ICMP Port unreachable 原因1：账号未启用 原因2：被叫启用随机端口 4. 被叫接听后无反应，直到超时结束(call_establish_failed.pcapng) 原因：被叫200O