[Lobster]

Всем привет.

Нужна помощь в решении проблем Asterisk+Cisco (4351) one-way RTP.
Проблема появилась после замены Cisco 2851 на Cisco 4351.
Есть 4 транка от поставщика услуг, до замены все 4 транка работали исправно. Настройки у всех идентичные (кроме логин/пароль), проходят все транки через идентичное оборудование в интернет.
После замены Cisco на 2х транках перестал ходить голос во внутрь...
На обоих Cisco отключен SIP ALG настроен НАТ на порт 5060 и разрешен пропуск пакетов UDP во внутрь...
Но на 4351 не работает входящая на 2х транках, на 2851 работает.
Т.е. ничего не меняя просто меняем железку с 2851 на 4351 - не работает, меняем обратно - работает.
Разница на роутерах только в том, что на одном Firewall CBAC, на другом ZBF.

Если пробросить пачку UDP портов через НАТ в сторону астериск, то голос начинает ходить. Но такая "портянка" пробросов в конфиге - это не красиво, да и не правильно...

 

Конфиг старой cisco 2851 IOS:

no ip nat service sip udp port 5060
ip nat inside source static udp int_ip 5060 ext_ip 5060

ip access-list extended WAN_to_LAN
 permit udp host voip_prov_ip host ext_ip eq 5060
 permit udp any host ext_ip range 10000 10500

 

Конфиг новой cisco 4351 IOS XE:

class-map type inspect match-all CLASS-WAN-TO-LAN-VOIP
 match access-group name VOIP-PASS
class-map type inspect match-any CLASS-LAN-TO-WAN
 match protocol http
 match protocol https
 match protocol dns
 match protocol icmp
 match protocol smtp
 match protocol pop3
 match protocol ftp
 match protocol ssh
 match protocol sip
 match protocol tcp
 match protocol udp
class-map type inspect match-all CLASS-WAN-TO-LAN
 match access-group name ACL-WAN-TO-LAN
!
policy-map type inspect PMAP-LAN-TO-WAN
 class type inspect CLASS-LAN-TO-WAN
  inspect
 class class-default
  drop
policy-map type inspect PMAP-WAN-TO-LAN
 class type inspect CLASS-WAN-TO-LAN-VOIP
  pass
 class type inspect CLASS-WAN-TO-LAN
  inspect
 class class-default
  drop
!
zone security WAN
zone security LAN
zone-pair security LAN-TO-WAN source LAN destination WAN
 service-policy type inspect PMAP-LAN-TO-WAN
zone-pair security WAN-TO-LAN source WAN destination LAN
 service-policy type inspect PMAP-WAN-TO-LAN

no ip nat service sip udp port 5060
ip nat inside source static udp int_ip 5060 ext_Ip 5060 extendable

ip access-list extended VOIP-PASS
 permit udp any host int_ip range 10000 10500
 permit tcp host voip_prov_ip host int_ip eq 5060
 permit udp host voip_prov_ip host int_ip eq 5060

 

Настройка всех VOIP-транков на астерикс:

username=user
type=peer
trunkstyle=voip
secret=****
registersip=no
registeriax=no
qualify=yes
promiscredir=yes
port=5060
host=sip.prov.com
hassip=yes
hasiax=no
hasexten=no
fromuser=user
disallow=all
allow=alaw&ulaw

 

[SUrov_IBM]

Lobster, здравствуйте.

 

В 20.04.2022 в 15:21, Lobster сказал:

На обоих Cisco отключен SIP ALG

К сожалению, я не знаком с IOS XE, просто предположение - Вы уверены, что на CISCO 4351 SIP ALG полностью отключен?

Если верить документации, то "no ip nat service sip" действительно отключает SIP ALG, но в Вашей конфигурации присутствует "inspect match protocol sip".

 

Предположение: согласно документации, в IOS XE появилось несколько расширенных методов SIP ALG, один из них PRACK (rel1xx). В моём понимании, PRACK больше "мешается" при взаимодействии SIP. Если SIP ALG отключен не полностью, возможно он влияет на трансляцию медиаканалов (RTP) через NAT, просматривая SDP в сообщении PRACK.

 

В 20.04.2022 в 15:21, Lobster сказал:

Если пробросить пачку UDP портов через НАТ в сторону астериск, то голос начинает ходить. Но такая "портянка" пробросов в конфиге - это не красиво, да и не правильно

