Video : Cisco 网真编解码器 C40

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

2015 年 8 月 28 日 - 机器翻译
其他版本: PDFpdf | 英语 (2015 年 7 月 23 日) | 反馈

简介

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

贡献用Ankita Kanyal, Devasayee Gopalan和Ishan Sambhi, Cisco TAC工程师。

先决条件

要求

Cisco 建议您了解以下主题:

如何获取H.323调试日志

注意:保证输出捕获的安全Socket主机(SSH)会话。

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

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

注意:保证输出捕获的SSH会话。

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

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

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

其他需的信息

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

使用的组件

本文档不限于特定的软件和硬件版本。

本文档中的信息都是基于特定实验室环境中的设备编写的。本文档中使用的所有设备最初均采用原始(默认)配置。如果您使用的是真实网络,请确保您已经了解所有命令的潜在影响。

问题:由于的呼叫失败呼叫在CallManager的搜索空间(CSS) /Partition问题

在两个终端之间的呼叫注册对Cisco Unified Communications Manager (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会话超时计时器。默认情况下在CallManager, 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调试日志并且检查这些项目:

示例:从Party A的发出的呼叫对方B.的CUCM。如果刷新者UAC打开请方A和UAS在Party B :

  1. 方A必须发送再邀请/更新到CUCM。
  2. CUCM必须发送再邀请/更新方B。
  3. Party B接收再邀请并且响应对该消息以200 OK。
  4. CUCM必须发送200 OK方A。

如果一个终端传送再邀请信息对CUCM, CUCM发送再邀请对另一Party。然而,如果这没有由远端接收然后这可能中间是由于一些网络设备。很可能,高度再邀请/答复不达到其中一侧由于SIP检查或网络设置。

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

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

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

解决方案

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

思科终端使用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)在CallManager要求。

解决方案

对于视频转码,信息包语音数字模块(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的方案。当区域设置为终端不可以支持的低带宽时, CallManager发送"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信息>地区并且检查地区关系。检查在区域的音频视频带宽并且保证终端能运行在音频/视频带宽如选择:

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

如果视频呼叫带宽的带宽是不足的,另一应急方案是尝试视频呼叫作为音频呼叫。使用此步骤为了检查和配置:

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

    此问题能发生由于在CallManager的位置设置。

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

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

    位置可能也应用在设备池级别。所以,首先请检查两个终端的设备池:

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

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

能有断开的其他原因。请参阅页Cisco Unified Communications Manager呼叫详细记录管理指南178,发布10.0(1)断开原因代码的。


相关的思科支持社区讨论

思科支持社区是您提问、解答问题、分享建议以及与工作伙伴协作的论坛。


Document ID: 119207