SIP进阶-Wireshark使用及实例分析 - 图文

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 tag&To tag]整个会话过程中From tag和To tag都是唯一的 4. [Cseq]uac和uas的CSeq独立计算

二、wireshark使用技巧

1. column设置

我认为以下的column信息是必要的

2. 颜色规则

不同的协议，不同的服务器可以用颜色区分，按各自喜好设置 3. 数据过滤 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

4. Follow TCP/UDP Stream 5. Decode As

6. Preference-->Protocols SSL

H.264 payload RTP EVENT

三、实例分析（信令部分）

1. 连续两个新的事务请求（reinvite_transaction.pcap）

事务1的CSeq为107 INVITE，事务2的CSeq为108 INVITE，处理事务必须是按顺序来，事务1未处理完成，所以处理事务2的响应500 Internal Server Error，并告知Warning: 399 GS \，响应和请求的匹配关系需要通过 Call-ID和CSeq来判断

2. 多个会话和事务的区分（transaction.pacpng）

数据中包含了多个会话，其中注册以及后面的重注册算同一会话，可以按条件sip.Call-ID == \来过滤

后面的呼叫又是一次会话，按条件sip.Call-ID == \或者sip.from.tag == \都可以过滤，因为同一会话的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)

原因：被叫200OK携带的Contact地址主叫的ACK无法到达被叫

5. 网络切换gs_phone未使用新的地址（network_switch.pcapng）

6. 服务器转发200 OK C地址错误（SDP_connection_error.pcapng） sip.Call-ID == \

Frame 20641和Frame 20642回复的两次200OK中SDP携带的C地址不一样，第二次的有错误，直接将被叫的200OK携带的地址和端口写入。

7. Hold时因为BFCP Goodbye无法透传导致延迟挂断（bfcp_hold_bye.pcapng）

8. BFCP连接未建立结束通话仍发Goodbye（bfcp_not_established_bye.pcapng）

三、实例分析（媒体部分）

1. Offer/Answer m行不匹配（SDP_m_lines_not_match.pcapng） NO.2 INVITE SDP

No.16 200OK SDP

2. RTP包长度错误（rtp_audio_length_error.pcapng） 20ms*8kHz*8bit=160byte 160byte*50=64kbps

3. RTP Jitter过大（rtp_audio_jitter.pcapng）

4. RTP内容错误（rtp_audio_from_qdeng.pcapng）

5. 被叫回180就开始发RTP导致 I帧不全无法解出视频（vidyo-oneway.pcapng）

6. 视频卡顿问题分析（video_loss.pcapng） 参考指标：

1. 丢包率：大的丢包率有参考意义，但小的丢包率不能作为参考依据，因为有连续丢包的可能，需要看具体数据

2. 抖动和乱序：需要看具体帧率是否平滑稳定，按mark包（mark标记一帧结束）来统计帧率，抖动需要看视频解码的缓冲大小，比如预设了512kbit，如果码率为512kbps，也就是可以缓冲约1s钟的数据 3. 关键帧（I帧）是否完整

这段数据的回放实际是有花屏卡顿的，先来看下丢包率

数据中因为同一SSRC有两个payload，而这两个payload数据的Sequence Number又是独立计算，wireshark解析丢包率会出错，需要重新Export单独的Payload数据

虽然丢包率很小，只有14个（0.21%），再仔细看下数据

从seq.1030开始丢包，而且是连续性的丢包 过滤rtp.ssrc == 0x74a9b431，查看丢包的数据

丢包的数据恰好是I帧（IDR）的数据，从前后的264 FU Header中可以看到I帧，I帧以Mark包结束

这段数据也是I帧内的

本文来源：https://www.bwwdw.com/article/0cnx.html