ФОРУМ КУПИТЬ

Последние статьи

ВСЕ СТАТЬИ

Подключение к городской АТС по протоколу SIP

02/05/2015 22:32:38

Весной 1944 году мой прадед, служивший в 127 отдельном батальоне связи на 1-м Украинском фронте, получил Орден Красной Звезды за то, 26 марта в районе поселка Гусятин Тернопольской области, цитата: "показал образцы отваги и решительности по наладке и обслуживанию линии связи".  Далее в наградном листе (вся орфография сохранена): "Не смотря ни на какие трудности, под сильным артиллерийским и минометным огнем противника давал связь от командного пункта до 24-ой стрелковой дивизии. Связь работала устойчиво и бесперебойно. Порывы устранял в самый короткий срок, чем обеспечил командованию корпуса бесперебойную связь и своевременное руководство боем".

Семьдесят лет прошло с тех пор, как закончилась Великая Отечественная Война, мир окутан цифровыми оптоволоконными линиями связи, а космос буквально напичкан телекоммуникационными спутниками, но качественная и бесперебойная связь в нашей стране есть далеко не везде. Наверное, я не сильно ошибусь, если скажу, что в подавляющем большинстве случаев городские телефоны подключены к АТС обычными аналоговыми медными линиями, которые и сами по себе создают помехи и ловят их извне. Не скрою, и мой телефон был подключен традиционной медью. Аналоговая линия заходила через плату Digium TDM410 в моей медиа-сервер с установленной на нем программной PBX Asterisk. Такая схема подключения мне активно не нравилась. Ну какой, казалось бы, смысл цифровой сигнал на АТС конвертировать в аналоговый, передавать по медной, плохо защищенной линии ко мне, где снова оцифровывать и уже в цифровом виде отправлять на IP-телефон? Почему нельзя обойтись без всех этих конвертаций, тем более, имея высокоскоростное оптическое подключение к провайдеру на скорости 100Мбит/с?..

Можно! Многие провайдеры при наличии принципиальной технической возможности предоставляют такой сервис. Но к сожалению часто в виде: "вот вам китайский голосовой шлюз". Это, конечно, тоже неплохо, когда аналоговая линия вместо километра сокращается до 50 см, но по сути мы по-прежнему имеем дело с таким же двойным преобразованием. Кроме того, шлюзы эти часто настроены в режиме моста, должны быть подключены к цифровому каналу первыми, а пароль от конфигурирования провайдером не сообщается. Никогда не нравились такие вот черные ящики...

Нужны учетные данные (логин, пароль, IP-адрес сервера) для подключения по SIP-протоколу без аппаратного голосового шлюза, напрямую из Asterisk к АТС. За этим следует обратиться в техническую службу провайдера. Если это не типовая услуга, то круглые глаза с той стороны обеспечены. Если вам не повезло, и вы связались с каким-нибудь крупным провайдером, то сначала вам откажут в службе техподдержки, потом на уровне начальника отдела, а потом и на уровне регионального технического директора. Но мне повезло больше. Мой провайдер - небольшая местечковая компания с небольшим штатом сотрудников. Конечно же и здесь мне предоставили учетные данные далеко не сразу. Потребовалось время. Ведь такой клиент был у них впервые. Но все-таки мне пошли навстречу, за что отдельное спасибо директору компании.

Настройка SIP-транка в Asterisk оказалась неожиданно простой.

В sip.conf

register=0950000:password@172.16.3.2/0950000

[provider]
    username=0950000
    type=friend
    secret=password
    context=from_provider
    host=172.16.30.2
    trunkname=provider
    fromuser=0950000
    fromdomain=172.16.3.249
    realm=0950000
    insecure=port,invite
    disallow=all
    allow=alaw
    qualify=200

А в extension.conf меняем маршрутизацию с аналогового транка DAHDI на SIP

;exten => _NXXXXX,1,Dial(DAHDI/2/${EXTEN:0})
exten => _NXXXXX,1,Dial(SIP/provider/${EXTEN},120)

