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

主要原因是BAS口没有IP地址 * 1，（*，G）时间长说明从服务器引流慢 2，（S,G）时间长一般是正常现象，跟下游用户切换频道有关，（*，G）的删除是用户离开是立即删除的，（S,G）是需要等待老化，默认210秒老化，如果还没老化之前又有新用户加入频道，则（S,G）的时间将保持。 * 1,普通三层接口/子接口跑组播的话，设备收到igmp报文就是交给三层的IGMP协议模块处理，中间没有复杂的映射关系，所以直接在全局模式用display igmp group查看有内容。 2,BAS接口的话，下面是挂接的拨号业务，实际上用户要拨号，用户发的IGMP报文是承载在拨号连接的基础上，设备收到IGMP报文，要交给很多模块处理，这些工作是抽象出了UA口来完成。相关的查询命令只支持在诊断模式查询。 * 后面这两个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 * 组播花屏定位（4）丢包点和故障现象互相印证 码流到达ME60时候已经有丢包，这种情况下，应该是大范围故障，该ME60下观看该频道的用户全部花屏 ME60丢包，如果多块用户侧单板下挂用户花屏，丢包点在网络侧单板；如果单块用户侧单板下挂用户花屏，丢包点在这块单板及对应二层网络 二层丢包，这种情况下，故障范围比较集中，故障原因往往是因为交换机转发性能导致 Page * 组播花屏定位（5）码流重复 这种场景下，在ME60上同时给终端发送了多份频道流量，大部分机顶盒无法处理，同时多个频道流量会相互挤占用户带宽，导致花屏 Page * 码流重复的可能原因： 一般是因为ME60没有收到机顶盒发出的leave报文，导致之前频道的流量没能立即撤销，又复制了新流量。可以在交换机和ME60上做流统确认leave报文有没有送达。Leave报文特征如下： 需要注意的是，组播leave报文的目的IP为，要离开的组播组IP封装在报文当中 一般运营商会在网络设备上部署ACL过滤策略，机顶盒用户只能访问组播服务器和组播组IP，其他报文一律deny掉，由于不是组播组IP，很容易被忽略，导致leave报文到达ME60之后被误deny掉 典型故障四：点播正常 直播异常 问题分析： 这种故障比较常