ME60产品组播基础和定位指导-2.0.ppt

后面这两个debug对问题定位来说意义不大，可以用来理解协议的一些交互过程。 开启时需慎重，要最小范围开启，尽量不要全局都打开。 * * 组播主要的应用场景是IPTV，上述故障绝大部分都是IPTV业务的故障。 * RTSP：Real-Time Streaming Protocol RTSP实时流协议定义了如何有效地通过IP网络传送多媒体数据。它使用TCP或RTP完成数据传输。 在应用层上控制实时传输数据，提供一种可扩展的框架，使能够提供能控制的，按请求传输的实时数据，比如音频和视频。 SDP：Session Description Protocol 会话描述协议SDP，是一种文件描述协议，是由服务器端生成的描述媒体文件的编码信息以及所在的服务器的链接等信息。客户端通过它来配置播放软件的设置，如音视频解码器，接受音频视频数据的地址以及端口等等。 RTP：Real-time Transport Protocol RTP是用于Internet上针对多媒体数据流的一种传输协议。RTP被定义为在一对一或一对多的传输情况下工作，其目的是提 供时间信息和实现流同步。RTP通常使用UDP来传送数据，但RTP也可以在TCP或ATM等其他协议之上工作。RTP本身并不能为按顺序传送数据包提供可靠的传送机制，也不提供流量控制或拥塞控制，它依靠RTCP提供这些服务。 RTP适合通过点播、广播和组播传送实时流数据，RTP没有涉及资源预订和质量保证等服务。 * RTSP 有请求和响应两种命令 主要请求： SETUP：让服务器给流分配资源，启动RTSP会话。 PLAY： 启动SETUP 分配流的数据传输。 PAUSE：临时停止流，而不释放服务器资源。 TEARDOWN：释放流的资源，RTSP会话停止 点台和换台涉及两部分交互：终端和BRAS之间的组播加入和离开；终端和服务器之间的注册和解注册 * * * * * * * * * * * * * * * * * C表示rtsp客户端,S表示rtsp服务端 上述的过程是标准的RTSP流程，其中第3步和第4步是必需的 * 通过比对看，故障的抓包TCP的交互部分几乎都没有完全建立。而且存在大量终端发出的报文重传信息，证明是某个节点存在丢包。 经过逐级排查，确认是上游一台设备的单板故障，导致终端到服务器的报文存在丢包。 至于为什么只有在点台开始阶段卡一段时间，分析用户带宽比较大，丢包导致TCP协商建立比较慢，而一旦TCP能够建立，后续的报文交互都会有快速重传机制保证，大带宽可以保证终端有视频缓存，也缓解了TCP连接建立后的卡顿现象。 * * Page * 组播花屏定位（5）码流重复 这种场景下，在ME60上同时给终端发送了多份频道流量，大部分机顶盒无法处理，同时多个频道流量会相互挤占用户带宽，导致花屏 Page * 码流重复的可能原因： 一般是因为ME60没有收到机顶盒发出的leave报文，导致之前频道的流量没能立即撤销，又复制了新流量。可以在交换机和ME60上做流统确认leave报文有没有送达。Leave报文特征如下： 需要注意的是，组播leave报文的目的IP为，要离开的组播组IP封装在报文当中 一般运营商会在网络设备上部署ACL过滤策略，机顶盒用户只能访问组播服务器和组播组IP，其他报文一律deny掉，由于不是组播组IP，很容易被忽略，导致leave报文到达ME60之后被误deny掉 典型故障四：点播正常 直播异常 问题分析： 这种故障比较常见，典型的有彻底不能看和视频卡/花两种，原因多种多样。分析的重点在于从点播和直播的差异入手。点播一般是IPV4单播的TCP数据，少量丢包可以通过快速重传保证视频质量不受影响，直播一般都是组播的UDP，千分之一的丢包就能严重影响画面质量。常见的原因有如下几类：视频平台异常，无法发送组播数据；终端异常，不支持组播业务；配置问题，部分路径没有使能组播数据传输；链路带宽不足，部分数据丢失。 处理方法： 1、检查设备的组播表项是否正常建立，以进一步判定是网络侧有问题还是用户侧有问题。 2、检查路径配置，确认整个路径是否都使能了组播 3、检查终端是否支持组播业务，如不支持，做出调整 4、检查二层设备如DSLAM等是否打开了IGMP功能，如果打开了，需要关闭 5、检查链路带宽和用户带宽是否充足，一般用户至少需要2M以上的带宽 6、分别在服务器侧和ME60入口侧以及用户终端抓包确认，界定视频流在那一侧丢弃 典型故障五：直播正常 点播异常 问题分析：此类故障现网也有出现，概率相对较小。一般都是由于服务器原因引起。一般IPTV单播和组播的服务器不是同一台，单播服务器的性能要求较高，而且每台服务器可以支持的最大用户数也是有限制的，服务器之间用户数分配不均情况下，很有可能导致超