Не понимаю, чем Вас смущает проброс портов для медиаканалов (RTP) через NAT c указанием нужного диапазона, тем более у Вас корректно работает такой вариант?

[Lobster]

@SUrov_IBM 

"inspect match protocol sip" - появилось во время экспериментов, когда этой строки не было проблема была полностью та же, т.е. после добавления этой строки ничего не изменилось.

 

Сейчас много читаю по этой теме, но до PRACK еще не дошел, может что то и с ним.

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

 

В 21.04.2022 в 01:18, SUrov_IBM сказал:

Не понимаю, чем Вас смущает проброс портов для медиаканалов (RTP) через NAT c указанием нужного диапазона, тем более у Вас корректно работает такой вариант?

Во-первых - это постоянные дырки из внешнего мира в сторону астериска. А во вторых диапазоном НАТ не сделаешь, только для каждого порта отдельная строчка, а так как у нас открыто на астериске 500 портов.... то это 500 строк - очень не красивая портянка получается...

 

 

Вчера вечером немного подкорректировал конфиг, добавил инспектирование SIP на вход и включил ALG, но ничего не изменилось... (Благо хоть рабочие каналы не отвалились)

Теперь конфиг выглядит так:

class-map type inspect match-all CLASS-WAN-TO-LAN-VOIP
 match access-group name VOIP-PASS
class-map type inspect match-any CLASS-LAN-TO-WAN
 match protocol http
 match protocol https
 match protocol dns
 match protocol icmp
 match protocol smtp
 match protocol pop3
 match protocol ftp
 match protocol ssh
 match protocol sip
 match protocol tcp
 match protocol udp
class-map type inspect match-all CLASS-WAN-TO-LAN
 match access-group name ACL-WAN-TO-LAN

---Добавлено---
class-map type inspect match-all CLASS-WAN-TO-LAN-INSPECT-SIP
 match protocol sip
---Добавлено---

!
policy-map type inspect PMAP-LAN-TO-WAN
 class type inspect CLASS-LAN-TO-WAN
  inspect
 class class-default
  drop
policy-map type inspect PMAP-WAN-TO-LAN
---Добавлено---
 class type inspect CLASS-WAN-TO-LAN-INSPECT-SIP
  inspect
---Добавлено---
 class type inspect CLASS-WAN-TO-LAN-VOIP
  pass
 class type inspect CLASS-WAN-TO-LAN
  inspect
 class class-default
  drop
!
zone security WAN
zone security LAN
zone-pair security LAN-TO-WAN source LAN destination WAN
 service-policy type inspect PMAP-LAN-TO-WAN
zone-pair security WAN-TO-LAN source WAN destination LAN
 service-policy type inspect PMAP-WAN-TO-LAN


---Убрано---
no ip nat service sip udp port 5060
---Убрано---


ip nat inside source static udp int_ip 5060 ext_Ip 5060 extendable

ip access-list extended VOIP-PASS
 permit udp any host int_ip range 10000 10500
 permit tcp host voip_prov_ip host int_ip eq 5060
 permit udp host voip_prov_ip host int_ip eq 5060

 

Но... в работе РТП ничего не изменилось.. Все так же 2 канала работают, 2 нет....

