UMG产品黄埔培训系列教材问题定位信令类要点分析.pptVIP

UMG8900产品问题定位信令类 ISSUE1.0 TDM资源相关流程 ——添加端点 TDM资源相关流程 ——联网、拆网 IP资源相关流程 ——添加端点 IP资源相关流程 ——TOPO操作 IP资源相关流程 ——TOPO操作 ATM资源相关流程 ——添加端点 TC、EC资源相关流程 问题 TDM、IP、ATM资源各由哪种单板进行管理？ UMG中呼叫流程由哪种单板进行控制？ IP和TDM资源联网、拆网有什么区别？ UMG板间消息格式 Dopra消息头解读 SenderCPUID：发送消息的单板的CPU ID，通过这个字段，可以计算出发送消息的单板的框、槽、板位置。 SenderPID：发送消息的模块号，这个字段一般用于代码走读，定位问题时不需关心。 ReceiverCPUID：接收消息的单板的CPU ID，通过这个字段，可以计算出接收消息的单板的框、槽、板位置。 ReceiverPID：接收消息的模块号，这个字段一般用于代码走读，定位问题时不需关心。 Length：消息长度，定位问题时不需关心。 根据CPU ID计算单板位置的方法： 将CPU ID除以32，得到的商为框号，余数为槽号（前后插统一编号） 例如：对于CPU ID为178的单板，178÷32=5余数为18，因此该单板为5框2槽后插板。（前后插统一编号时，0~15槽为前插板，16~31槽为后插板） 内部错误码与呼叫日志 一般来说，从H248信令跟踪里看到UMG响应消息中返回500号错误时，需要跟踪UMG内部跟踪，并结合当时的呼叫日志对具体原因进行定位。 内部错误码一般在响应消息（RESP）的Message Header字段中： R5、R6版本，读取error code字段 R7以后版本，读取 内部错误码与呼叫日志 内部错误码一般对应一条呼叫日志，在呼叫日志中会详细列出产生呼损的消息名称和错误码以及端点信息 还有部分呼损是CMU单板直接判断产生的，无返回错误码，只有详细错误原因的文字描述。此类呼损日志只需要关注呼损日志中的错误原因即可。 问题 在纯SSM256环境中，CPU ID为88的单板是哪种单板？在纯SSM32环境中呢？ 某局点呼叫日志中有大量E30和E38呼损，请问两种呼损分别应该如何处理？ 附录：UMG呼叫流程举例 此问题为Server下发的Subtract消息丢失导致呼叫占用的资源超时自动回收。如果少量出现，可能因为信令承载网少量丢包导致，请继续观察，如果大量出现，说明信令承载网丢包严重，需要立刻联系数通工程师处理。 呼损处理步骤 Server下发Subtract消息丢失，信令承载网丢包严重 呼损可能原因 LONG_CONTEXT 呼损关键字 常见呼损处理 此呼损一般是由于容量不够导致。请按照以下步骤排查： 1.??使用DSP OLUSR命令查询上报日志的单板的在线用户信息，确认是否没有可用的UDP端口号可以分配了（每个IP地址，最大可分配：16381个）。 2.??使用DSP IPBRES命令查询是否还有可用带宽，如果发现配置带宽过小，可通过MOD IPIF，修改接口上的配置带宽 呼损处理步骤 没有可用的UDP端口，没有可用的承载带宽 呼损可能原因 E14呼损（RPU_ADD_RESP） 呼损关键字 常见呼损处理 此呼损一般是由于Server下发消息不符合协议导致。请直接联系Server工程师处理。 呼损处理步骤 Server下发的远端BIWF中的UDP端口号为奇数，不符合RTP协议（协议规定RTP的UDP端口号不能为奇数，UMG分配UDP端口号的原则为：4n—RTP；4n+1----RTCP；4n+2-----传真，4n+3-----预留） 呼损可能原因 E92呼损（MRPU_ADD_RESP） 呼损关键字 常见呼损处理 此呼损是由于UMG上配置错误引起，请参照以下步骤进行排查： 1.?请确认IWE1对应的实隙配置成了内部时隙?? 2. 用LST IWFE1命令检查配置是否和正确，是否有和IWF配置不一至的地方 。 呼损处理步骤 未知的iwf端点，呼叫中携带的iwf端点找不到对应的内部TID 呼损可能原因 E181呼损（MTNU_ALLOC_RSP_SLOT_REQ） 呼损关键字 常见呼损处理 如呼损少量出现，并且与E36呼损（MTNU_CONNECT_RESP)伴随出现的话，可能是因为Server下发消息时序错误或电路占用频繁导致电路同抢，无需处理。如果此呼损大量出现，请联系研发定位 呼损处理步骤 Server下发的TOPO结构导致TDM码流出现汇聚现象 呼损可能原因 E174呼损（MTNU_CONNECT_RESP） 呼损关键字 常见呼损处理 此呼损是由于UMG上硬件线缆连接或软件配