Миграция нашего клиента на новую инфраструктуру 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)? Что может (или не может) вызвать такой тип оповещения? Спасибо за помощь.

]]>https://sla247.ru/forum/topic/1252/предупреждение-о-нехватке-лицензий-cube-v14-trunk-standard-sessionRSS for NodeThu, 14 May 2026 22:47:10 GMTWed, 18 Feb 2026 20:02:35 GMT60Это абсолютно верно. При наличии SRST в смеси вы должны выполнять любой перевод телефонных номеров при входе из PSTN в шлюзе. Лучше всего было бы использовать номера каталога в формате +E.164, а затем, если у вас есть формат коротких номеров, наложить его поверх номеров E.164. ![Response Signature]

]]>https://sla247.ru/forum/post/8769https://sla247.ru/forum/post/8769Wed, 18 Feb 2026 20:02:49 GMTЯ понимаю, о чем вы, Роджер, но в таком случае перевод с E164 12345XXX на внутренний шаблон XXXX должен происходить на ISR, а не на CUCM (согласно найденной конфигурации), верно?

]]>https://sla247.ru/forum/post/8768https://sla247.ru/forum/post/8768Wed, 18 Feb 2026 20:02:48 GMTЕсли устройства с
шаблонами
E164 12345XXX регистрируются на шлюзе, когда они находятся в состоянии SRST, не должно быть необходимости в наличии диалогового пира, который перенаправляет вызов на сам шлюз. ![Response Signature]

]]>https://sla247.ru/forum/post/8767https://sla247.ru/forum/post/8767Wed, 18 Feb 2026 20:02:47 GMTУ нас есть 4 диалоговых партнера, соответствующих шаблону E164 12345XXX, которые в нормальных условиях работы отправляют вызовы на узлы CUCM. Теперь, поскольку ISR также действует как сервер SRST, был настроен один диалоговый пир, соответствующий вышеуказанному шаблону E164 12345XXX, но отправляющий вызовы на сам ISR, когда CUCM недоступен.

]]>https://sla247.ru/forum/post/8766https://sla247.ru/forum/post/8766Wed, 18 Feb 2026 20:02:46 GMTНе могли бы вы поделиться более подробной информацией об этом «У
нас есть диалоговый пир, подключающийся к самому ISR, когда активен режим SRST»? Что вы имеете в виду? ![Response Signature]

]]>https://sla247.ru/forum/post/8765https://sla247.ru/forum/post/8765Wed, 18 Feb 2026 20:02:45 GMTPS добавил команду
voice-class sip options-keepalive
к dial-peers с узлами CUCM, чтобы в случае недоступности CUCM из филиала эти dial-peers не сопоставлялись. Надеюсь, это должно помочь.

]]>https://sla247.ru/forum/post/8764https://sla247.ru/forum/post/8764Wed, 18 Feb 2026 20:02:44 GMTДжонатан, твой совет был верным: мне удалось удалить цикл вызовов, который я нашел в журналах, и предупреждение в CSSM исчезло. У нас есть dial-peer, подключающийся к самому ISR, когда активен режим SRST, и только для определенного номера этот dial-peer был сопоставлен, что привело к возникновению цикла. Исправил это, назначив приоритет такому dial-peer. Однако еще предстоит доработать настройки, так как предпочтение не всегда обеспечивает точное соответствие вызовов, предназначенных для SRST, и вызовов для CUCM. Спасибо!

]]>https://sla247.ru/forum/post/8763https://sla247.ru/forum/post/8763Wed, 18 Feb 2026 20:02:43 GMTСпасибо, Роджер, посмотрю документ, который ты прислал!

]]>https://sla247.ru/forum/post/8762https://sla247.ru/forum/post/8762Wed, 18 Feb 2026 20:02:42 GMTДля входящих вызовов рекомендуется использовать информацию в заголовке VIA для сопоставления входящего диалогового партнера, а затем, если вы не хотите рисковать возникновением циклов вызовов, я бы использовал либо группу диалоговых партнеров (Dial Peer Group, сокращенно DPG), либо COR для ограничения диалоговых партнеров, которые могут использоваться в каждом направлении. Ознакомьтесь с этим документом для получения дополнительной информации о том, как работает маршрутизация вызовов в IOS.
Объяснение маршрутизации вызовов Cisco IOS и IOS XE ![Response Signature]

]]>https://sla247.ru/forum/post/8761https://sla247.ru/forum/post/8761Wed, 18 Feb 2026 20:02:41 GMTPS Джонатан, как вы, наверное, уже поняли, у меня ограниченные навыки в области маршрутизации вызовов на ISR и dial-peers: не могли бы вы привести пример желаемого случая, когда «вызов соответствует VoIP dial-peers для входящих и исходящих сегментов вызова»?

]]>https://sla247.ru/forum/post/8760https://sla247.ru/forum/post/8760Wed, 18 Feb 2026 20:02:40 GMTСпасибо, Джонатан! Я бы очень хотел остаться на SIP, а возврат к H323 — это худший из возможных вариантов. Строка Mode border-element на самом деле не включена в конфигурацию. В выводе show logging было замечено сообщение «%CALL_CONTROL-6-CALL_LOOP: Входящий вызов имеет глобальный идентификатор, который уже присутствует в списке обрабатываемых в данный момент вызовов. Он отклоняется», которое также находится в процессе расследования. По вашему мнению, может ли это быть связано с упомянутым потреблением лицензии?

]]>https://sla247.ru/forum/post/8759https://sla247.ru/forum/post/8759Wed, 18 Feb 2026 20:02:39 GMTСпасибо, jrsteele21, обязательно посмотрю!

]]>https://sla247.ru/forum/post/8758https://sla247.ru/forum/post/8758Wed, 18 Feb 2026 20:02:38 GMTХорошее объяснение механизма приведено в этом руководстве.
Руководство по настройке Cisco Unified Border Element через Cisco IOS XE 17.5 — CUBE Smart Licensing [Cisco Unified Border Element] — Cisco Кто-то снял видео об этом
Cisco Unified Boarder Element (CUBE) 14 Обзор лицензирования

]]>https://sla247.ru/forum/post/8757https://sla247.ru/forum/post/8757Wed, 18 Feb 2026 20:02:37 GMTЛицензии 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.

]]>https://sla247.ru/forum/post/8756https://sla247.ru/forum/post/8756Wed, 18 Feb 2026 20:02:36 GMT