Идей больше нет... =(

Изменено 21 апреля, 2022 пользователем Lobster

[SUrov_IBM]

Lobster, здравствуйте.

 

В 21.04.2022 в 08:57, Lobster сказал:

Идей больше нет

Вы уже собрали рабочую схему, остальное - Ваша тяга к познаниям, для этого можно организовать тестовый стенд, например VM Cisco CSR и Asterisk, не взаимодействуя с рабочим проектом.

 

В 21.04.2022 в 08:57, Lobster сказал:

Во-первых - это постоянные дырки из внешнего мира в сторону астериска

В Вашем случае, Asterisk выступает в роли UA клиента, IP адрес АТС оператора заведомо известен, ограничить доступа можно силами ACL ip access-group на интерфейсе CISCO.

 

В 21.04.2022 в 08:57, Lobster сказал:

500 строк - очень не красивая портянка получается

С эстетической точки зрения, только Вы наблюдаете конфигурацию маршрутизатора и в принципе, не имеет значения одна строка её определяет или "портянка", если это не приводит к дополнительным накладным расходам (отнимает ресурсы). Диапазона портов медиаканалов (RTP) можно скорректировать со стороны Asterisk, ограничив до минимума, в любом случае, он определяется в SDP, во время согласования вызова с любой из сторон.

 

В 21.04.2022 в 08:57, Lobster сказал:

Единственная зацепка - это в рабочем канале есть запись Record-route на голосовой сервер, а в нерабочем канале эта запись отсутствует

Возможно, но это не точно, в Вашем случае SIP ALG IOS XE "чувствует" (если верить документации - SIP ALG Record-Route Header Support: SIP application-level gateway (ALG) parses the Contact header and uses the IP address and the port value in the Contact header to create a firewall pinhole and a Network Address Translation (NAT) door) сигнализацию и опираясь на неё создаёт трансляцию медиаканалов (RTP) через NAT, а там где Record-Route отсутствует, трансляция UDP портов не создаётся.

 

В 21.04.2022 в 08:57, Lobster сказал:

добавил инспектирование SIP на вход и включил ALG, но ничего не изменилось

Выскажу свое менее - не стоит создавать дополнительные сущности, там где этого можно избежать, т.е. разрешать маршрутизатору анализировать / инспектировать телефонную сигнализацию, его первоочередная роль - маршрутизация IP L3 / NAT. Телефонией, даже в IP представлении,  должна заниматься АТС. Чтобы, при смене маршрутизатора, телефонии это коснулось меньше всего.

 

 

P.S. Для себя, я давно решил, что если CISCO и будет заниматься обработкой VoIP сигнализации для маршрутизации вызовов, обязательно должна быть ограничена взаимодействием только с доверенными (разрешёнными) по IP партнёрами. Разрешёнными, именно на уровне фильтрации IP по ACL, а не по собственному механизму проверки подлинности в сигнализации (ip address trusted list, SIP ALG). Что позволяет избежать фрод запросов, генерируемых фрод скриптами в публичной сети, которые легко "кладут" маршрутизатор CISCO "на лопатки". ;)

[Lobster]

В 21.04.2022 в 14:31, SUrov_IBM сказал:

В Вашем случае, Asterisk выступает в роли UA клиента, IP адрес АТС оператора заведомо известен, ограничить доступа можно силами ACL ip access-group на интерфейсе CISCO.

Ну так ограничение и стоит на порт 5060 только с ИП оператора... RTP не ограничишь, так как идти может с любого ИП.

 

В 21.04.2022 в 14:31, SUrov_IBM сказал:

С эстетической точки зрения, только Вы наблюдаете конфигурацию маршрутизатора и в принципе, не имеет значения одна строка её определяет или "портянка", если это не приводит к дополнительным накладным расходам (отнимает ресурсы). Диапазона портов медиаканалов (RTP) можно скорректировать со стороны Asterisk, ограничив до минимума, в любом случае, он определяется в SDP, во время согласования вызова с любой из сторон.

Ну.. постоянно открытые порты в сторону Астериск тоже не есть хорошо и тут ACLем уже не ограничишь, так как RTP может идти откуда угодно.

 

В 21.04.2022 в 14:31, SUrov_IBM сказал:

Возможно, но это не точно, в Вашем случае SIP ALG IOS XE "чувствует" (если верить документации - SIP ALG Record-Route Header Support: SIP application-level gateway (ALG) parses the Contact header and uses the IP address and the port value in the Contact header to create a firewall pinhole and a Network Address Translation (NAT) door) сигнализацию и опираясь на неё создаёт трансляцию медиаканалов (RTP) через NAT, а там где Record-Route отсутствует, трансляция UDP портов не создаётся.

Я тоже к этому склоняюсь... Но поставщик все равно с этим сделать ничего не может.. Поправить конфигурацию своего оборудования, чтобы оно включало эту запись в датаграмму

 

В 21.04.2022 в 14:31, SUrov_IBM сказал:

Выскажу свое менее - не стоит создавать дополнительные сущности, там где этого можно избежать, т.е. разрешать маршрутизатору анализировать / инспектировать телефонную сигнализацию, его первоочередная роль - маршрутизация IP L3 / NAT. Телефонией, даже в IP представлении,  должна заниматься АТС. Чтобы, при смене маршрутизатора, телефонии это коснулось меньше всего.

Вот это не понял. Вы тоже придерживаетесь того, что SIP ALG нужно, все таки, отключать?

[SUrov_IBM]

Lobster,

 

В 21.04.2022 в 15:54, Lobster сказал:

