предупреждение о нехватке лицензий «CUBE v14 Trunk Standard Session»
-
Спасибо, 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]
Здравствуйте! Похоже, вам интересна эта беседа, но у вас пока нет учетной записи.
Вы устали просматривать одни и те же посты каждый раз, когда заходите на сайт? После регистрации, вам не придётся искать обсуждения в которых вы принимали участие, настройте уведомления о новых сообщениях так как вам это удобно (по электронной почте или уведомлением). У вас появится возможность сохранять закладки и ставить лайки постам, чтобы выразить свою благодарность другим участникам сообщества.
С вашими комментариями этот пост может стать ещё лучше 💗
Зарегистрироваться Войти