Голосовая связь и система унифицированных коммуникаций : Cisco Unified Communications Manager (CallManager)

Статус моста конференц-связи CallManager: KEEPALIVE_FAILED

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


Содержание


Введение

Этот документ предоставляет сведения о том, как устранить неполадки, когда Мост конференц-связи Сisco CallManager отказывает с сообщением об ошибках KEEPALIVE_FAILED. Мост конференц-связи становится недоступным потенциально неопределенному периоду времени, пока это не исправлено.

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

Требования

Для этого документа отсутствуют особые требования.

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

Сведения в этом документе основываются на Сisco CallManager 4.1 (3) и Cisco маршрутизатор серии 2800, который выполняет Cisco Выпуск ПО IOS� 12.3.

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

Условные обозначения

Дополнительные сведения об условных обозначениях см. в документе Условные обозначения технических терминов Cisco.

Общие сведения

Поддерживающая аппаратные средства конференц-связь предоставляет способность поддержать голосовые конференции в аппаратных средствах. Процессоры Сигнализации по цифровым каналам (DSP) преобразовывают множественные Потоки мультимедиа Передачи голоса по IP в потоки TDM, которые смешаны в одиночный поток циркулярного вызова. Количество поддерживаемых конференций зависит от количества доступных DSP. Так, если мосты конференц-связи не завершены должным образом, DSP не могут быть снова использованы. Для получения дополнительной информации о том, как настроить мост конференц-связи на IOS-шлюзе, обратитесь к CallManager и Примеру конфигурации Цифрового процессора DSP Farm IOS-шлюза.

Мост конференц-связи всунутое Состояние KEEPALIVE_FAILED

Если Сisco CallManager становится недостижимым к мосту конференц-связи, это было зарегистрировано к тому, в то время как конференция была активна, мост конференц-связи заканчивается в состоянии KEEPALIVE_FAILED. Мост конференц-связи также продолжает передавать сигналы сред, потенциально по глобальной сети (WAN) в течение длительного времени после того, как все стороны оставили конференцию, и ресурсы DSP не в состоянии быть снова использованными для большего количества конференций.

Решение

Ошибка KEEPALIVE_FAILED найдена, потому что мост конференц-связи не переключается назад к другому CallManager, который доступен в кластере. Для решения этой проблемы необходимо упомянуть switchover method для использования в шлюзе.

Когда соединение связи между активным Cisco Unified CallManager и клиентом Протокола SCCP выключается, клиент SCCP пытается соединиться с одним из вторичных Cisco Unified CallManager с использованием одного из этого switchover method:

  • Постепенный — переключатель Cisco Unified CallManager происходит только после того, как все активные сеансы завершены корректно. Это метод по умолчанию.

  • Непосредственный — Независимо от того, существует ли активное соединение или нет, переключения клиента SCCP к одному из вторичных Cisco Unified CallManager сразу. Если Клиент SCCP не в состоянии соединиться со вторичным Cisco Unified CallManager, он продолжает опрашивать для соединения Cisco Unified CallManager.

  1. Switchover method может быть упомянут под конфигурацией sccp ccm group.

    gateway(config)#sccp ccm group 1
    
    gateway(config-sccp-ccm)#switchover method immediate
    

    Примечание: Если вам настроили множественные профили для конференц-связи в dspfarm, используйте switchover method в качестве постепенного.

  2. Для завершения мостов конференц-связи, которые передают сообщения сред, сообщение RTP должно таймаут. Это может быть сделано при изменении получить таймера RTP в конфигурации шлюза.

    gateway(config)#gateway
    
    gateway(config-gateway)#timer receive-rtp 180
    

    Время ожидания по умолчанию происходит только после 1200 secs (20 минут).


Дополнительные сведения


Document ID: 82478