海信手机WAP方式播放手机视频被rst问题案例分析.ppt

* * * * * * * * * * * * * * * * * * 专业 进取 协作 共享 增值业务质量测试案例分析 海信手机WAP方式播放手机视频被rst问题分析 中国移动集团湖北有限公司 2010年11月 海信手机WAP方式无法播放手机视频 1.使用该款手机在湖北武汉地区测试手机视频业务，客户端方式可以成功播放，WAP方式不能成功播放。 其他手机没有类似问题。 现 象 网络：诺西WAP网关socket防火墙CHECKPOINT IP2250 地点：湖北武汉 终端：海信HS-N56_TD/1.0 ThreadX/4.0 MOCOR/W09B Release/05.25.2010 Browser/NF3.5 Profile/MIDP-2.0 Configuration/CLDC-1.1 流媒体播放器UA ： HSVPlayer/1.0 流媒体播放方式： WAP方式 环 境 2.湖北公司借到该测试手机进行全面测试，发现在连续的十余次重试后WAP方式播放可以成功，但是成功率很低。 现 象 终端侧抓包发现异常的RST信令 终端侧抓包 从右侧信令中可以看出，在开始RSTP协议SETUP协商之前，流程全部正常，在终端发送RSTP协议SETUP 请求后，直接收到RST响应，关闭了SOCKET连接，业务被立即中止。 联系上海视频基地进行日志分析 联系上海基地做对应的日志分析，基地表示从日志中看到：手机视频服务器收到并回复了RTSP协议的OPTIONS方法，但是没有收到紧接着的SETUP方法，也没有发出RST消息，在等待一定时间后，终端中止了连接。 为了证实上海基地的日志分析，并排除从湖北到上海基地的网络故障，湖北公司从SOCKET防火墙公网接口抓包，证实防火墙的确没有收到SP侧转发的SETUP方法，也没有收到RST消息，这说明RST是我们的网络发给终端的。 逐段排查，定位发出RST消息的设备 RNC/BSC SGSN GGSN NodeB/BTS WAP网关 视频基地 海信终端 分别组织在Gb、Gn、Gi接口上抓包，均能发现该RST消息。 在诺西WAP的socket防火墙内网外网对比抓包，确认了该RST消息是诺西WAP的socket防火墙CHECKPOINT IP2250向终端发出的，确认是防火墙阻止了该请求。 分析防火墙日志，发现DROP记录 原 因 定 位 测试并分析防火墙日志，发现用户请求失败时防火墙产生右图所示的日志：该日志中可以查出drop包的原因是“Tried to open a known service port, protocol :udp, port_svc: 6972”。字面意义是用户尝试打开已定义的服务端口。 询问诺西厂家，厂家给出的答复是用户访问了不在防火墙socket白名单中的端口导致被拒绝。 对手机视频使用的流媒体协议进行研究，发现厂家的说法不合理 流媒体的播放过程实际上使用了实时传输协议RTP、实时传输控制协议RTCP和实时流协议RTSP三种流媒体协议（右中图）。 RTSP是一个多媒体播放控制协议，提供了对流媒体的暂停、快进等控制功能，而它本身并不传输媒体数据。 当客户端发起URL请求时，与服务器建立RTSP连接（基于TCP的可靠连接），并发起RTSP会话，包括OPTIONS、DESCRIBE、SETUP、PLAY等一系列请求。其中SETUP请求用于建立视频和音频的RTP及RTCP连接，协商客户和服务器使用的端口和地址，如右上图所示，协商成功后客户端端口是59532-59533，服务器端端口是970-6971。 协商成功后，服务器根据协商好的端口发起RTCP和RTP连接（基于UDP的连接），并通过其传送音视频数据。 测试信令中可以很明显看到被防火墙DROP的端口是客户端的端口（右下图）。 流媒体播放研究 SETUP rtsp://127.0.0.1/1.mpg/track1 RTSP/1.0CSeq: 3Transport: RTP/AVP;unicast;client_port=59532-59533 RTSP/1.0 200 OKCSeq: 3Transport:RTP/AVP;unicast;destination=127.0.0.1;source=127.0.0.1;client_port=59532-59533;server_port=6970-6971 对厂家的说法产生怀疑以后，对信令包进行深入分析，发现异常现象 请求及响应报文 由于在测试中发现，在很多次重试后WAP方式播放可以成功。因此，用该终端对手机视频业务进行长时间反复测试并抓包对比分析，