предупреждение о нехватке лицензий «CUBE v14 Trunk Standard Session»
-
Миграция нашего клиента на новую инфраструктуру UC, состоящую из CUCM 14 + ряд CUBEs (ISR4331). ISR изначально были настроены как шлюзы H323 на CUCM 11.5, которые все еще находятся в эксплуатации, и были обновлены до версии 17.06.06a. Это потребовало настройки SIP-транков вместо исходной конфигурации H323 (в соответствии с примечанием «Прекращение поддержки функций управления вызовами H.323 в программном обеспечении Cisco IOS XE» —
https://www.cisco.com/c/en/us/products/collateral/unified-communications/unified-border-element/bulletin-c25-2479306.html))
. В течение нескольких недель проводилось тестирование на маршрутизаторе ISR с активными соединениями ISDN, было сделано много вызовов в PSTN и из PSTN, и на основе этого были настроены конфигурации. Теперь, около месяца назад, еще один такой ISR вошел в производственную фазу: все работает нормально, но было замечено, что на портале лицензирования CSSM появляется предупреждение «Виртуальная учетная запись «XXXXX» сообщила о нехватке 1 лицензии «CUBE v14 Trunk Standard Session»». Такого рода предупреждение никогда не появлялось на тестовом ISR, и мы задаемся вопросом, почему. Возможно, это зависит от количества одновременных вызовов (в любом случае, для тестового ISR оно намного ниже, чем для ISR, который сейчас находится в производстве), или, возможно, между ними есть какие-то различия в конфигурации, которые нелегко понять. Кроме того, если клиент не хочет приобретать новые лицензии, следует ли нам вернуться к Cisco IOS XE Bengaluru 17.5 и конфигурации h323? Мы попытались узнать больше с помощью команд
show voice sip license status
и
show voice sip license stats,
но результаты не кажутся легко понятными. Есть ли какие-либо советы или, возможно, простое объяснение того, как работает механизм лицензирования CUBE v14 Trunk Standard Session? Скольким одновременным вызовам соответствует использование 1 лицензии (что мы показываем в CSSM)? Что может (или не может) вызвать такой тип оповещения? Спасибо за помощь. -
Лицензии CUBE trunk расходуются за каждый одновременный вызов. Если вы включили функцию CUBE (режим border-element) и вызов соответствует VoIP dial-peers для входящих и исходящих вызовов, расходуется лицензия CUBE. Мое предположение, основанное на догадках, заключается в том, что CUCM отправил маршрутизатору вызов, который также соответствовал dial-peers, обращенным к CUCM. CUCM, надеюсь, отклонил его, чтобы предотвратить образование петли, но к тому моменту лицензия CUBE уже была использована. Возвращение к H.323, на мой взгляд, было бы очень недальновидным решением. IOS XE 17.5 уже
достиг конца срока обслуживания программного обеспечения
, поэтому дальнейшие исправления ошибок или уязвимостей не будут производиться. PS- CUCM 11.5 достиг
конца срока поддержки
. Обновитесь до версии 15 или перейдите на Webex Calling. -
Хорошее объяснение механизма приведено в этом руководстве.
Руководство по настройке Cisco Unified Border Element через Cisco IOS XE 17.5 — CUBE Smart Licensing [Cisco Unified Border Element] — Cisco Кто-то снял видео об этом
Cisco Unified Boarder Element (CUBE) 14 Обзор лицензирования -
Спасибо, jrsteele21, обязательно посмотрю!
-
Спасибо, Джонатан! Я бы очень хотел остаться на SIP, а возврат к H323 — это худший из возможных вариантов. Строка Mode border-element на самом деле не включена в конфигурацию. В выводе show logging было замечено сообщение «%CALL_CONTROL-6-CALL_LOOP: Входящий вызов имеет глобальный идентификатор, который уже присутствует в списке обрабатываемых в данный момент вызовов. Он отклоняется», которое также находится в процессе расследования. По вашему мнению, может ли это быть связано с упомянутым потреблением лицензии?
-
PS Джонатан, как вы, наверное, уже поняли, у меня ограниченные навыки в области маршрутизации вызовов на ISR и dial-peers: не могли бы вы привести пример желаемого случая, когда «вызов соответствует VoIP dial-peers для входящих и исходящих сегментов вызова»?
-
Для входящих вызовов рекомендуется использовать информацию в заголовке VIA для сопоставления входящего диалогового партнера, а затем, если вы не хотите рисковать возникновением циклов вызовов, я бы использовал либо группу диалоговых партнеров (Dial Peer Group, сокращенно DPG), либо COR для ограничения диалоговых партнеров, которые могут использоваться в каждом направлении. Ознакомьтесь с этим документом для получения дополнительной информации о том, как работает маршрутизация вызовов в IOS.
Объяснение маршрутизации вызовов Cisco IOS и IOS XE ![Response Signature]
-
Спасибо, Роджер, посмотрю документ, который ты прислал!
-
Джонатан, твой совет был верным: мне удалось удалить цикл вызовов, который я нашел в журналах, и предупреждение в CSSM исчезло. У нас есть dial-peer, подключающийся к самому ISR, когда активен режим SRST, и только для определенного номера этот dial-peer был сопоставлен, что привело к возникновению цикла. Исправил это, назначив приоритет такому dial-peer. Однако еще предстоит доработать настройки, так как предпочтение не всегда обеспечивает точное соответствие вызовов, предназначенных для SRST, и вызовов для CUCM. Спасибо!
-
PS добавил команду
voice-class sip options-keepalive
к dial-peers с узлами CUCM, чтобы в случае недоступности CUCM из филиала эти dial-peers не сопоставлялись. Надеюсь, это должно помочь. -
Не могли бы вы поделиться более подробной информацией об этом «У
нас есть диалоговый пир, подключающийся к самому ISR, когда активен режим SRST»? Что вы имеете в виду? ![Response Signature] -
У нас есть 4 диалоговых партнера, соответствующих шаблону E164 12345XXX, которые в нормальных условиях работы отправляют вызовы на узлы CUCM. Теперь, поскольку ISR также действует как сервер SRST, был настроен один диалоговый пир, соответствующий вышеуказанному шаблону E164 12345XXX, но отправляющий вызовы на сам ISR, когда CUCM недоступен.
-
Если устройства с
шаблонами
E164 12345XXX регистрируются на шлюзе, когда они находятся в состоянии SRST, не должно быть необходимости в наличии диалогового пира, который перенаправляет вызов на сам шлюз. ![Response Signature] -
Я понимаю, о чем вы, Роджер, но в таком случае перевод с E164 12345XXX на внутренний шаблон XXXX должен происходить на ISR, а не на CUCM (согласно найденной конфигурации), верно?
-
Это абсолютно верно. При наличии SRST в смеси вы должны выполнять любой перевод телефонных номеров при входе из PSTN в шлюзе. Лучше всего было бы использовать номера каталога в формате +E.164, а затем, если у вас есть формат коротких номеров, наложить его поверх номеров E.164. ![Response Signature]
Здравствуйте! Похоже, вам интересна эта беседа, но у вас пока нет учетной записи.
Вы устали просматривать одни и те же посты каждый раз, когда заходите на сайт? После регистрации, вам не придётся искать обсуждения в которых вы принимали участие, настройте уведомления о новых сообщениях так как вам это удобно (по электронной почте или уведомлением). У вас появится возможность сохранять закладки и ставить лайки постам, чтобы выразить свою благодарность другим участникам сообщества.
С вашими комментариями этот пост может стать ещё лучше 💗
Зарегистрироваться Войти