排除TC终端的呼叫失败故障注册对Cisco CallManager

下载选项

  • PDF     (828.7 KB)
    在各种设备上使用 Adobe Reader 查看
  • ePub     (691.1 KB)
    在 iPhone、iPad、Android、Sony Reader 或 Windows Phone 上使用各种应用查看
  • Mobi (Kindle)     (611.3 KB)
    在 Kindle 设备上查看或在多个设备上使用 Kindle 应用查看
已更新: 2015 年 7 月 23 日
文档 ID:119207

非歧视性语言

此产品的文档集力求使用非歧视性语言。在本文档集中，非歧视性语言是指不隐含针对年龄、残障、性别、种族身份、族群身份、性取向、社会经济地位和交叉性的歧视的语言。由于产品软件的用户界面中使用的硬编码语言、基于 RFP 文档使用的语言或引用的第三方产品使用的语言，文档中可能无法确保完全使用非歧视性语言。 深入了解思科如何使用包容性语言。

关于此翻译

思科采用人工翻译与机器翻译相结合的方式将此文档翻译成不同语言，希望全球的用户都能通过各自的语言得到支持性的内容。 请注意：即使是最好的机器翻译，其准确度也不及专业翻译人员的水平。 Cisco Systems, Inc. 对于翻译的准确性不承担任何责任，并建议您总是参考英文原始文档（已提供链接）。

简介

本文解释某些普通的呼叫失败问题面对Tandberg注册的编码(TC)终端对Cisco CallManager和建议的解决方案。

Prerequisites

Requirements

Cisco 建议您了解以下主题：

如何获取H.323调试日志

Note:保证巩固插槽主机(SSH)会话输出是获取的。

  1. SSH到编码CLI里和输入这些命令：
    • 日志ctx H.323Packet调试9
    • 日志输出在(这输出所有日志到SSH会话终端会议屏幕。)
  2. 开始呼叫并且再现问题。
  3. 输入日志输出并且记录ctx H.323Packet调试命令。

如何获取会话初始化协议(SIP)调试日志

Note:保证SSH会话输出是获取的。

  1. SSH到编码CLI里和输入这些命令：
    • 日志ctx SIPPacket调试9
    • 日志输出在(这输出所有日志到SSH会话终端会议屏幕。)
  2. 开始呼叫并且再现问题。
  3. 输入日志输出并且记录ctx SIPPacket调试命令。

如何从TC终端收集信息包获取终端日志

  1. 从Web GUI请选择诊断>日志文件和enable (event)与完整的信息包捕获的被扩大的记录。
  2. 开始呼叫并且再现问题。注意信息包获取可以只是启用的在3分钟。
  3. 从Web GUI请选择诊断>日志文件并且下载完全日志档案和信息包获取。

其他需的信息

  • 完成呼叫流用包括的所有设备
  • 呼叫和呼叫号
  • 问题的日期和时间发生了

Components Used

This document is not restricted to specific software and hardware versions.

The information in this document was created from the devices in a specific lab environment.All of the devices used in this document started with a cleared (default) configuration.If your network is live, make sure that you understand the potential impact of any command.

问题：由于的呼叫失败呼叫在呼叫管理器的搜索空间(CSS) /Partition问题

在两个终端之间的呼叫注册对Cisco Unified通信管理器(CUCM)也许发生故障由于在CUCM的一个CSS/Partition问题。

获取呼叫的终端SIP日志。此"404没被找到的”消息出现在来自CUCM的终端SIP日志：

 |SIP/2.0 404 Not Found
 Via: SIP/2.0/TCP 172.16.2.55:5060;branch=z9hG4bK26e12a6fbed832;received=172.16.2.55
 Call-ID: 77fec00-564180a1-1eec8b-370210ac@172.16.2.55
 CSeq: 101 INVITE
 From: <sip:1502@172.16.2.55>;tag=158127671
 To: <sip:4659@172.16.2.53>;tag=654ba920aeef9e74
 User-Agent: Cisco-CUCM10.5
 Content-Length: 0

解决方案

完成这些步骤为了检查呼叫的终端的CSS和被呼叫的终端的分区。保证呼叫的终端的CSS有被呼叫的终端的分区。