Ну так ограничение и стоит на порт 5060 только с ИП оператора... RTP не ограничишь, так как идти может с любого ИП.

В 21.04.2022 в 15:54, Lobster сказал:

и тут ACLем уже не ограничишь, так как RTP может идти откуда угодно.

Выступая в роли клиента, Ваш Asterisk регистрируется на операторском Softswitch (или на чём-то близком по смыслу), который с огромной долей вероятности, совмещает в себе Mediaproxy для медиаканалов (RTP) и скорей всего Softswitch/Mediaproxy имеют одинаковый IP адрес, возможно соседние (в пределах сети оператора), если располагаться на разных устройствах. Более точно, это можно посмотреть в SIP сигнализации или уточнить у оператора.

 

Просто, в случае подключения к оператору, медиаканалы (RTP) "бегают" в сторону операторской АТС, а не напрямую, к IP-телефону соседа в другой галактической сети, как это принято рисовать в учебнике (где сигнализация идёт через Proxy сервер, а RTP напрямую между UA-UA). Поэтому, порты медиаканалов (RTP) можно ограничить силами ACL ip access-group до конкретного IP адреса или небольшой группы адресов.

 

В 21.04.2022 в 15:54, Lobster сказал:

Вот это не понял. Вы тоже придерживаетесь того, что SIP ALG нужно, все таки, отключать?

Да, я придерживаюсь того, что если Вы клиент и находитесь за NAT, то функционал SIP ALG нужно полностью отключать. Потому, что сегодня у Вас один маршрутизатор, завтра другой (может быть даже виртуальный). ;)

Если бы Ваш SIP сервер находился за NAT и потребовалось вывести его в публичный Интернет, чтобы на нём регистрировались клиенты, тогда можно/нужно было бы задуматься про SBC (Session Border Controller) или какие-то подобные грабли.

[Lobster]

В 21.04.2022 в 16:57, SUrov_IBM сказал:

Выступая в роли клиента, Ваш Asterisk регистрируется на операторском Softswitch (или на чём-то близком по смыслу), который с огромной долей вероятности, совмещает в себе Mediaproxy для медиаканалов (RTP) и скорей всего Softswitch/Mediaproxy имеют одинаковый IP адрес, возможно соседние (в пределах сети оператора), если располагаться на разных устройствах. Более точно, это можно посмотреть в SIP сигнализации или уточнить у оператора.

 

Просто, в случае подключения к оператору, медиаканалы (RTP) "бегают" в сторону операторской АТС, а не напрямую, к IP-телефону соседа в другой галактической сети, как это принято рисовать в учебнике (где сигнализация идёт через Proxy сервер, а RTP напрямую между UA-UA). Поэтому, порты медиаканалов (RTP) можно ограничить силами ACL ip access-group до конкретного IP адреса или небольшой группы адресов.

Нет, голосовые сервера другие - это 100%. Об этом говорит поставщик да и я вижу в SIP сигнализации.

При чем для 2 рабочих линий - один RTP IP, для 2х нерабочих другой RTP IP.

 

Еще интересно то, что циска нат сессии открывает.... и правильно открывает. Что для рабочих линий, что для не рабочих. Это видно по команде ip nat translations - там именно то, что в SIP пакетах. Единственное в SIP пакете порт возврата ко мне указан UDP порт астериска, а не внешний порт циски, т.е. inside local, а не inside global. Но такое поведение одинаково как для рабочих каналов, так и не для рабочих. В общем не понятно где теряются эти датаграммы... но на ЛАН интерфейс циски они не выходят...

 

ЗЫ: SIP ALG отключил (весь свой рабочий опыт без него работал, тут включил уже от безысходности) и вернул конфиг к тому, что в первом посте.

Изменено 21 апреля, 2022 пользователем Lobster

[SUrov_IBM]

Lobster,

 

В 21.04.2022 в 17:10, Lobster сказал:

Нет, голосовые сервера другие - это 100%. Об этом говорит поставщик да и я вижу в SIP сигнализации.

При чем для 2 рабочих линий - один RTP IP, для 2х нерабочих другой RTP IP.

Хорошо, IP адреса Mediaproxy располагаются отдельно от сервера сигнализации, но IP адреса Mediaproxy известны и насколько я понял, их несколько (пара), а не произвольное значение в публичной сети Интернет? Поэтому, силами ACL можно настроить ограничение до небольшой группы IP адресов Mediaproxy, чтобы проброс RTP не "светил" во всю галактику. ;)

 

