SIP进阶Wireshark使用及实例分析报告文档格式.docx

SIP进阶Wireshark使用及实例分析报告文档格式.docx

《SIP进阶Wireshark使用及实例分析报告文档格式.docx》由会员分享，可在线阅读，更多相关《SIP进阶Wireshark使用及实例分析报告文档格式.docx（19页珍藏版）》请在冰点文库上搜索。

CANCEL和针对非2xx响应的ACK需要和其取消的请求有一致的Branch

Fromtag：

会话中uac标识

Totag：

会话中uas标识

以call_id.pcapng中的例子讲解：

1.[Call-ID]从最初的INVITE到最后BYE结束通话，整个算同一个会话，所以这中间的其他请求（I帧请求和SessionTimer更新也是包含在这个会话当中）和响应都是同一个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.[Fromtag&

Totag]整个会话过程中Fromtag和Totag都是唯一的

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.FollowTCP/UDPStream

5.DecodeAs

6.Preference-->

Protocols

SSL

H.264payload

RTPEVENT

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

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

事务1的CSeq为107INVITE，事务2的CSeq为108INVITE，处理事务必须是按顺序来，事务1未处理完成，所以处理事务2的响应500InternalServerError，并告知Warning:

399GS"

PreviousINVITEisnotcompletedorterminated"

，响应和请求的匹配关系需要通过

Call-ID和CSeq来判断

2.多个会话和事务的区分（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"

都可以过滤，因为同一会话的fromtag和totag都是唯一的

主叫和被叫的Branch和CSeq分开独立统计的，主叫这边一共有6个不同Branch，如下黑色选中部分，被叫有2个

Fromtag和Totag整个会话中都是固定的，也是用于标识整个会话的

INVITE请求中只携带Fromtag，而Totag需要对方响应带上，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.IPCall失败：

ICMPPortunreachable

原因1：

账号未启用

原因2：

被叫启用随机端口

4.被叫接听后无反应，直到超时结束（call_establish_failed.pcapng）

原因：

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

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

6.服务器转发200OKC地址错误（SDP_connection_error.pcapng）

sip.Call-ID=="

1571901531-14451-31@BJC.BGI.BCI.IJ"

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

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

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

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

1.Offer/Answerm行不匹配（SDP_m_lines_not_match.pcapng）

NO.2INVITESDP

No.16200OKSDP

2.RTP包长度错误（rtp_audio_length_error.pcapng）

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

3.RTPJitter过大（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数据的SequenceNumber又是独立计算，wireshark解析丢包率会出错，需要重新Export单独的Payload数据

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

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

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

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

这段数据也是I帧内的