межкластерный магистральный канал (неуправляемый шлюзом) не регистрируется

[philip-cr]

Я нашел обходной путь для решения этой проблемы, но он мне показался очень странным. Мой межкластерный транк регистрируется только на моих узлах-подписчиках. Если я изменяю IP-адрес в транке на любой из моих узлов-издателей, он перестает маршрутизировать вызовы через него. Есть ли какие-либо идеи, что может быть причиной того, что Publisher не регистрируется для этого? SIP-транки работают нормально. Это тестовая среда, и у меня очень простая настройка: ![philipcr_0-1755198062352.png] ![philipcr_1-1755198188329.png]

[Jonathan Schulenberg]

Пожалуйста, пересмотрите свое решение и останьтесь при SIP. С соответствующим профилем безопасности SIP Trunk, профилем SIP и настройками транка он способен на все, на что способна устаревшая ИКТ, и даже больше. Настройка нового транка H.323 в 2025 году, на мой взгляд, безумие; это функция CCM 3.x более чем 20-летней давности. Это также потребует взаимодействия протоколов H.323 и SIP — всех IP-телефонов текущего поколения, CUBE или других SBC с PSTN, интеграции CUC SIP и т. д. — что часто создает проблемы, особенно между быстрым/медленным запуском H.323 и ранним/запоздалым предложением/медиа SIP. H.323 для Cisco мертв. Если это какое-то лабораторное упражнение, то, по-моему, вы также можете проверить разрешение DNS-имени хоста с каждой стороны, чтобы убедиться, что оно работает (удается ли
utils network host
из одного паба успешно разрешить другой паб?), или вместо этого настроить по IPv4-адресу. А если это не поможет, вам нужно будет извлечь трассировки CCM SDL с обеих сторон, чтобы понять, что происходит; возможно, PCAP.

[Roger Kallberg]

Полностью согласен с
@Jonathan Schulenberg
в том, что использование устаревшего ИКТ-транка, то есть H.323, не рекомендуется. SIP-транк между двумя кластерами CM — гораздо лучший выбор по всем причинам, перечисленным Джонатаном, и по многим другим.
@philip-cr
Есть ли конкретная причина, по которой вы настраиваете устаревший межкластерный транк? ![Response Signature]

[Marco Rojas Abarca]

Уважаемый Philip-cr,
я подозреваю, что здесь проблема в настройках. За годы работы я сталкивался с множеством случаев с похожими симптомами. Если моя память меня не подводит, IP-адреса назначения каждого транка должны соответствовать порядку серверов, настроенных в CM Group пула устройств, установленного в ICT противоположной стороны.
Итак, после просмотра фотографий, которые вы поделились, вот что у вас есть:
От ICT A --> ICT B у вас настроено следующее: Пул
устройств: Штаб-квартира Мстителей
Пункт назначения:
cucm-sub-b.abc.inc
От ICT B --> ICT A у вас настроено следующее: Пул
устройств: Главная база
Пункт назначения:
cucm-pub-a.abc.inc
Вам нужно проверить группу CM как штаб-квартиры Мстителей, так и главной базы и записать порядок, в котором они настроены друг относительно друга.
Затем в разделе
«IP-адрес/имя хоста
сервера
ICT A» необходимо добавить серверы в том же порядке, в котором они настроены в группе CM пула устройств Main Base.
Наконец, в разделе
«IP-адрес/имя хоста
сервера
ICT B» необходимо добавить серверы в том же порядке, в котором они настроены в группе CM пула устройств Avengers HQ.
Надеюсь, эта информация вам поможет.
С уважением,
Марко Р.

[Nithin Eluvathingal]

Во-первых, насколько я знаю, ICT-транки больше не используются в таких развертываниях.
Обычно для межкластерной связи рекомендуется использовать SIP-транки. Во-вторых, у вас есть возможность включить в конфигурацию ICT-транка как узел-издатель, так и узел-подписчик. В настоящее время вы добавляете только узел-издатель, но необходимо включить оба узла. Если я правильно помню, при использовании опции «Run on All Nodes» в сочетании с CM Group система обычно пытается зарегистрироваться с узлом, который появляется первым в списке CM Group. Существует специальный алгоритм, который управляет этим поведением, поэтому стоит ознакомиться с документацией Cisco, чтобы понять, как он работает. Поскольку ваша настройка включает только два узла, включение «Run on All Nodes» может быть не обязательным. ![Response Signature]

