2024年4月24日发(作者：)

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_中的例子讲解：

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. 数据过滤

//

//

/t/t

/-ID//

rtp.p_type/

4. Follow TCP/UDP Stream

5. Decode As

6. Preference-->Protocols

SSL

H.264 payload

RTP EVENT

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

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

事务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来判断

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

数据中包含了多个会话，其中注册以及后面的重注册算同一会话，可以按条件

-ID == "859539580-5060-1@"来过滤

后面的呼叫又是一次会话，按条件

"703915166-5060-2@"或者

-ID ==

== "281597148"||

== "as44a1d5bd"都可以过滤，因为同一会话的from tag和to tag都是唯一

的

主叫和被叫的Branch和CSeq分开独立统计的，主叫这边一共有6个不同Branch，

如下黑色选中部分，被叫有2个

From tag和To tag整个会话中都是固定的，也是用于标识整个会话的

INVITE请求中只携带From tag，而To tag需要对方响应带上，sipp官方的

中初始INVITE

tag=[call_number]这里的tag是自己随机生成的，而在To里面不带tag值

再看中的响应

再看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_)

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

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

6. 服务器转发200 OK C地址错误（SDP_connection_）

-ID == "1571901531-14451-31@"

Frame 20641和Frame 20642回复的两次200OK中SDP携带的C地址不一样，第

二次的有错误，直接将被叫的200OK携带的地址和端口写入。

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

8. BFCP连接未建立结束通话仍发Goodbye

（bfcp_not_established_）

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

1. Offer/Answer m行不匹配（SDP_m_lines_not_）

NO.2 INVITE SDP

No.16 200OK SDP

2. RTP包长度错误（rtp_audio_length_）

20ms*8kHz*8bit=160byte 160byte*50=64kbps

3. RTP Jitter过大（rtp_audio_）

4. RTP内容错误（rtp_audio_from_）

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

6. 视频卡顿问题分析（video_）

参考指标：

1. 丢包率：大的丢包率有参考意义，但小的丢包率不能作为参考依据，因为有连续丢

包的可能，需要看具体数据

2. 抖动和乱序：需要看具体帧率是否平滑稳定，按mark包（mark标记一帧结束）

来统计帧率，抖动需要看视频解码的缓冲大小，比如预设了512kbit，如果码率为512kbps，

也就是可以缓冲约1s钟的数据

3. 关键帧（I帧）是否完整

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

数据中因为同一SSRC有两个payload，而这两个payload数据的Sequence Number

又是独立计算，wireshark解析丢包率会出错，需要重新Export单独的Payload数据

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

从seq.1030开始丢包，而且是连续性的丢包

过滤 == 0x74a9b431，查看丢包的数据

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

帧以Mark包结束

这段数据也是I帧内的