В 21.04.2022 в 17:10, Lobster сказал:

Единственное в SIP пакете порт возврата ко мне указан UDP порт астериска, а не внешний порт циски, т.е. inside local, а не inside global. Но такое поведение одинаково как для рабочих каналов, так и не для рабочих. В общем не понятно где теряются эти датаграммы... но на ЛАН интерфейс циски они не выходят...

Боюсь соврать, поскольку давно не работал со "Звёздной АТС". В файле sip.conf, было несколько параметров отвечающие за взаимодействие через NAT и в Вашем случае, нужно произвести корректировку со стороны Asterisk, чтобы при регистрации, в сигнализации указывался IP адрес внешнего интерфейса CISCO и далее через статический проброс, с выключенным SIP ALG, уже попадал на Asterisk.

[Lobster]

В 21.04.2022 в 17:51, SUrov_IBM сказал:

Хорошо, IP адреса Mediaproxy располагаются отдельно от сервера сигнализации, но IP адреса Mediaproxy известны и насколько я понял, их несколько (пара), а не произвольное значение в публичной сети Интернет? Поэтому, силами ACL можно настроить ограничение до небольшой группы IP адресов Mediaproxy, чтобы проброс RTP не "светил" во всю галактику. ;)

Да, согласен, это можно сделать. Это я вижу только 2 ИП адреса, но как утверждает поставщик они могут динамически меняться, а это периодические проблемы из-за ACL, потому как надо будет вносить новые адреса.

 

В 21.04.2022 в 17:51, SUrov_IBM сказал:

Боюсь соврать, поскольку давно не работал со "Звёздной АТС". В файле sip.conf, было несколько параметров отвечающие за взаимодействие через NAT и в Вашем случае, нужно произвести корректировку со стороны Asterisk, чтобы при регистрации, в сигнализации указывался IP адрес внешнего интерфейса CISCO и далее через статический проброс, с выключенным SIP ALG, уже попадал на Asterisk.

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

 

 

Хотя у меня закрадываются подозрения что это БАГ в циско. Залил новую прошивку, была 16.06.5, залил 16.09.8 - вечером перезагружусь на новую - посмотрим что будет, может пофиксится.

[Lobster]

Докопался я в итоге до истины..... Дело в портах.

РТП сервер шлет медиа-поток не на тот порт. Проблема, видимо, в циско.. и ее не корректном инспектировании на этой прошивке.

На 28/2951 IOS смотрит внутрь пакета SIP INVITE и видит там исходящий порт астериска, допустим, 10333 и открывает у себя в НАТ этот же порт на медиапоток: получается нат трансляция ext_global: global_ip:10333, local_ip asterisk_ip:10333 и медиасервер шля поток на внешний порт попадает на астер по открытой "один-к-одному по портам" НАТ трансляции. (10333, напоминаю, указан внутри СИП Инвайта)

На 4300 IOS XE инспекция так не отрабатывает (в этом, походу и есть баг) она не открывает НАТ на том порту, который указан в СИП Инвайт, а открывает свой порт (ну.. первый свободный, наверно), например 6084 и получается НАТ трансляция  ext_global: global_ip: 6084, local_ip asterisk_ip:10333...

Теперь о медиасерверах.

Те линии, которые у нас не работают, висят на одном медиасервере и этот медиа сервере берет порт на отправку из пакета SIP INvite, получается он отправляет поток на порт 10333, соответственно на IOS он попадает в открытую НАТ-дырку и доходит до Астера, а на IOS XE открыт порт, которого нет в SIP Invite, и медиапоток, отправленный на 10333 бьется в стену... так как IOS XE открыла дырку на порту 6084...

Вопрос - как же работают те линии, которые все таки работают?! - очень просто, там медиасервер настроен чуть умнее: он просто шлет 2 потока на порт, с которого пришло соединение 6084 от циски и на тот порт, который указан в SIP Invite 10333 и один из потоков, соответственно проходит через нат, который отправлен на внешний порт циски, который она открыла в нат при установлении соединения...

Ну, как то так.... может сумбурно, но только сейчас сам до конца допер...

Решение - либо пофиксить циску (возможно поможет другая прошивка, ведь на 28/2951 на IOS нормально работает), либо просить поставщика подправить конфиг оборудования (что в моем случае не реально, упертые как бараны, у них все хорошо), чтобы сервере слал 2 потока на оба порта.

