Все спрашивают почему я не люблю 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:[email protected]
[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:[email protected]
[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 [email protected]
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:[email protected]: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
При распозновании сигнала факса AS53XX пытается сделать reinvite.
причем шлет INVITE с uri sip:@xxx.xxx.xxx.xxx где xxx.xxx.xxx.xxx ip адрес openser.
Соответственно, такой вызов попадает в ветку loose route и требует специальной обработки. Мало того, Cisco IOS не обрабатывает запрос на Digest Authorisation. В процессе моего «гугления» найдено несколько десятков topic-ов по этой теме и как правило, задающий вопрос просто не мог докопаться до источника проблемы с reinvite.
А как результат получал не очень корректный ответ.
Мое решение не очень элегантное но надежное:
В процессе обработки loose route выставить флаг на соответствующий src_ip (циски или другого t38 шлюза )и по этому флагу обходить авторизацию.
Буду признателен, за более красивое решение, в случае 100% использования digest authorisation.
Поскольку часовое «гугление» красивого варианта не дало, привожу свое решение, с очень сильно подкорректированными скриптами найденными где-то на буржуйских сайтах. У меня хостинг стоит на Ubuntu. Для других реализаций Linux, возможно придется корректировать каталоги доступа к bind.
Идея в следующем: На машине с Plesk панелью находится скрипт,
который генерирует include файл с описанием secondary зон для secondary DNS. Скрипт привязывается к событиям Domain created и Domain deleted в Event manager панели администратора Plesk.
Этот скрипт помещает include файл в один из защищенных каталогов, какого либо из сайтов на хостинге.
На машине с secondary DNS в cron.hourly помещается второй скрипт.
Он через wget подружает файл с хостинга, сравнивает с уже существующим и в случае различий подменяет локальный файл на загруженный. После чего делает rndc reload.
Оказалось просто и надежно до безобразия.
Скрипты здесь:
gen-secondaries.sh
xfer-config.sh
