Видео и доставка контента : Кодек Cisco TelePresence C40

Ошибки вызова устранения неполадок на оконечных точках TC, зарегистрированных к Сisco CallManager

20 октября 2016 - Машинный перевод
Другие версии: PDF-версия:pdf | Английский (21 апреля 2016) | Отзыв

Введение

Этот документ объясняет некоторые проблемы сбоя обычного вызова, сталкивающиеся с оконечными точками Кодека Tandberg (TC), зарегистрированными к Сisco CallManager и предложенным решениям.

Внесенный Ankita Kanyal, Devasayee Gopalan, и Ishan Sambhi, специалистами службы технической поддержки Cisco.

Предварительные условия

Требования

Компания Cisco рекомендует предварительно ознакомиться со следующими предметами:

Как Перехватить Журналы отладки H.323

Примечание: Гарантируйте, что перехвачены выходные данные сеанса Хоста защищенного сокета (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. От веб-GUI выбирают Diagnostics> Файлы журнала и включают расширенную регистрацию с перехватом полного пакета.
  2. Запустите вызов и воссоздайте проблему. Обратите внимание на то, что захват пакета может только быть включен в течение 3 минут.
  3. От веб-GUI выбирают Diagnostics> Файлы журнала и загружают завершенный регистрационный архив и захват пакета.

Другая требуемая информация

  • Завершенный поток вызовов со всеми включенными устройствами
  • Вызываемый и вызывающий номер
  • Дата и время проблемы произошла

Используемые компоненты

Настоящий документ не имеет жесткой привязки к каким-либо конкретным версиям программного обеспечения и оборудования.

Сведения, представленные в этом документе, были получены от устройств, работающих в специальной лабораторной среде. Все устройства, описанные в этом документе, были запущены с чистой (стандартной) конфигурацией. В рабочей сети необходимо изучить потенциальное воздействие всех команд до их использования.

Проблема: Ошибки вызова из-за Пространства поиска вызова (CSS) / Проблема Разделения на CallManager

Вызовы между двумя оконечными точками, зарегистрированными к Cisco Unified Communications Manager (CUCM), могли бы отказать из-за проблемы CSS/Разделения на CUCM.

Перехватите журналы SIP оконечной точки вызова. Это "404 Не Найденное" сообщение появляется на журналах SIP Оконечной точки, которые прибывают из CUCM:

 |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 должны иметь разделение вызываемого номера:

  2. Проверьте CSS, назначенный на телефонном уровне. Выберите Device> Phone и выберите рассматриваемую оконечную точку вызова:

  3. Проверьте разделение Вызываемого номера. Выберите Device> Phone, выберите вызываемое устройство, щелкните по линии и проверьте Маршрут Partion:

  4. После проверки Partiton и CSS на обеих оконечных точках проверьте, имеет ли CSS вызывного устройства разделение вызываемого устройства:

    В противном случае это могло быть причиной "404 Не Найденная" ошибка.

Проблема: Отбрасывание вызова SIP после 15 Минут (или после любого Специфического времени)

Обычно сбросы вызова в интервалах специфического времени вызваны Sip timer или таймаутом TCP, настроенным на межсетевых экранах, маршрутизаторах, и т.д.

Решение

Когда разъединения вызова точно в 15 минут, замеченная типичная проблема являются таймаутом TCP, настроенным в сети (межсетевые экраны, маршрутизаторы) меньше, чем сеанс SIP истекает таймер. По умолчанию на CallManager, сеанс SIP Истекает, Таймер установлен в 1800 секунд.

Для проверки этого выберите Cisco Unified CM Administration> System> Service Parameters> Cisco Call Manager ServiceLook для - сеанс SIP Истекает Таймер.

Все оконечные точки, зарегистрированные к CUCM, используют этот таймер. Когда оконечная точка по требованию с другой удаленной оконечной точкой, одна из сторон должна обновить сеанс и передает переINVITE или ОБНОВЛЕНИЕ. Это обновление должно быть передано, прежде чем половина Сеанса Истекает Таймер (1800/2 = 900 секунд = 15 минут). Если нет никакого полученного сообщения обновления, вызов разъединен.

Проверьте для таймера сеанса в начальном INVITE. Обновление (INVITE / ОБНОВЛЕНИЕ) должно быть получено, прежде на этот раз истекает:

|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 Agent (UAC/UAS) согласование, одна из оконечных точек обновляет сеанс, когда это передает переINVITE. Если напоминание является UAC, инициатор вызова несет ответственность обновить сеанс. Если напоминание является UAS, сервер должен обновить сеанс. Соберите журналы отладки SIP от обеих оконечных точек и проверьте эти элементы:

Пример: Назовите сделанными из Стороны к CUCM для Посещения вечеринок B. Если напоминание является UAC на Стороне A и UAS на Стороне B:

  1. Сторона A должна передать переINVITE / ОБНОВЛЕНИЕ CUCM.
  2. CUCM должен передать переINVITE / ОБНОВЛЕНИЕ для Посещения вечеринок B.
  3. Сторона B получает переINVITE и отвечает на то сообщение с 200 OK.
  4. CUCM должен передать 200 OK для Посещения вечеринок A.

Если одна оконечная точка передает ПЕРЕСООБЩЕНИЕ INVITE к CUCM, CUCM передает переINVITE другой Стороне. Однако, если это не получено удаленной стороной тогда, это могло бы быть из-за некоторых промежуточных сетевых устройств. Очень возможно, что re-INVITE/response не добирается до одной из сторон из-за проверки SIP или настроек сети.

Если оконечные точки не инициируют переINVITE, это могла бы быть проблема с оконечной точкой. Включите Технический центр Assitance (TAC) Cisco для исследования далее.

Проблема: Сбросы вызова H.323 после любого Специфического времени

Как с SIP, в H.323 звонит, сбросы вызова в интервале специфического времени обычно происходят из-за сети или конфигурации таймаута межсетевого экрана.

Решение

В вызовах H.323 сообщение Запроса задержки приема-передачи (RTDR) передается каждые 30 секунд между оконечными точками наряду с порядковыми номерами. Для каждого запроса ожидается ответ.

Оконечная точка Cisco использует Ответное сообщение Задержки обхода RTDR/Round, которое является частью Управляющего сообщения Мультимедийной системы H.245. Этот keps сеанс TCP H.245, живой во время вызова, который используется для управления активного вызова. Если оконечная точка получает ответ для 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

Проблема: Ошибка вызова из-за Ошибки выделения Медиаресурса

В случае видеовызовов замечены вызовы, которые отказывают из-за сбоя выделения Медиаресурса. Например, если вызов и вызванная оконечная точка не поддерживают стандартный кодек тогда, перекодировщик требуется, поскольку Двухтональная много частота (DTMF) не сочетается, Media Termination Point (MTP) требуется на Call Manager.

Решение

Для видео перекодировки Пакет речевых сигналов требуется Цифровой перекодировщик Цифрового процессора сигналов (DSP) Модуля (PVDM3), поскольку перекодировщики на PVDM2 не поддерживают видео. Если бы перекодировщик/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 Resource Groups / Список Media Resource Groups (MRG/MRGL) конфигурация и гарантируйте, что видео перекодировщик/MTP доступен. MRGL может быть назначен на устройство на Телефонном Уровне или Уровне Аппаратного пула:

  1. На CallManger выбирают Device> Phone и выбирают устройство, которое имеет проблему, и проверьте Аппаратный пул и параметры настройки MRGL:

  2. Если значение MRGL по телефону не Ни один, то необходимо проверить параметры настройки Аппаратного пула, чтобы удостовериться, что существует перекодировщик.
  3. Выберите System> Device Pool и выберите аппаратный пул, назначенный на устройство:

  4. Выберите Media Resources> Media Resource Group List и выберите MRGL, назначенный на телефонном уровне / уровень Аппаратного пула, и проверьте MRG:

  5. Обратите внимание на MRG и выберите Media Resources> Media Resource Group и выберите MRG, на которые обращают внимание. Гарантируйте, что у вас есть аппаратный транскодер PVDM3 / добавленный MTP.

Проблема: Ошибки вызова из-за Недостаточной Пропускной способности

Как правило, существуют сценарии, где вызов разъединен из-за недостаточной настройки пропускной способности в Области/Местоположении на устройстве в CUCM. Когда область установлена в низкую пропускную способность, которую не может поддержать оконечная точка, CallManager передает "488 Не Приемлемые Среды" с причиной 125, что означает "Из Пропускной способности" или "Недостаточной Пропускной способности" после того, как происходит согласование среды SIP.

Вам нужно к caputure, SIP входит в систему оконечной точки, как описано, и ищите это сообщение:

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. Как только вы проверяете Аппаратный пул, выбираете System> Device Pool на CUCM и проверяете Область, настроенную на обоих Аппаратных пулах:

  3. Выберите System> Region Information> Regions и проверьте Отношение Области. Проверьте аудио полосу частот видеосигнала на области и гарантируйте, что оконечная точка может работать в аудио/полосе частот видеосигнала, как выбрано:

В вышеупомянутых снимках экрана предполагается, что одна оконечная точка находится в Области "Область Транка", и другой находится в "Области Локальных оконечных точек".

Если пропускная способность для пропускной способности видеовызова недостаточна, другой обходной путь должен попробовать видеовызов как Аудио Вызов. Используйте эту процедуру, чтобы проверить и настроить:

  1. Выберите Device> Phone и выберите вызывное устройство проблемой. Проверьте, проверен ли параметр в этом снимке экрана. Если это неконтролируемо, проверьте его так, чтобы видеовызов переключился на аудио в случае проблем с полосой пропускания:

    Эта проблема могла произойти из-за Настроек расположения на CallManager.

    Местоположения могут быть назначены на Телефонном Уровне, или на уровне Аппаратного пула (Телефонный Уровень берет более высокий приоритет).

  2. Для проверки Телефонных настроек расположения Уровня выберите Devices> Phones и проверьте местоположение и на вызове и на вызванной оконечной точке:

    Местоположение может также быть применено на уровне аппаратного пула. Поэтому первая проверка аппаратный пул обеих оконечных точек:

  3. Выберите System> Device Pool. На аппаратном пуле проверьте местоположение, назначенное на обоих вызов и вызванные оконечные точки. В данном примере никакое местоположение не назначено на уровне аппаратного пула. Телефонная конфигурация расположения используется:

  4. Проверьте, настроена ли достаточная пропускная способность между вызовом и вызванным местоположением оконечных точек. В данном примере одна оконечная точка, как предполагается, находится в местоположении Локальных оконечных точек, и другой находится в местоположении Hub_None и пропускной способности для аудио / видео и иммерсивные вызовы все настроены как Неограниченные:

Могли быть другие причины для разъединения. Посмотрите страницу 178 Руководства по администрированию Подробных записей о вызовах Cisco Unified Communications Manager, Выпуска 10.0 (1) для кодов причин Разъединения.



Document ID: 119207