ЗЫ: как циско справится с тем, если будет конфликт портов, если в SIP Invite будет указан тот порт, который уже занят НАТ трансляцией на циске - тут не знаю как будет, не сталкивался, скорее всего надо будет перезвонить чтобы забиндились другие порты.

Изменено 22 апреля, 2022 пользователем Lobster

[Lobster]

Иииии... баг прошивки подтвердился. Перезагрузка на прошивку 16.09.8 решила проблему! Потоки проходят! Проблема решена!

[SUrov_IBM]

Lobster, здравствуйте.

 

В 22.04.2022 в 09:02, Lobster сказал:

я тоже недалеко не профессионал в астериск и VoIP

В 22.04.2022 в 18:09, Lobster сказал:

Докопался я в итоге до истины..... Дело в портах

В 23.04.2022 в 11:28, Lobster сказал:

Потоки проходят! Проблема решена!

А Вы говорите, что в VoIP не профессионально разбираетесь. ;)

 

В 20.04.2022 в 15:21, Lobster сказал:

registersip=no

Обратил внимание, что у Вас схема SIP trunk своеобразная - с аутентификацией (авторизация по логину и паролю), но без регистрации (сообщения REGISTER). Подскажите, это обусловлено работой оборудования оператора или особенностью настройки Asterisk, чтобы входящие вызовы поступали в один контекст?

 

Возможно, если использовать схему SIP trunk с регистрацией и аутентификацией, для безопасности можно ограничить доступ по IP со стороны оператора, то не потребовалось бы организовывать статический или средствами SIP ALG проброс UDP портов сигнализации / медиаканалов (RTP). Что позволит телефонии в принципе не завязываться на маршрутизатор. Плюс схема, может упросить диагностику в спорных с оператором моментах, если вместо PBX (Asterisk) использовать Softphone.

 

Совершенно противоположный, альтернативный вариант - CISCO, можно использовать как телефонный коммутатор-пограничник, в идеологии CISCO он именуется CUBE. Аналогично работает почтовый RELAY сервер, перед внутренним MTA. Можно реализовать самую "топорную" схему - [ОПЕРАТОР]<= SIP trunk =>[CISCO CUBE]<= SIP trunk =>[PBX Asterisk]. Плечо [ОПЕРАТОР]<= SIP trunk =>[CISCO CUBE] строиться без аутентификации и без регистрации (SIP-to-SIP trunk, поддерживает практически любой оператор), с обязательной привязкой по IP со стороны оператора. Так-же строиться плечо [CISCO CUBE]<= SIP trunk =>[PBX Asterisk], без аутентификации и без регистрации (без привязок IP, поскольку сеть внутренняя). Входящие от оператора  вызовы, маршрутизируются в сторону PBX (в случае с Asterisk, можно направить вызовы в один контекст) средствами dial-peer, по полученным в сигнализации значениям и так же в обратную сторону. Единственное, в таком случае, нужно скрупулёзно настроить фильтрацию IP по ACL, чтобы из публичной сети CUBE по сигнализации мог взаимодействовать только оператором. Если вдруг, решите сделать телефонный пограничник из CISCO, я поделюсь с Вами конфигурацией CUBE, просто нужно ли оно лишний раз голову забивать, знать как телефония маршрутизируется на CISCO. ;)

[Lobster]

В 23.04.2022 в 11:42, SUrov_IBM сказал:

Обратил внимание, что у Вас схема SIP trunk своеобразная - с аутентификацией (авторизация по логину и паролю), но без регистрации (сообщения REGISTER). Подскажите, это обусловлено работой оборудования оператора или особенностью настройки Asterisk, чтобы входящие вызовы поступали в один контекст?

Вот это, честно не подскажу. Настраивалось еще давно, не мной, а тем, кто нам полностью Астериск настраивал (сторонняя компания) я тогда в VoIP еще меньше разбирался. А дальше мы просто настройки транка копировали для других линий и просто меняли логин и пароль, я даже не задумывался над этой строчкой. Ну и придерживаюсь мнения: "не трогай то что хорошо работает".

ЗЫ: пробовал тестовый транк без этой строчки, на мой взгляд, в работе ничего не менялось.

В 23.04.2022 в 11:42, SUrov_IBM сказал:

