Уважаемые знатоки,

Настройка АТС долгое время не требовалась и все накопленные знания подрастерялись изрядно. Сейчас же, ввиду грядущей смены дислокации, потребовалось плавно перейти от Е1 Вымпелком на SIP от МТС. С настройкой SIP до этого встречались только в теории. Настройку производим на UCP100, на которой есть VOIU(SW) для NETWORKING с "соседними" АТС по 0 и ISDN PRI с Е1 для выхода в город по 9.

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

PGM126 – Создать пользователя SIP по данным, выданным оператором, например:
Registration User ID: USER_ID@PROVIDER_SERVER_IP
Authentication User ID: USER_ID
Authentication User Password: USER_PASS
User ID Register: Register
User ID Usage: On
Ring Route Type: DID Conversion
DID Conversion Type: Modify using Flexible DID Conversion Table

Выбрать CO по таблице CO Line Overview из состава VOIU(SW) (Н-р 13-22)

PGM140 13-22
CO Type - DID
CO/IP Group - Объединить выбранные CO в отдельную группу

PGM117 - Дать доступ к группе CO SIP необходимым STA

PGM142 13-22
CO VoIP Mode - SIP&RTP-Packet-Relay

PGM133
Proxy Server Address: PROVIDER_SERVER_IP
Primary DNS Address: LOCAL_DNS_SERVER
Domain: PROVIDER_DOMAIN
Registration UID Range: INDEX созданного SIP пользователя в PGM126
SIP User ID Fixed Table Index: INDEX созданного SIP пользователя в PGM126
Use Outbound Proxy ON
Use rport method ON

Проверить SIP Trunk Status Overview
Index Proxy Address Domain COL Range SIP Group UID Range State UIDSEL
1 PROVIDER_SERVER_IP PROVIDER_DOMAIN 13 - 22 0 1 - 1 Registered UID_Index_1

Проверить SIP Registration Status Overview
Index Registration User ID SIP Status
1 USER_ID@PROVIDER_SERVER_IP Register - Registered

PGM111 – SIP USER TABLE INDEX установить INDEX созданного пользователя SIP для нужных STA

Проверить SIP UID Alloc Status Overview - должны быть перечислены STA, установленные в P111
Index Station
1 4065,

PGM231 Flexible DID Conversion Настроить обработку входящих

В результате застряли на том, что звонок с указанной STA на внешний номер даёт отбой со следующей трассировкой:
865 13.747108 10.104.0.2 212.188.36.179 SIP/SDP 1145 Request: INVITE sip:89192205568@reg.aa.mts.ru |
871 13.772570 212.188.36.179 10.104.0.2 SIP 421 Status: 100 Trying |
872 13.778639 212.188.36.179 10.104.0.2 SIP 627 Status: 407 Proxy Authentication Required |
873 13.780324 10.104.0.2 212.188.36.179 SIP 593 Request: ACK sip:89192205568@reg.aa.mts.ru |
874 13.781964 10.104.0.2 212.188.36.179 SIP/SDP 1366 Request: INVITE sip:89192205568@reg.aa.mts.ru |
876 13.817268 212.188.36.179 10.104.0.2 SIP 421 Status: 100 Trying |
877 13.837397 212.188.36.179 10.104.0.2 SIP/SDP 785 Status: 183 Session Progress |
885 13.883219 212.188.36.179 10.104.0.2 SIP 446 Status: 487 Request Terminated |
886 13.884806 10.104.0.2 212.188.36.179 SIP 564 Request: ACK sip:89192205568@reg.aa.mts.ru |

При звонке на SIP номер (во Flexible DID Conversion настроена передача на STA) звонок приходит, входящий номер отражается, звука нет в обе стороны.

Прошу помочь разобраться что пропустили...

У вас в 133 проге Use rport method ON. А Firewall IP Apply OFF?

В 133 проге я бы выставил для Proxy Registration Timer 600 сек.

В 132 программе прописан RTP Packet firewall ip и firewall ip для всех модулей VoIP которые используются?

Исправил - кажется rport method ON было включено по чьему-то примеру. Убрал, оставил rport method OFF, Filrewall IP Apply ON

Proxy Registration Timer установил 600 сек

Изменений нет.

Да, проверил, спасибо. Включено давно, т.к. VoIP модули использовались ранее (да и сейчас, но уже частично, т.к. часть СО выделены под SIP) для NETWORKING с другими АТС с другими Firewall.

А какими должны быть настройки CO VoIP Mode в PGM142? Сейчас установлены для группы SIP линий SIP & RTP Packet Relay. Но понимания, почему, например, не SIP Only нет, к сожалению...

Эта настройка указывает какие протоколы может использовать модуль VoIP.
RTP Packet Relay - это работа любых ip телефонов за NAT. SIP - работа с SIP провайдером. H323 - работа по H323 протоколу, Common- любые протоколы.

На голос по SIP это не влияет

Снифф сможете снять? надо посмотреть, что вы оправляете в Connection information в Invite

Большое спасибо за разъяснение, всё, как всегда, логично)

Если я правильно Вас понял, то вот:

Message Body
Session Description Protocol
Session Description Protocol Version (v): 0
Owner/Creator, Session Id (o): iPECS-UCP 52 52 IN IP4 84.17.236.156
Session Name (s): iPECS-UCP SIP
Connection Information ©: IN IP4 84.17.236.156
Connection Network Type: IN
Connection Address Type: IP4
Connection Address: 84.17.236.156
Time Description, active time (t): 0 0
Media Description, name and address (m): audio 10126 RTP/AVP 8 0 101
Media Attribute (a): rtpmap:8 PCMA/8000
Media Attribute (a): rtpmap:0 PCMU/8000
Media Attribute (a): rtpmap:101 telephone-event/8000
Media Attribute (a): fmtp:101 0-15
Media Attribute (a): sendrecv
[Generated Call-ID: 4b965cd0-200680a-13c4-65014-6480d-242f31e6-6480d]

