Страничка VOIP Инженера

Стандартная ситуация которую я вижу в обсуждениях во многих форумах. У людей есть маршрутизатор Cisco стоящий во front end. На нем крутится корпоративный NAT, VPN между офисами ну и дальше по вкусу. У начальника IT возникает «Гениальная идея». А почему бы нам с помощью этой дорогой железяки не сэкономить на телефонных переговорах. Или вообще взять по VOIP номерочек у провайдера со всеми вкусностями. Местный цискарь, обученный всяческим IT премудростям, но без какой либо практики в VOIP, насилует support провайдера, задает идиотские вопросы на форумах и самое главное методом проб и ошибок крутит все что связанно с voip в циске. И наконец, о чудо все заработало. В приподнятом настроении админ бросает все и отправляется на радостях пить пиво.

А здесь начинается самое неприятное. По в процессе экспериментов, этот админ открыл возможность транзитных VOIP звонков через циску. А в связи с тем, что ничего не работало на циске сняты все acl на голосовых портах и нет voip авторизации. Если они вообще были закрыты, поскольку по умолчанию на маршрутизаторах Cisco открыты голосовые порты и нет VOIP авторизации. Причем доступны и SIP и H323. То есть двери открыты заходи бери. Транк с авторизацией на провайдера поднят. Маршрутизация прописана.

Поэтому, при хорошем раскладе фирма за ночь получает несколько сот минут, а при плохом и тысяч, трафика на премиум направления ценой от 50 американских центов до нескольких долларов за минуту. Количество ботов сканирующих SIP порты, конечно меньше чем сканирующих ssh, mysq и www, но вреда от них на порядок больше.

Замечу из лишнего опыта. Cisco для админов, у которых /dev/hand растут из /dev/ass является самым потенциально опасным устройством, поскольку защиты от дурака не предусмотрено. Считается, что админ прошел всякого рода учебные курсы, прежде чем подошел к ней.
Выводы делайте сами.

Все спрашивают почему я не люблю Supermicro. И говорят, что их просто надо уметь готовить. Риторический вопроскак же такое приготовить, когда даже конденсаторы у них как в китайских Мыльницах.

У себя дома нарвался на ситуацию описанную в моей  же заметке. Надо было выходить из ситуации.

Установка Open SBC на домашнем маршрутизаторе

Решил попробовать интересный проект Open SBC. Вообще проект довольно вялый, но на удивление собрался без плясок с бубном. Зато над собственно настройками пришлось попотеть. Привожу окончательную рабочую конфигурацию для доступа к сети ipshka.com