Совершенно противоположный, альтернативный вариант - CISCO, можно использовать как телефонный коммутатор-пограничник, в идеологии CISCO он именуется CUBE. Аналогично работает почтовый RELAY сервер, перед внутренним MTA. Можно реализовать самую "топорную" схему - [ОПЕРАТОР]<= SIP trunk =>[CISCO CUBE]<= SIP trunk =>[PBX Asterisk]. Плечо [ОПЕРАТОР]<= SIP trunk =>[CISCO CUBE] строиться без аутентификации и без регистрации (SIP-to-SIP trunk, поддерживает практически любой оператор), с обязательной привязкой по IP со стороны оператора. Так-же строиться плечо [CISCO CUBE]<= SIP trunk =>[PBX Asterisk], без аутентификации и без регистрации (без привязок IP, поскольку сеть внутренняя). Входящие от оператора  вызовы, маршрутизируются в сторону PBX (в случае с Asterisk, можно направить вызовы в один контекст) средствами dial-peer, по полученным в сигнализации значениям и так же в обратную сторону. Единственное, в таком случае, нужно скрупулёзно настроить фильтрацию IP по ACL, чтобы из публичной сети CUBE по сигнализации мог взаимодействовать только оператором. Если вдруг, решите сделать телефонный пограничник из CISCO, я поделюсь с Вами конфигурацией CUBE, просто нужно ли оно лишний раз голову забивать, знать как телефония маршрутизируется на CISCO. ;)

Да, про цисковский CUBE я знаю, но такую схему не рассматривали, так как это, в общем то, костыли. И астер делал свою работу хорошо и сейчас делает. Этой бы темы, собственно и не было бы, если бы не БАГ в прошивке циско.

ЗЫ: у нас был SIP транк между астером и циской, когда были FXO линии и в циско входили несколько медях.

А пока я разбирался с этой циско, "relay" сервером для наших нерабочих каналов был другой астериск, который пока еще стоит за 2951 и у него проблем с РТП нету, а с этим астериском он связан по IAX2. Пришлось чутка поковыряться чтобы входящая и исходящая связь с одного астериска (которому нужны "не рабочие" каналы) уходила/приходила через IAX2 на рабочий астер. Т.е. сделал, как бы RTP proxy, костыль конечно, тоже... но как временная схема на время решения проблемы с 4351 нам подошло.

Щас уже вернул все как было: один астериск обрабатывает свои каналы, другой свои.

[SUrov_IBM]

Lobster,

 

В 24.04.2022 в 09:53, Lobster сказал:

ЗЫ: пробовал тестовый транк без этой строчки, на мой взгляд, в работе ничего не менялось

Возможно, Вы меня не так поняли. Я имел в виду, не отсутствие строки в конфигурации, а её состояние и отсылку к методу, который Asterisk использует при взаимодействии с оператором - с аутентификацией, но без регистрации. ;)

 

В 24.04.2022 в 09:53, Lobster сказал:

CUBE я знаю, но такую схему не рассматривали, так как это, в общем то, костыли

Это было, просто альтернативное предложение. Действительно Asterisk более чем самодостаточная PBX.

Для себя, я использую CUBE в качестве пограничника, поскольку в моём случае за CUBE располагается железная АТС и мне проще маршрутизировать и производить диагностику вызовов на CISCO.

 

В 24.04.2022 в 09:53, Lobster сказал:

Этой бы темы, собственно и не было бы, если бы не БАГ в прошивке циско.

Главное, что у Вас всё получилось и нормально работает, а уж как реализовано, это дело десятое.

[Lobster]

Проблема возобновилась после ребута роутера =( Теперь уже никакие прошивки не заставляют заработать эту схему =(.... Видимо баг был в том, что оно как то случайно заработало... =(

Но, нашел другой выход:

Раньше астериск выходил в инет с НАТом как и все внутренние хоста через interface overload

ip nat inside source route-map RM_ISP1_NAT interface GigabitEthernet0/0/1.100 overload

У нас были в резерве парочка запасных белых ИПа. Выпустил Астериск в инет через отдельный ИП через nat pool и все заработало тут же.

1. Сделал access list с нужными ИПшниками для выпуска через "спец.нат".

2. Этим же аксес-листом исключил эти ИПшники из основного НАТа.

3. Создал nat pool с единственным внешним ИПшником (одним из резервных)

4. И создал нат правило на основе этого аксес-листа.

Прошивка та же 16.09.8.

 

ЗЫ: пока не перезагружался =)