Перейти к содержимому
Калькуляторы

AS5350/5400, Busy с PRI, и 183 Progress

Добрый день, коллеги.

 

Никто не сталкивался?

 

Есть Cisco 5350, 5400. На них прописан выход в PRI, и масса диалпиров (IP-телефонов и Asterisk'ов) по SIP. Диалпиры звонят через 5350 в PSTN.

 

Фокус в том, что когда диалпир звонит на занятый номер в PSTN, с PSTN приходит Cause-Code 17 (BUSY). Но эта зараза ака Cisco не передает в SIP 486 Busy, а делает 183 Progress, и начинает проигрывать туда Busy-тон. Вследствие чего отследить занятость канала на тех же Asterisk'ах возможным не представляется, они видят состоявшийся вызов.

 

Что бы такого с этими граблями сделать, чтобы циска не играла тоны, а отдавала нормальный Cause-Code в SIP?

Изменено пользователем Alex/AT

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Что бы такого с этими граблями сделать, чтобы циска не играла тоны, а отдавала нормальный Cause-Code в SIP?

А у вас маппинга кодов pstn-to-sip не настроено?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Нет, всё в дефолтах. Вообще, похоже, что оно зачем-то проключает канал, по типу ringback. Как отключить - пока непонятно.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Окей, спасибо, уже понял, что не баг, а фича :)

 

Если сдизейблить, всякие "абонент временно недоступен" перестанут работать, а этого не хочется.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

А почему "абонент временно недоступен" перестанет работать?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Потому-что оно работает как раз через ирли медиа. Как лечить честно говоря не помню. Помню ковырялся в прогресс индикаторах, в том числе недокументированных.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Так если это "ирли медиа", откуда бизи взялся то?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Ну тут налицо какая-то грабля с некорректной обработкой этого бизи. То есть кошке пришло бизи, но коннект не дропается и она бизитон играет в ирлимедиа. Обычно такие залепухи бывают из-за беды с прогрессами и алертами. То бизи нету вовсе, то рингбэка, то еще беда какая.

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Тогда надо бы Q.931 + VoIP посмотреть-подебажить.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

хм... а можно конфиг в студию. а именно dial-peer как pots так и voip?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Конфиг большой, вот два пира к примеру, которые "общаются":

 

dial-peer voice *** pots
trunkgroup all
description IN-OUT-Default
translation-profile outgoing T-OUT
huntstop
destination-pattern ***
incoming called-number .T
no digit-strip
direct-inward-dial
forward-digits all
!
dial-peer voice *** voip
description In-Ast
huntstop
destination-pattern .T
voice-class codec 1
session protocol sipv2
session target ipv4:*.*.*.*
dtmf-relay rtp-nte
no vad
!

 

Ну тут налицо какая-то грабля с некорректной обработкой этого бизи. То есть кошке пришло бизи, но коннект не дропается и она бизитон играет в ирлимедиа.

Тогда надо бы Q.931 + VoIP посмотреть-подебажить.

Подебажили... Фокус в том, что бизя прилетает с POTS с PI 8, т.е. виновник торжества всё-таки удалённая сторона. Жалко, что у кошки нет детекта бизитонов :(

Изменено пользователем Alex/AT

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Включили disc_pi_off на voice-port'ах одного из шлюзов, бизе помогло, "абонентов временно недоступных" тоже не зарубило - там другой код, Congestion. Хитровыделанные отбойники, конечно, убьются, но будем смотреть - по итогам весь важный функционал на месте, извращения не пройдут, мб и хорошо.

Изменено пользователем Alex/AT

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

покажите настройки Serial interface

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

У всех сериальников настройки одинаковые.

 

interface Serial3/0:15
no ip address
encapsulation hdlc
trunk-group all
isdn switch-type primary-net5
isdn timer T310 30000
isdn timer T321 40000
no cdp enable

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

попробуйте на исходящий диалпир поставить:

 

progress_ind setup enable 3

progress_ind progress enable 8

progress_ind connect enable 8

progress_ind disconnect enable 8

 

и уберите disc_pi_off

Не уверен что поможет. Но попробуйте. У меня по крайней мере так стоит. Вроде я именно с этим и копался года 4 назад.

и ещё добавьте на сериал интерфейс

 

isdn incoming-voice modem // тут от серии AS зависит

isdn send-alerting

isdn negotiate-bchan // это так от сталкновения каналов. :)

isdn sending-complete

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Спасибо за подсказку. Будем тестировать.

Навскидку, скорее всего не поможет, поскольку на другом шлюзе полностью указанная Вами конфигурация, только нет isdn negotiate-bchan и send-alerting/sending-complete.

На данный момент и там включили disc_pi_off на voice-port'ах, после чего отдача бизи в SIP пришла в норму. Проверим предложенный Вами вариант - вдруг поможет.

Изменено пользователем Alex/AT

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.