Быстрая занятость при исходящих вызовах

[umeshplamthottam]

Всем привет! Сегодня я столкнулся с проблемой, с которой никогда раньше не сталкивался. У нас есть CUCM и PBX стороннего производителя, мы подключили обе PBX через SIP-транк. Я создал внутренний номер 2045 в PBX стороннего производителя и создал маршрут с тем же номером 2045, а затем выбрал транк в списке шлюзов/маршрутов. Каждый раз, когда я набираю цифру (2045), сразу же слышу сигнал «занято». Я проверил журналы SDL, но не нашел никаких следов. Кроме того, звонки по всем другим существующим шаблонам работают. Пожалуйста, помогите мне в этом.

[umeshplamthottam]

Привет всем, Спасибо всем за ответы и предложения, которые помогли устранить проблему. Основной причиной оказалась неправильная настройка сторонней АТС. Наш кластер состоит из одного издателя и одного подписчика. Изначально магистраль от сторонней АТС была настроена на издателя, а тестовый телефон был зарегистрирован на подписчика. Поскольку между сторонней АТС и подписчиком не было магистрального соединения, звонки не проходили. После повторной регистрации устройства на издателе звонки стали проходить успешно. Теперь мы также установили магистраль на подписчика, и все работает как положено.
Еще раз спасибо за вашу поддержку.

[Nithin Eluvathingal]

Если вы не видите следов этих вызовов в журналах, значит вызовы не обрабатываются.
Вы проверили все настройки, а не только настройки маршрута и SIP-транка? Они полностью работоспособны? Вы посмотрели группу маршрутов и список маршрутов, если вы их используете?
Кроме того, на некоторых АТС необходимо добавить маршрут, иначе вызовы из CUCM будут отклоняться на стороне АТС. Я часто сталкивался с этим у поставщиков АТС. Они утверждают, что это проблема CUCM, что вызовы с АТС на CUCM работают, а вызовы с CUCM на АТС не работают. Позже, когда они добавляют маршруты, входящие вызовы с CUCM на АТС работают. Поэтому убедитесь, что вы выполнили необходимые настройки на стороне АТС для приема вызовов с CUCM. ![Response Signature]

[umeshplamthottam]

Привет, Нитин, SIP-транк работает в полном объеме. Изначально они не добавили входящий маршрут, но теперь они настроили маршруты. Как ты уже упомянул, они могут звонить на CUCM, и наоборот, поэтому все подозревают, что проблема возникла на стороне CUCM. Я также попробовал настроить шаблон маршрута с RG&RL.

[Maren Mahoney]

Если трассировки SDL настроены правильно, попытка вызова должна быть зафиксирована, даже если вызов не удался. Каков уровень ваших трассировок? В старых версиях CUCM по умолчанию установлен уровень «Ошибка», который фиксирует только ошибки CUCM, а не полную информацию SDL. Еще одно, что следует проверить, — это то, что раздел для шаблона маршрута находится в пространстве поиска вызовов устройства или линии, с которой осуществляется вызов. Вызов не удается после набора первой цифры или после набора всех четырех цифр? Марен

[umeshplamthottam]

Когда я проверяю с помощью DNA, оказывается, что вызов будет направлен через тот же SIP-транк. Поэтому я не думаю, что есть какие-то проблемы с CSS и Partition.

[Nithin Eluvathingal]

В RTMT вы можете просматривать вызовы и сообщения SIP.
Журналы предоставят ответы о том, что происходит с этим вызовом. На CUCM
локально не настроен номер конфликта, верно? ![Response Signature]

[Maren Mahoney]

Хорошо, если ДНК говорит, что вызов маршрутизируется, следующим шагом будет просмотр трассировок, чтобы увидеть, что не работает. Я бы посмотрел данные RTMT Real Time, чтобы просмотреть лестничную диаграмму и увидеть, показывает ли она, в чем проблема. Марен

[ryabenne]

Когда вы набираете номер, вы снимаете трубку и набираете каждый номер по отдельности или набираете их как быстрый набор / Enbloc (все сразу)?
Это звучит так, будто у вас какая-то проблема с CSS / Partition, если вы не можете найти их в трассировках SDL.
Я видел, как клиенты должны были останавливать / запускать свои трассировки и убеждаться, что все настроено по умолчанию на уровнях трассировки, чтобы быть уверенными, что мы собираем нужные для них данные, так что вам, возможно, стоит попробовать это тоже.