您能分配CSS在设备和在终端的线路级：

  1. 选择Device > Phone，选择终端并且点击线路，并且检查呼叫搜索空间(CSS)在线路级。在本例中， CSS没有被配置在线路级。然而，如果有CSS在目录号级别， CSSs之一必须有被叫号码的partiton ：

  2. 检查在电话级别上asigned的CSS。选择Device > Phone并且选择正在考虑中呼叫的终端：

  3. 检查被叫号码的分区。选择Device > Phone，选择被调用的设备，点击线路，并且检查路由Partion ：

  4. 在您验证Partiton和CSS在两个终端后，请检查呼叫设备的CSS是否有被调用的设备的分区：

    否则，这能是"404没被找到的”错误的原因。

问题：SIP呼叫丢弃在15分钟之后(或在任何特定时间之后)

通常在特定时间时间间隔的呼叫丢包是由在防火墙或TCP超时造成的配置的SIP计时器，路由器，等等。

解决方案

当在正确地15分钟的呼叫断开，被看到的常见问题是在网络配置的TCP超时(防火墙，路由器)时是较少比SIP会话到期计时器。默认情况下在呼叫管理器， SIP会话到期计时器设置为1800秒。

为了验证此，请选择Cisco Unified CM管理>System >服务参数> Cisco Call Manager Service>寻找- SIP会话到期计时器。

所有终端注册对CUCM使用此计时器。当终端在与另一个远程终点时的呼叫，其中一个当事人必须刷新会话并且发送再邀请或更新。这刷新必须被发送，在会话的一半到期计时器前(1800/2 = 900秒= 15minutes)。如果没有收到的刷新消息，呼叫是断开的。

检查在首字母的会话计时器邀请。应该接受刷新(请邀请/更新)，在这次到期前：

|INVITE sip:+1234@10.108.64.22:5060;transport=tcp SIP/2.0
 Via: SIP/2.0/TCP 10.110.68.38:5060;branch=z9hG4bK00eed555
 Call-ID: dbfe0000-4491f669-9fd00-16406c0a@10.108.64.22
 CSeq: 1 INVITE
 Contact: <sip:30048@example.com;gr=urn:uuid:f7a3a098-ead8-5512-85ef-26ae544d6547
   >;isfocus;x-cisco-tip
 From: "TP Conference 30048 - Test" <sip:30048@10.110.68.6>;tag=86251172C3B60000
 To: <sip:1234@10.108.64.22>;tag=25983910~226bf657-9d6c-4ad9-98a2-cf842fe1d733-52629917
 Max-Forwards: 70
 Route: <sip:proxy-call-id=53a00ced-68e1-4ecd-872b-1edbb9abc75b
 @10.110.68.6:5060;transport=tcp;lr>
 Route: <sip:proxy-call-id=53a00ced-68e1-4ecd-872b-1edbb9abc75b
 @10.110.68.6:5060;transport=tcp;lr>
 Allow: INVITE,ACK,CANCEL,OPTIONS,UPDATE,INFO,SUBSCRIBE,NOTIFY,BYE
 User-Agent: TANDBERG/518 (TC6.2.0.20b1616)
 Supported: timer,outbound,record-aware,X-cisco-callinfo
 Session-Expires: 1800;refresher=uac

凭最初的用户代理客户端/User代理程序服务器(UAC/UAS)协商，其中一个终端刷新会话，当发送一再邀请时。如果刷新者是UAC，呼叫的发起者有责任刷新会话。如果刷新者是UAS，服务器必须刷新会话。从两个终端收集SIP调试日志并且检查这些项目：

示例：从当事人A的发出的呼叫对方B.的CUCM。如果刷新者是在当事人A和UAS的UAC在当事人B ：

  1. 方A必须发送再邀请/更新到CUCM。
  2. CUCM必须发送再邀请/更新方B。
  3. 当事人B接受再邀请并且回应该消息以200 OK。
  4. CUCM必须发送200 OK方A。

如果一个终端传送再邀请信息到CUCM， CUCM发送一再邀请到另一个当事人。然而，如果这没有由远端接受然后这可能中间是由于一些网络设备。很可能，高度再邀请/回应不达到其中一边由于SIP检查或网络设置。

如果终端不起动再邀请，它可能是终端的一个问题。介入Cisco技术支持中心(TAC)为了进一步调查。

问题：H.323呼叫丢包在任何特定时间之后

如同SIP，在H.323呼叫呼叫丢包间隔以特定时间请发生通常由于网络或防火墙超时配置。

解决方案

在H.323呼叫，往返时延请求(RTDR)信息传送每30秒在终端之间与序号一起。对于每个请求，回应被预计。