Ну голос идет на 84.17.236.156, если это правильный адрес, то может RTP трафик блокирует маршрутизатор. Можно настроить проброс портов на маршрутизаторе.
По умолчанию используются порты:
Нажмите для просмотра прикрепленного файла

Спасибо, будем изучать.

Вы работаете с регистрацией. В таком случае я в последнее время использую rport method, при rport method ON Filrewall IP Apply должен быть OFF. В таком варианте порты на роутере можно не пробрасывать, голос ходит без проблем. Если роутер, конечно, ничего не блокирует...

Спасибо, установил rport method ON и Firewall IP Apply OFF.

В процессе всех манипуляций потеряли регистрацию SIP Status: Register - Terminated и ни при каких значениях внесенных чуть ранее изменений не удаётся её вернуть пока. Вернусь, как только вернём регистрацию...

И снова здравствуйте

Регистрация пропала по не совсем очевидным причинам (правило брандмауэра с инспектором протокола по неведомой причине блокировало трафик), но таки была успешно возвращена.

Видимо после установки rport method ON Firewall IP Apply OFF появился звук с двух сторон при входящем звонке.

Но вот исходящие звонки не поддаются.

Картина следующая:

Нажмите для просмотра прикрепленного файла

Из картинки мало что можно понять. Нужен сам файл сниффера.

Fixed Table Index вы указали, но не увидел, что в 133 проге в разделе ID Individuality для From ID вы указали Fixed Table.

Пардон, не закрепил. Прилагаю (добавил .txt в конце, чтобы загрузить файл через форму форума.).

Нажмите для просмотра прикрепленного файла

Вы верно подметили, не указал Fixed Table, хотя видел это в одном из алгоритмов на форуме и в http://www.artcom.ru/_files/Download/Docs/...res_Rev1.0).rar , а т.к. не понял, что конкретно это определяет - оставил по умолчанию. Этот пункт отвечает за то, откуда берется Contact Display Name верно? Это поле имеет существенное значение для исходящих? Сейчас в поля Contact Display Name и Contact Number в PGM126 "от балды" вписан DEF номер, выданный к SIP оператором, т.к. МТС не дал никаких указаний на этот счёт.

Сейчас указал PGM133/ID Individuality/From ID = Fixed Table. Проверить результат, к сожалению, смогу только завтра.

Собственно, поле From у вас не пустое. Вызов отменяет провайдер. Почему, не понял с лёту.
Попробуйте в 126 проге для Registration User ID указать 9107416331(без U8160)@PROVIDER_SERVER_IP.
Contact Number и Contact Display Name в 126 проге я никогда не заполняю, проблем не наблюдалось.

PGM133/ID Individuality/From ID определяет, что передавать в поле From.

Если изменить Registration User ID таким образом, то слетает регистрация: SIP Status - Register Terminated



Вас понял, поля Contact Number и Contact Display Name в PGM126 очистил.

Понятно.

А Connection information 10.104.0.2 не может быть причиной reject от МТС? Это же не белый ip?
Сниф снимали до или после фаервола?

Докладываю - без Contact Number теряется входящая связь. Если Contact Number указан, то входящая связь работает.

Сниф снят после файервола с самой станции через Packet Capture. 10.104.0.2 - адрес АТС в локальной сети. Может на это как раз влияет настройка Use rport method ON и Firewall IP Apply OFF& Но, насколько я помню, в обратной ситуации также исходящая связь не работала.

Ну, если надо, значит надо!

А с провайдером не общались? Что они говорят по исходящей?

Тогда вопрос: на маршрутизаторе включен ALG SIP? Провайдер же не знает адреса из вашей локальной сети.

В снифе, вроде, все благополучно поступает от прова на 10.104.0.2. В том числе и RTP с 212.188.36.187.

Конкретно этой настройки на маршрутизаторе нет, но если исходить из её сути, то никаких препятствий для соединений нет - пакеты доходят до адресатов в обе стороны.

Задал вопрос, но, честно говоря, не ожидаю какой-то конкретики. Скорее всего, будет что-то вроде "С нашей стороны всё в порядке"... Но я надеюсь на лучшее

Можно еще попробовать этот аккаунт на каком-нибудь софт-фоне на компе, без АТС... И, опять же, сниф снять исходящего.

Это работает не так. При включении опции ALG, маршрутизатор лезет в тело пакета SIP и меняет внутренний адрес вашей сети на свой внешний. Если вы регистрируетесь с одного ip адреса, а оператору в конекшен информейшн отсылаете другой, то оператор может считать этот запрос некорректным. В этом случае либо прописывают Firewall ip на АТС, либо включают ALG SIP на маршрутизаторе.
У вас МТС шлет сообщение, что вызов отклонил оператор. Значит вы шлете ему некорректные данные.
Ну и как сказал Dron, проверьте сначала работу с МТС на любом софтфоне

Понятно, спасибо. В нашем случае возможности управления этой функцией нет. Тем не менее все рекомендации производителя файерволла на этот счёт выполнены. Какие-то изменения ("Мы всё настроили ещё раз") внесены на стороне оператора, и исходящая и входящая связь работает.

Большое спасибо за помощь!

Неожиданно помогло! Ответили, что "перенастроили у себя" и всё волшебным образом заработало.

Искренне благодарю за помощь.