Там же настройка входящих вызовов

[from_provider]
exten => 0950000,1,Answer ; Входящие вызовы приходят на 950000
exten => 0950000,2,Dial(SIP/102,25,Ttr) ; Входящие перенаправляются на внутренний номер 102
exten => 0950000,3,Hangup

Собственно, все. Достаточно сделать перезагрузку настроек Asterisk. Но есть один нюанс. Для доступа к серверу 172.16.3.2 согласно конфигурации провайдера нужно настроить VLAN, обеспечивающий приоритезацию трафика.
В Debian делается это очень просто (необходимо установить пакет vlan) с помощью утилит vconfig или ip, но лучше сразу прописать конфигурацию в /etc/network/interfaces

auto eth0.45
iface eth0.45 inet static
        address 172.16.3.249
        netmask 255.255.255.0
        vlan_raw_device eth0

И далее запускаем
ifup eth0.45

Провайдер мне выдал специальный адрес, который я прописал статически, хотя можно получить адрес и по DHCP.
Однако случилась одна маленькая сложность. Компьютер с установленным Asterisk у меня находится за маршрутизатором, роль которого выполняет основной сервер Умного Дома. Поэтому, чтобы все заработало, следует настроить VLAN Bridge на маршрутизаторе. А это еще проще. В /etc/network/interfaces маршрутизатора прописываем

auto br0
iface br0 inet manual
        bridge_ports eth0.45 eth1.45
        up /sbin/brctl stp br0 on

Вот теперь, после того, как мы подняли "бридж", все сразу же и заработало. Посмотреть текущие регистрации в Asterisk можно командой "sip show registry".

Host                                    dnsmgr Username       Refresh State                Reg.Time
172.16.3.2:5060                        N      0950000            105 Registered           Sat, 02 May 2015 17:58:24

Качество связи стало намного лучше. Исчезли треск и шумы. Из минусов - осталась проблема эха при звонках на некоторые номера. Связано оно с тем, что сигнал по цифровым каналам идет с небольшой задержкой, которая требуется для кодирования/декодирования. И если совокупная задержка всех элементов составляет более 50 мс, то при звонках на аналоговые телефоны может проявляться эхо. Давить его можно только на конечном оборудовании (так как Asterisk при таком подключении работает только как транспорт), но IP-телефоны (равно как и голосовые шлюзы) справляются с этой задачей не всегда хорошо. Как одно из решений - снижение чувствительности микрофона. Эхо остается, но его почти не слышно.

При эксплуатации сетевой конфигурации с VLAN'ами я заметил, что мою сеть видно из сети 172.16. Кроме того, мою сеть посещают всякие широковещательные пакеты и DHCP-запросы. И если с обычным IP трафиком достаточно легко справиться с помощью iptables, то вот запретить DHCP так просто не выйдет. Дело в том, что DHCP работает не на сетевом, а на канальном уровне. А значит нужно использовать специальную утилиту ebtables.

ebtables -A INPUT --in-interface eth1.45 --protocol ipv4 --ip-protocol udp --ip-source-port 67:68 -j DROP
ebtables -A INPUT --in-interface eth1.45 --protocol ipv4 --ip-protocol udp --ip-destination-port 67:68 -j DROP
ebtables -A FORWARD --in-interface eth1.45 --protocol ipv4 --ip-protocol udp --ip-source-port 67:68 -j DROP
ebtables -A FORWARD --in-interface eth1.45 --protocol ipv4 --ip-protocol udp --ip-destination-port 67:68 -j DROP

Вот теперь проблема лишнего DHCP-трафика, приходящая из сети VLAN решена.

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

Автор: Andrey_B
Любое использование материалов сайта возможно только с разрешения автора и с обязательным указанием источника.



Добавить комментарий:

(необязательно, не отображается на сайте)


Сортировка комментариев: Последние сверху | Первые сверху