[Solegy]
RTTS-Client-Address=192.168.119.230
[Local-Domain-Accounts]
Accept-All-Registration=False
Account-List Array Size=1
Account-List 1=sip:XXX:XXX@sip.int
[B2BUA-Routes]
Route-List Array Size=1
Insert-Route-Header=True
Rewrite-TO-URI=False
Prepend-ISUP-OLI=False
Route-By-Request-URI=False
Route-By-To-URI=False
Drop-Routes-On-Ping-Timeout=False
Use-External-XML=False
External-XML-File=b2bua-route.xml
Route-List 1=[sip:100011@*]sip:100011@sipphone.int
[OpenSBC-General-Parameters]
SIP-Log-Level=0
PTRACE-Log-Level=0
Log-File-Prefix=b2bua
SBC-Application-Mode=B2BUpperReg Mode
Enable-Trunk-Port=False
Enable-Calea-Port=False
RTP-Min-Port=30000
RTP-Max-Port=35000
NAT-Keep-Alive-Interval=59
Send-OPTIONS-NAT-Keep-Alive=False
Send-Responses-Using-New-Socket=False
Enable-Local-Refer=False
Disable-Refer-Optimization=False
Max-Forwards=70
Encryption-Mode=XOR
Encryption-Key=GS
Alerting-Timeout=30000
Seize-Timeout=60000
SIP-Timer-B=Default
SIP-Timer-H=Default
Session-Keep-Alive=1800
Session-Max-Life-Span=10800
Max-Concurrent-Session=100
Max-Call-Rate-Per-Second=10
[Outbound-Proxies]
Outbound-Proxies Array Size=0
[Upper-Registration]
All-Reg-As-Upper-Reg=True
Enable-Stateful-Reg=False
Rewrite-TO-Domain=True
Rewrite-FROM-Domain=False
Route-List Array Size=1
Route-List 1=[sip:*@*:*] sip:ipshka.com:5060;domain=ipshka.com
[SIP-Transports]
Main-Interface-Address Array Size=0
Backdoor-Interface-Address=sip:*:5062
Trunk-Interface-Address=sip:*:5064
Media-Server-Interface-Address=sip:*:5066
CALEA-Interface-Address=sip:*:5068
Auxiliary-Interface-Address=sip:*:5070
Interface-Route-List Array Size=2
Interface-Route-List 1=[sip:10.0.10.*] sip:10.0.10.1
Interface-Route-List 2=[sip:*] sip:192.168.119.230
[RTP-Proxy]
Proxy-On-Private-Contact=True
Proxy-On-via-received-vs-signaling-address=True
Proxy-On-Private-Via=True
Proxy-On-Different-RPORT=True
Proxy-All-Media=True
[Trusted-Domains]
Accept-All-Calls=True
Trusted-Domain-List Array Size=0
[OpenSBC HTTP Admin]
HTTP User=admin
HTTP Password=XXXXXXXXXXXXX==
SMTP Return Address=devnull@telegroup.com.ua
SMTP Password=XXXXXXXXXXXX=
SMTP Server=localhost
[Host-Access-List]
Trust-All-Hosts=True
Trusted-Host-List Array Size=0
Trusted-Host-List 1=10.0.10.0-10.0.10.255
Enable-Selective-Banning=True
Banned-Host-List Array Size=0
Trusted-Host-List 2=193.28.184.0-193.28.184.255
Trusted-Host-List 3=192.168.119.0-192.168.119.255
[Media-Server]
Enable-Media-Server=False
Media-Server-Number=5000
Codec-List Array Size=0
No-RTP-Proxy-On-All-Transfers=False
Enable-Announcement-Service=False
4xx-Error-Map=prompts/basic/cant_complete.wav
5xx-Error-Map=prompts/basic/cant_complete.wav
6xx-Error-Map=prompts/basic/cant_complete.wav
Announcement-Error-Map Array Size=0


На предмет устойчивости проекта сказать не могу, но вроде как для одного телефона работает в оба направления весьма устойчиво

Особенность работы Сisco IOS при звонке из телефонной сети в SIP сеть.

При данной схеме Cisco использует для передачи и приема разные UDP порты. Так называемая ассиметричная сигнализация. Пакеты отправляются обычно с очень высокого порта, а слушает на стандартном 5060 или том, что указан в параметре sip-server.

U 2009/07/31 15:01:21.567483 192.168.1.21:51883 -> 192.168.1.13:5060
INVITE sip:0000100@192.168.1.13:5060 SIP/2.0..Via: SIP/2.0/UDP 192.168.1.21:5060..

Причем каждый следующий пакет начинает следующую Seqence и посылается с другого порта

U 2009/07/31 15:01:21.653034 192.168.1.21:51416 -> 192.168.1.13:5060
PRACK sip:192.168.1.13:5060;lr=on;ftag=137D6378-B73 SIP/2.0..Via: SIP/2.0/UDP 192.168.1.21:5060

Интелектуальные SIP proxy (SER, Openser, Kamalio) сравнивают реальный порт передачи и значение порта в верхнем Via. На основании этого они принимают решение находится ли данный SIP клиент за NAT. И в дальнейшем посылают ответные SIP пакеты не на порт из верхнего VIA либо из поля Contact, а на порт откуда пришел последний пакет. А свою очередь Cisco закрывает порт передачи по только ей известному алгоритму. Отсюда огромное количество trouble в интернете по потере BYE пакета из SIP сети в сторону PSTN шлюза на Сisco.

Рекомендации по клонам SER, осторожно использовать 16 параметр в функции nat_uac_test, означающий принятие решения о нахождении UAC за NAT