Cisco终端使用RTDR/Round往返延迟响应消息，是控制信息H.245的多媒体系统的部分。此keps H.245 TCP会话运行在使用激活的呼叫管理的呼叫期间。如果终端最初收到RTDR的答复在呼叫期间，并且无响应被接受，终端终止呼叫。

在此方案中，请收集H.323调试日志，并且终端登陆命令查出问题。从H.323调试日志，如果下降，请检查RTDR请求和响应消息并且发现。

在此输出示例中，终端发送一个RTDR请求到远程终点，并且从远程终端不收到答复。因此它断开呼叫：

 014-09-23T21:37:01+10:00 corevcs1 tvcs: UTCTime="2014-09-23 11:37:01,
 711"Module="network.H.323" Level="DEBUG":  Dst-ip="10.0.20.11"  
 Dst-port="11012" Sending H.245 PDU: value MultimediaSystemControlMessage
 ::= request : roundTripDelayRequest : {   sequenceNumber 120

请求和回应可以跟踪与sequenceNumbers。

从终端日志的此示例显示断开的原因：

2977610.83 H.323Call I: H.323_call_handler::handleDiscInd(p=349, s=1) 
Received disconnectindication (Cause: 12:18, H.323 cause: 3:18)- 
NetworkRejected Q85012977610.84 MC I: RemoteParticipant::
reevalRefMode(p=349,ch=2) set ref [Video (2): vid-off0x0@0.0  0k ] 
q= auto, t60=600012977610.84 ModesController I: ModesController::
resetRateLimit(ch=2)12977610.84 MC I: RemoteParticipant::modeChanged
(p=349, ch=2): ModesController wants torun mode: Video (2): vid-off 0x0@0.0  0k

问题：呼叫失败由于媒体资源分配故障

一旦视频呼叫，发生故障由于媒体资源alocation故障的呼叫被看到。例如，如果呼叫和被呼叫的终端不支持一个普通的编码然后需要转码器，为了双音频多频率(DTMF)不匹配媒介终接点(MTP)在呼叫管理器需要。

解决方案

对于视频转码，需要信息包语音数字式模块(PVDM3)数字式信号处理器(DSP)转码器，因为在PVDM2的转码器不支持视频。如果transcoder/MTP不是可用的， 503服务不可用信息将传送到终端：

SIP/2.0 503 Service UnavailableVia: SIP/2.0/TCP 10.101.15.13:
5060;branch=z9hG4bK954956da2012413dfb6ef80d6bc9e373.1;rportFrom:
 <sip:3550@10.102.254.4>;tag=47c4717d0db85e1aTo:
 <sip:1281@10.102.254.4>;tag=176803~66dd1c7a-eac9-42af-a69b-
18da1695a800-31478649Date: 
Wed, 19 Feb 2014 16:10:05 GMTCall-ID: 
c05df2acedcafd063eb5cf947ebc1efcCSeq: 100 INVITEAllow-Events: 
presenceReason: Q.850;cause=47Content-Length: 0 

为了解决此，检查媒体资源组/Media资源组列表(MRG/MRGL)配置和保证视频transcoder/MTP是可用的。MRGL可以分配到在电话级别或设备缓冲池级别的一个设备：

  1. 在CallManger请选择Device > Phone并且选择有问题的设备并且检查设备缓冲池和MRGL设置：

  2. 如果设置在电话的MRGL是无，则您必须检查设备缓冲池设置确定有转码器。
  3. 选择System > Device池并且选择设备缓冲池分配到设备：

  4. 选择媒体资源> Media Resource Group List并且选择MRGL分配在电话级别/设备缓冲池级别并且检查MRGs ：

  5. 注释MRGs并且选择媒体资源>媒体资源组并且选择要注意的MRGs。保证您安排PVDM3硬件transcoder/MTP被添加。

问题：呼叫失败由于不足的带宽

多半有呼叫断开由于不足的带宽配置在地区/位置设备的在CUCM的方案。当区域设置为终端不可以支持的低带宽时，意味着“在带宽”或“不足的带宽外面”的呼叫管理器发送"488不可接受的媒体”与原因125，在SIP媒体协商发生后。

您需要SIP注册终端如所描述的caputure并且寻找此消息：

1459.81 SipPacket I: PacketDump: Proto: SIP, Direction: Incoming, Name: 488 
Not Acceptable Media, CSeq: 100 INVITE, RemoteAddress: 10.106.85.219:5060, 
CallId: 207b6ddb148ddf900ae2e2f844115837, Time: 1459811
	1459.81 SipPacket   SIP/2.0 488 Not Acceptable Media
	1459.81 SipPacket   Via: SIP/2.0/TCP 10.106.85.231:56280;
branch=z9hG4bK64e2eb4a1a3afd5f956a1547eb1c05ad.1;rport
	1459.82 SipPacket   Call-ID: 207b6ddb148ddf900ae2e2f844115837
	1459.82 SipPacket   CSeq: 100 INVITE
	1459.82 SipPacket   From: <sip:4657@example.com>;tag=2d98ee2065ba492d
	1459.82 SipPacket   To: <sip:1112@10.106.85.219>;
tag=10543~8c84fc84-78bb-de4d-3ac7-da2a9cab63d5-19683975
	1459.83 SipPacket   Server: Cisco-CUCM10.5
	1459.83 SipPacket   Date: Sun, 07 May 2015 14:36:41 GMT
	1459.83 SipPacket   Allow-Events: presence
	1459.83 SipPacket   Warning: 370 10.106.85.219 "Insufficient Bandwidth"
	1459.83 SipPacket   Reason: Q.850 ;cause=125
	1459.83 SipPacket   Content-Length: 0
	1459.83 SipPacket   
	1459.83 SipStack I: SipDialog(ui=3,s=9) sendInviteRejToStack (488:Not Acceptable Media)
	1459.84 SipCall I: sip_call_handler::handleSIPMCallRej(3/9/-1): Call rejected
 (cause: Not Acceptable Media)
	1459.84 MainEvents I: CallDisconnectRequested(p=3) remoteURI='sip:1112@10.106.85.219'
 cause=[normal('') 'LocalDisconnect']
	1459.84 MainEvents I: ParticipantLeftConference(c=2,p=3)
	1459.85 APPL_Media ERROR: AudioCtrlImpl::execute_disconnectInputOutput 
No mixer for (p=1,ch=61)
	1459.85 MainEvents I: CallDisconnected(p=3) remoteURI='sip:1112@10.106.85.219' 
causeToLocal=[disconnected('Not Acceptable Media') 'RemoteDisconnect'] 
causeToRemote=[normal('') 'LocalDisconnect']

解决方案

如果此问题发生，请检查在两个终端配置的地区并且检查他们之间的地区关系：

  1. 选择Device > Phone并且选择两个设备。检查设备缓冲池分配到设备：

  2. 一旦检查设备缓冲池，请选择在CUCM的System > Device池并且检查在两设备缓冲池配置的地区：

  3. 选择系统>Region信息>地区并且检查地区关系。检查在区域的音频视频带宽并且保证终端能运行在音频/视频带宽如选择：

在上述屏幕画面假设，一个终端在这个区域“Trunk区域”，并且其他在“本地终端区域”。

如果视频呼叫带宽的带宽是不足的，另一个解决方法是尝试视频呼叫作为音频呼叫。使用此程序为了检查和配置：

  1. 选择Device > Phone并且选择有问题的呼叫设备。检查在此屏幕画面的参数是否被检查。如果它被不选定，请检查它，以便视频呼叫下跌回到音频在带宽问题的情况下：

    此问题能发生由于在呼叫管理器的位置设置。

    位置可以分配在电话级别或在设备缓冲池级别(电话级别采取更加高优先级)。

  2. 为了检查电话级别位置设置，选择设备>电话和检查呼叫的两个和被呼叫的终端的位置：

    位置可以也适用在设备缓冲池级别。所以，首先请检查两个终端设备缓冲池：

  3. 选择System > Device池。在设备缓冲池，请检查在两个分配的位置呼叫和被呼叫的终端。在本例中位置没有分配在设备缓冲池级别。使用电话位置配置：

  4. 检查充足的带宽是否被配置在呼叫和被呼叫的端点位置之间。在此示例一终端假设在本地端点位置，并且人一个在Hub_None位置，并且音频/视频和immersive呼叫的全部带宽被配置作为无限：

能有断开的其他原因。请参阅Cisco Unified通信管理器呼叫详细信息详情记录管理指南第178页，发布10.0(1)断开原因代码的。

TAC Authored

由思科工程师提供

此文档是否有帮助?

Feedback反馈

联系我们

本文档适用于以下产品