Поиск и устранение неисправностей при межкластерном вызове между Cisco IP Phone
В этом разделе рассматривается пример, когда Cisco IP Phone совершает вызов на другой Cisco IP Phone, расположенный в другом кластере (межкластерный вызов).
Для примера возьмем следующую топологию:два кластера, каждый имеет два CUCM, а также Cisco IOS Gateways и Cisco IOS Gatekeeper.
Intercluster H.323 Communication
Cisco IP Phone в Cluster 1 звонит на Cisco IP Phone in Cluster 2. Межкластерное соединения CUCM происходит с использование протокола H.332 версии 2. Cisco IOS Gatekeeper служит для контроля доступа.
Cisco IP Phone может соединятся с CUCM используя Skinny Station протокол (SCCP), а CUCM может соединятся с Cisco IOS Gatekeeper, используя H.323 RAS протокол.
Admission request message (ARQ)[2] посылается к Cisco IOS Gatekeeper, который посылает Admission confirmed message (ACF)[3], убедившись, что межкластерный вызов будит совершаться с использованием протокола H.323 версии 2. После этого происходит установление звукового тракта между Cisco IP Phones в разных кластерах, с использованием RTP протокола.
Trace потока вызова
В этом разделе рассматривается поток вызова, на примере использования SDI trace, записанного в файле CCM000000000. Traces, рассматриваемый в этом примере, содержит информацию только этого конкретного вызова (рассматриваемого в примере).
В данном случае, Cisco IP Phone (2002), расположенный в Cluster 2, звонит на Cisco IP Phone (1001), расположенный в Cluster 1. Помните, что вы можете следить за устройством с использованием trace, просматривая значения TCP handle, time stamp или имени устройства. Значение TCP handle для устройства не изменяется, пока оно не будет перезагружено или не будит выведено из сети.
В следующем trace показано: Cisco IP Phone (2002) снимает трубку, TCP handle и номер вызывающего абонента. Так же показан номер вызываемого абонента (набранный номер) (1001), H.225 запрос на соединение и H.245 подтверждающие сообщения. Тип кодеков - выбран G.711 mu-law.
16:06:13.921 CCM|StationInit - InboundStim - OffHookMessageID tcpHandle=0x1c64310
16:06:13.953 CCM|Out Message -- H225ConnectMsg -- Protocol= H225Protocol
16:06:13.953 CCM|Ie - H225UserUserIe IEData= 7E 00 37 05 02 C0 06
16:06:13.953 CCM|StationD - stationOutputCallInfo CallingPartyName=, CallingParty=2002,
CalledPartyName=1001, CalledParty=1001, tcpHandle=0x1c64310
16:06:14.015 CCM|H245Interface(2) OLC indication chan number = 2
16:06:14.015 CCM|StationD - stationOutputOpenReceiveChannel tcpHandle=0x1c64310 myIP:
e74610ac (172.16.70.231)
16:06:14.015 CCM|StationD - ConferenceID: 0 msecPacketSize: 20
compressionType:(4)Media_Payload_G711Ulaw64k
16:06:14.062 CCM|StationInit - InboundStim - StationOpenReceiveChannelAckID
tcpHandle=0x1c64310, Status=0, IpAddr=0xe74610ac, Port=20444, PartyID=2
16:06:14.062 CCM|H245Interface(2) paths established ip = e74610ac, port = 20444
16:06:14.187 CCM|H245Interface(2) OLC outgoing confirm ip = fc4610ac, port = 29626
Представлены номера вызывающего и вызываемого абонентов, которые связаны с IP адресами и шестнадцатеричными значениями.
16:06:14.187 CCM|StationD - stationOutputStartMediaTransmission tcpHandle=0x1c64310 myIP: e74610ac (172.16.70.231)
16:06:14.187 CCM|StationD - RemoteIpAddr: fc4610ac (172.16.70.252)
Далее представлен trace, показывающий размер пакетов и MAC адрес Cisco IP Phone (2002), затем идет разъединение, сообщение о том, что трубку положили.
RemoteRtpPortNumber: 29626 msecPacketSize: 20 compressionType:(4)Media_Payload_G711Ulaw64k
16:06:16.515 CCM| Device SEP003094C26105 , UnRegisters with SDL Link to monitor NodeID= 1
16:06:16.515 CCM|StationD - stationOutputCloseReceiveChannel tcpHandle=0x1c64310 myIP:
e74610ac (172.16.70.231)
16:06:16.515 CCM|StationD - stationOutputStopMediaTransmission tcpHandle=0x1c64310 myIP:
e74610ac (172.16.70.231)
16:06:16.531 CCM|In Message -- H225ReleaseCompleteMsg -- Protocol= H225Protocol
16:06:16.531 CCM|Ie - Q931CauseIe -- IEData= 08 02 80 90
16:06:16.531 CCM|Ie - H225UserUserIe -- IEData= 7E 00 1D 05 05 80 06
16:06:16.531 CCM|Locations:Orig=1 BW=64Dest=0 BW=-1 (-1 implies infinite bw available)
16:06:16.531 CCM|MediaManager - wait_AuDisconnectRequest - StopSession sending disconnect
to (64,2) and remove connection from list
16:06:16.531 CCM|MediaManager - wait_AuDisconnectReply - received all disconnect replies,
forwarding a reply for party1(16777219) and party2(16777220)
16:06:16.531 CCM|MediaCoordinator - wait_AuDisconnectReply - removing MediaManager(2) from
connection list
16:06:16.734 CCM|StationInit - InboundStim - OnHookMessageID tcpHandle=0x1c64310
Поток вызова с ошибкой
В следующем разделе рассматривается межкластерный поток вызова с ошибкой. Cisco IP Phone (1001) снимает трубку. TCP handle присваивается Cisco IP Phone.
16:05:33.468 CCM|StationInit - InboundStim - OffHookMessageID tcpHandle=0x4fbbc30
16:05:33.468 CCM|StationD - stationOutputDisplayText tcpHandle=0x4fbbc30, Display= 1001
16:05:33.484 CCM|StationD - stationOutputSetLamp stim: 9=Line instance=1 lampMode=LampOn
tcpHandle=0x4fbbc30
Пользователь набирает номер вызываемого абонента (2000), и процесс анализа цифр пытается сопоставить номер (с шаблоном).
16:05:33.484 CCM|Digit analysis: match(fqcn="", cn="1001", pss="", dd="")
16:05:33.484 CCM|Digit analysis: potentialMatches=PotentialMatchesExist
16:05:35.921 CCM|Digit analysis: match(fqcn="", cn="1001", pss="", dd="2")
16:05:35.921 CCM|Digit analysis:potentialMatches=ExclusivelyOffnetPotentialMatchesExist
16:05:36.437 CCM|Digit analysis: match(fqcn="", cn="1001", pss="", dd="20")
16:05:36.437 CCM|Digit analysis:potentialMatches=ExclusivelyOffnetPotentialMatchesExist
16:05:36.656 CCM|Digit analysis: match(fqcn="", cn="1001", pss="", dd="200")
16:05:36.656 CCM|Digit analysis:potentialMatches=ExclusivelyOffnetPotentialMatchesExist
16:05:36.812 CCM|Digit analysis: match(fqcn="", cn="1001", pss="", dd="2000")
Trace, представленный ниже, результат завершившегося процесса анализа цифр. Обратите внимание, что PotentialMatches=NoPotentialMatchesExist сообщает, что CUCM не может найти соответствие этому абонентскому номеру. В завершении, посылается сигнал занятости линии вызывающему абоненту (1001), за которым следует сообщение «трубка повешена».
16:05:36.812 CCM|Digit analysis: analysis results
16:05:36.812 CCM||PretransformCallingPartyNumber=1001
|CallingPartyNumber=1001
|DialingPattern=2XXX
|DialingRoutePatternRegularExpression=(2XXX)
|PotentialMatches=NoPotentialMatchesExist
|CollectedDigits=2000
16:05:36.828 CCM|StationD - stationOutputCallInfo CallingPartyName=1001,
CallingParty=1001, CalledPartyName=, CalledParty=2000, tcpHandle=0x4fbbc30
16:05:36.828 CCM|StationD - stationOutputStartTone: 37=ReorderTone tcpHandle=0x4fbbc30
16:05:37.953 CCM|StationInit - InboundStim - OnHookMessageID tcpHandle=0x4fbbc30
Скорее всего имеется ввиду, что для набранного номера имеется несколько перекрывающихся шаблонов (например, 2ХХХ и 20ХХ). Номер будит выбран по условиям Closest Match Routing. После соединения с абонентом, выбранным по условиям Closest Match Routing, вызывающий слышит сигнал о занятости линии потому, что вызываемый абонент разговаривает (всего лишь предположение).
[2]Запрос на разрешение об участии в разговоре от конечной точки к gatekeeper.
[3]Положительный ответ от gatekeeper, разрешающей конечной точке принимать участие в разговоре.
Ссылка на
первую часть и
на вторую, на третью
P.S. Это перевод части официальной документации,если кто будит пользоваться обратите внимание, что точность и правильность перевода не гарантируется. В тексте могут присутствовать орфографические, пунктуационные и другие ошибки. За более полной информацией необходимо обратится к официальной документации.