[Elliot Dierksen]

Включены ли там службы, необходимые для работы этого магистрального канала на издателе? Связан ли магистральный канал с группой менеджеров вызовов, в которую входит издатель? Если нет, доступен ли флажок «Запускать на всех узлах»?

[philip-cr]

Я не уверен, какие именно службы, но в плане работоспособности все работает. Да, группа менеджеров вызовов включает весь кластер на обоих кластерах. Также проверено, что все узлы работают.

[Roger Kallberg]

Интересно, что вы имеете в виду под фразой «
Если я изменю IP-адрес в магистрали на любой из моих узлов-издателей»? Может быть только один издатель, а вы упоминаете его во множественном числе. Это опечатка? ![Response Signature]

[philip-cr]

У меня есть 2 кластера, я создаю ICT без шлюза между двумя кластерами. Поэтому, если я указываю ICT на абонентский узел другого кластера, то все работает, но если я указываю их на узел издателя другого кластера, то все не работает.

[philip-cr]

Я еще больше сузил круг: ICT-A (запускается на всех узлах) ---> cucm-pub-b.abc.inc & ICT-B (запускается на всех узлах) ---> cucm-pub-a.abc.inc === НЕ РАБОТАЕТ
ICT-A (запускается на всех узлах) ---> cucm-sub-b.abc.inc & ICT-B (запускается на всех узлах) ---> cucm-sub-a.abc.inc === РАБОТАЕТ
ICT-A (запускается на всех узлах) ---> cucm-pub-b.abc.inc & ICT-B (запускается на всех узлах) ---> cucm-sub-a.abc.inc === A к B РАБОТАЕТ, B к A НЕ РАБОТАЕТ.
ICT-A (запускается на всех узлах) ---> cucm-sub-b.abc.inc & ICT-B (запускается на всех узлах) ---> cucm-pub-a.abc.inc === B к A РАБОТАЕТ, A к B НЕ РАБОТАЕТ.
Это как если бы получатель указывал на издателя, тогда вызов не удался бы...

[philip-cr]

Это последняя ситуация, которую я перечислил выше:
ICT-A (запускается на всех узлах) ---> cucm-sub-b.abc.inc & ICT-B (запускается на всех узлах) ---> cucm-pub-a.abc.inc === B к A РАБОТАЕТ, A к B НЕ РАБОТАЕТ.
Телефоны, зарегистрированные в кластере B, могут звонить в кластер A, но не наоборот. ![Pasted image 20250814123408.png] ![signal-2025-08-14-163215.png] ![signal-2025-08-14-163236.png] ![signal-2025-08-14-163307.png] ![signal-2025-08-14-163332.png] ![signal-2025-08-14-163351.png]

[philip-cr]

Я делаю это в лабораторных условиях только для курса CCNP.

[Roger Kallberg]

Прошло уже много лет с тех пор, как я прошел обучение CCNP, но если оно включает в себя устаревшие ICT-магистрали, я буду весьма удивлен, поскольку в реальных условиях они не используются уже много лет. Cisco в целом отказывается от H.323 и даже заявляет о прекращении поддержки этого протокола в IOS. Несложно предположить, что он будет прекращен и в CM. ![Response Signature]

[philip-cr]

Это лабораторная среда, проблем с DNS нет, все разрешаются. Я попробовал IPv4, но результат остался прежним. Работает только абонент.

[Roger Kallberg]

Служба Call Manager активирована и запущена на узлах Publisher? ![Response Signature]

[philip-cr]

Да, Call Manager работает на всех узлах, он также находится в группе Call Manager. (Я попробовал поместить Publisher на верхнюю позицию, но результат остался прежним).