Добрый день.
Помогите пож-ста решить пролему.
Есть кластер CUCM в центральном офисе. Всё работает, все счастливы.
SIP-транки к шлюзам для выхода в город. H.323-транк на Gatekeeper (cisco) для выхода к АТСкам (LG-ERICSSON IPECS) в удаленных офисах. Между CUCM и удаленными АТС никаких шлюзов нет и все друг друга видят в локальной сети. Через Gatekeeper только сигнализация. Везде используется кодек G711.
Сейчас это всё работает вот так:
Появилась необходимость при связи с удаленными АТС использовать кодек G729.
Мы ознакомились с этой и этой статьями и решили на CUCM отделить H323-транк в Device Pool ассоциированный с другим Region и настроенным bandwidth 8 кбит/с (G.729). А на Gatekeeper'е выделить DSP-ресурсы для транскодинга и добавить их в управление CUCMу. Примерно как описано в вышеприведенных статьях.
В результате:
При тестировании на телефонах CUCM всё заработало как и ожидалось. т.е. если мы звоним с CUCM через Gatekeeper обратно на CUCM, то DSP-ресурсы Gatekeeper'а транскодят, звонки переводятся, и даже в конференциях звонки через транк гейткипера идут с G729, а локальные G711. Все друг друга слышат, всё замечательно.
А вот если звонить на удаленную АТС, кодек согласовывается G729, связь есть, но при попытке что-либо сделать (перевод, удерж, конф), соответствующий SoftKey на аппарате блокируется, связь пропадает и через несколько секунд отбой.
Возможно есть какие-то очевидные промахи в топологии? Так должно вообще работать? Если необходимо, могу скинуть более подробные данные по конфигурации устройств.
Картинка не прикрепилась
Как есть сейчас:
Добрый день
В принципе работать должно, но ваша ситуация определённо не простая, я бы поискал способы упростить.
А тут еще и удалённая ATC (циска ли).
Вы уверены что транкодинг у вас запустился? На Gatekeeper'е должны быть видны ноги терминированных звонков на транскодер.
Посмотрите чтобы в настройках шлюзов настройки типа Enable Inbound FastStart соответствовали друг другу.
Удаленные АТС - LG Ipecs MG.
Удаленные АТС - LG Ipecs MG.
Транскодинг при тестах на телефонах ЦО запустился точно и даже занимал необходимые каналы и ресурсы.
Fast Start везде стоит.
debug
Боюсь вам поможет только дебаг H.323 + Gatekeeper.
Спасибо. Будем дебажить.
Спасибо. Будем дебажить.
Правда я не очень понимаю, как CUCM в данном случае управляет потоком? как в удаленная АТС должна понять, что в определенный момент ей нужно начать слать/принимать поток не на CUCM, а на Transcoder? Этот момент по H.323 управляется?
Использование Transcoder
CUCM ведь играет роль "командира". Изначально на том конце "знают" только IP CUCM и номер назначения. Если звонок "падает" на H.323 GAteway, далее уже только CUCM решает куда пойдёт поток: будет это IP коф.бриджа, ipтелефона или транскодера.
Требование использования Transcoder вложено в галку Media Termination Point Required в св-вах H.323 Gateway: в этом случае CUCM требует подключение потоков RTP не к телефону а к транскодеру.
Адрес транскодера подсовывается в процессе негоциации потока, так же как и кодек
Решили.
Проблема была в нескольких местах.
Во-первых, Transcoder должен быть в том же Device Pool, что и Trunk. Если переносим его в другой девайс-пул, то почему-то перестает работать, хотя Media Resource Group и там и там одинаковый. Я не понял почему так, и не очень понимаю как дебажить подобные внутренние моменты на CUCM.
Во-вторых, CP7931 и CP7975 напрочь отказывались работать с Transcoder, пока не поставил Disabled на Advertise G.722 Codec в настройках самого аппарата. Хотя dspfarm profile выглядит так:
dspfarm profile 10 transcode
codec pass-through
codec g729r8
codec g729br8
codec g722-64
codec g711ulaw
codec g711alaw
codec g729ar8
codec g729abr8
maximum sessions 38
associate application SCCP
Вот как-то так.
Дебаг на CUCM
Дебаг внутренних процессов на CUCM - это трейс (trace).
Пример работы с трейсом Логирование и трекинг (trace) звонков в CUCM
Касательно Device pool, могу предположить что вместе с другим пулом наследуются какие-то несовместимые параметры типа региона.
Добавить комментарий