Внешние подключения

Вы не всегда можете контролировать что происходит снаружи.

Но вы всегда можете контролировать что присходит внутри.

— Уэйн Дьер

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

Архитектура Asterisk значительна во многом благодаря тому, что она рассматривает все типы каналов как равные. Это контрастирует с традиционной АТС, где транки (которые подключаются к внешнему миру) и внутренние номера (которые подключаются к пользователям и ресурсам) сильно отличаются. Тот факт, что диалплан Asterisk относится ко всем каналам похожим образом, означает, что в системе Asterisk вы можете легко выполнять вещи, которые намного сложнее (или невозможно) достичь на традиционной АТС.

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

Основы транкинга

Целью транкинга является предоставление общего соединения между двумя объектами. Например, магистраль — это шоссе, которое соединяет два города вместе. Железные дороги широко использовали термин «trunk» (транк, с англ. — магистраль), чтобы ссылаться на основную линию, соединяющую фидерные линии вместе.

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

Вероятно, проще всего подумать о транке как о наборе линий, обслуживающих маршрут. Таким образом, на УАТС Asterisk у Вас могут быть транки, которые идут к вашему VoIP-провайдеру для междугородних звонков, транки для ваших сетей PSTN и транки, которые соединяют ваши офисы вместе. Эти транки могут фактически работать через одно и то же сетевое соединение, но в вашем диалплане вы можете относиться к ним совершенно по-разному.

Хотя мы считаем, что VoIP в конечном итоге полностью заменит PSTN, многие из концепций, которые используются в VoIP-линиях (например, «номер телефона»), обязаны своим существованием больше истории, чем любые технические требования, и поэтому мы считаем, что будет полезно обсудить использование традиционных линий PSTN с Asterisk, прежде чем мы перейдем к VoIP.

Если система, которую вы устанавливаете, будет использовать только VoIP-линии, это не проблема. Идите прямо в раздел VoIP этой главы¹, и мы рассмотрим, что вам нужно сделать. Мы рекомендуем читать разделы PSTN по вашему усмотрению, так как в них могут быть общие знания, которые могут вам пригодиться, но это не является строго необходимым для понимания и использования Asterisk.

Фундаментальный диалплан для исходящих соединений

В традиционной УАТС внешние линии обычно доступны посредством кода доступа, который должен быть набран до номера.² Обычно для этой цели используется цифра 9.

В Asterisk аналогичным образом можно назначить 9 для маршрутизации внешних вызовов, но поскольку диалплан Asterisk намного более интеллектуальный, на самом деле не нужно заставлять ваших пользователей набирать 9 перед тем, как совершить вызов. Как правило, у вас будет диапазон номеров для вашей системы (скажем, 100-199) и диапазон кодов функций (от *00 до *99). Все, что находится за пределами диапазона, который соответствует шаблону набора номера для вашей страны или региона, можно рассматривать как внешний вызов.

Если у вас есть один оператор, предоставляющий всю вашу внешнюю маршрутизацию, вы можете обрабатывать свой внешний набор через несколько простых совпадений шаблонов. Пример в этом разделе действителен для Североамериканского плана нумерации (NANP). Если ваша страна не находится в пределах NANP (который обслуживает Канаду, США и несколько стран Карибского бассейна), вам понадобится другой шаблон.

Раздел [globals] содержит две переменные, называемые LOCAL и TOLL.³ Целью этих переменных является упрощение управления вашим диалпланом, если вам когда-либо понадобится изменить провайдера. Они позволяют сделать одно изменение в диалплане, которое повлияет на все места, где указан данный канал:

[globals]

LOCAL=DAHDI/G0 ; если у Вас в системе есть PSTN карта

TOLL=SIP/YourVoipCarrier ; как определено в sip.conf

Секция [external] содержит фактический код диалплана, который распознает набранные номера и передает их в приложение Dial():⁴

[external]

exten => _NXXNXXXXXX,1,Dial(${LOCAL}/${EXTEN}) ; 10-значный шаблон для NANP

exten => _NXXXXXX,1,Dial(${LOCAL}/${EXTEN}) ; 7-значный шаблон для NANP

exten => _1NXXNXXXXXX,1,Dial(${TOLL}/${EXTEN}) ; шаблон международного направления для NANP

exten => _011.,1,Dial(${TOLL}/${EXTEN}) ; Шаблон международного вызова, сделанного из NANP

; Этот раздел функционально совпадает с приведенным выше разделом.

; Это для людей, которым нравится набирать «9» для их звонков

exten => _9NXXNXXXXXX,1,Dial(${LOCAL}/${EXTEN:1})

exten => _9NXXXXXX,1,Dial(${LOCAL}/${EXTEN:1})

exten => _91NXXNXXXXXX,1,Dial(${TOLL}/${EXTEN:1})

exten => _9011.,1,Dial(${TOLL}/${EXTEN:1})

В любом контексте, который будет использоваться комплектами или пользовательскими устройствами, вы должны использовать директиву include =>, чтобы разрешить доступ к контексту external:

[LocalSets]

include => external

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

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

Линии PSTN (ТфОП)

Общественная коммутируемая телефонная сеть (PSTN) (или же телефонная сеть общего пользования — ТфОП) существует уже более века. Это предшественник многих технологий, которые формируют наш мир сегодня, от Интернета до MP3-плееров.

Традиционные транки ТфОП

Существует два типа фундаментальных технологий, которые используются операторами телефонной связи для доставки телефонных линий: аналоговых и цифровых.

Аналоговая телефония

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

Аналоговые линии имеют несколько характеристик, которые отличают их от других линий, которые вы, возможно, захотите подключить к Asterisk:

• Нет канала сигнализации — большинство сигналов являются электромеханическими.
• Контроль отключения обычно задерживается на несколько секунд и не является полностью надежным.
• Дальнейшее наблюдение минимально (например, контроль ответа отсутствует).
• Различия в линиях означают, что звуковые характеристики будут варьироваться от линии к линии и потребуют настройки.

Аналоговые линии, которые вы захотите подключить к вашей системе Asterisk, должны подключаться к порту Foreign eXchange Office (FXO). Поскольку на любом стандартном компьютере нет порта для FXO, в систему необходимо приобрести и установить плату FXO для подключения традиционных аналоговых линий.⁵

FXO и FXS

Для любой аналоговой линии есть два конца: офис (обычно центральный офис ТфОП) и станция (обычно это телефон, но также может быть карта, такая как модем или линейная карта в АТС).

Центральный офис отвечает за:

• Мощность на линии (номинально 48 Вольт постоянного тока)
• Напряжение звонка (номинально 90 Вольт переменного тока)
• Предоставление гудка набора
• Обнаружение состояния трубки (снятие трубки и повешение)
• Отправка дополнительной сигнализации, такой как идентификатор вызывающего абонента

Станция несет ответственность за:

• Предоставление звонка (или, по крайней мере, способности обрабатывать сигнальное напряжение каким-либо образом)
• Предоставление панели набора номера (или способ отправки DTMF)
• Предоставление рычажного переключателя трубки для указания статуса линии

Порт Foreign eXchange (FX) называется так в зависимости от того, к чему он подключается, а не тем, что он делает. Так, например, порт Foreign eXchange Office (FXO) фактически является станцией: он подключается к центральному офису. Порт External eXchange Station (FXS) фактически является портом, предоставляющим услуги центрального офиса (другими словами, вы подключаете аналоговый аппарат к порту FXS).

Вот почему настройки сигнализации в конфигурационных файлах Asterisk кажутся обратными: порты FXO используют сигнализацию FXS; порты FXS используют сигнализацию FXO. Когда вы понимаете, что имя физического типа порта основано на том, к чему оно подключается, имена сигналов в Asterisk имеют немного больше смысла: если порт FXO подключается к центральному офису, он должен вести себя как станция , и поэтому требуется сигнализация FXS.

Обратите внимание, что переход от FXO к FXS не так то просто сделать с помощью изменения настроек. Для портов FXO и FXS требуется совершенно разная электроника. Большинство аналоговых карт, доступных для Астериска, используют какую-то дочернюю карту, которая соединяется с основной и предоставляет правильный тип канала, а это означает, что у вас есть определенная гибкость в определении того, какие типы портов у вас есть на вашей карте.

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

• Доступность цифровых соединительных линий в вашем районе
• Стоимость (аналог дешевле при меньших плотностях, но более дорог при более высоких плотностях)
• Логистика (если у вас уже установлены аналоговые линии, вы можете их сохранить)

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

Цифровая телефония

Цифровая телефония была разработана для преодоления многих ограничений аналоговой.

Некоторые из преимуществ цифровых линий включают в себя:

• Отсутствие потери амплитуды на больших расстояниях
• Снижение шума в сети (особенно междугородных линий)
• Возможность переносить более одного вызова на линию
• Более быстрая настройка и отключение вызова
• Более богатая сигнальная информация (особенно, если используется ISDN)
• Более низкая стоимость для провайдеров
• Более низкая стоимость для клиентов (при более высокой плотности)

В системе Asterisk (или любой АТС, если на то пошло) существует несколько типов цифровых линий, которые вы можете подключить:

T1 (24 канала)

Используется в Канаде и США (в основном для ISDN-PRI)

E1 (32 канала)

Используется в остальном мире (ISDN-PRI или MFC/R2)

BRI (2 канала)

Используется для схем ISDN-BRI (Euro-ISDN)

Обратите внимание, что физическая линия может быть дополнительно определена протоколом, запущенным на линии. Например, T1 может использоваться для ISDN-PRI или CAS, а E1 может использоваться для ISDN-PRI, CAS или MFC/R2. Мы обсудим различные протоколы в следующем разделе.

Установка ТфОП транков

В зависимости от установленного оборудования процесс установки ваших ТфОП-карт будет отличаться. Мы обсудим установку в общих чертах, которая будет применяться ко всем картам Digium PSTN. Другие производители, как правило, предоставляют инсталляционные скрипты с их аппаратными средствами, которые будут автоматизировать большую часть этого процесса.

Загрузка и установка DAHDI

Интерфейс аппаратного устройства Digium Asterisk, a.k.a. DAHDI (DAW-dee),⁶ — это программная среда, необходимая для связи между ТфОП-картами и Asterisk. Даже если у вас нет оборудования ТфОП, мы рекомендуем установить DAHDI, поскольку это простой и надежный способ получения правильного источника синхронизации.⁷ Полные инструкции по установке DAHDI можно найти в Главе 3.

Отключение загрузки дополнительных модулей DAHDI

По умолчанию DAHDI загрузит все скомпилированные модули в память. Поскольку это необязательно, давайте отключим загрузку любых аппаратных модулей. Если в конфигурационные файлы не загружены модули, DAHDI загрузит драйвер dahdi_dummy, который предоставит интерфейс для Asterisk, чтобы получать синхронизацию с ядром для корректной работы таких модулей как MeetMe и IAX2.

Начиная с DAHDI 2.3.0, требования загрузки dahdi_dummy для интерфейса синхронизации больше не существует. Та же функциональность теперь интегрирована в основной модуль ядра dahdi.

Файл конфигурации, определяющий, какие модули DAHDI будут загружаться, находится в /etc/dahdi/modules. Чтобы отключить загрузку дополнительных модулей, все, что нам нужно сделать, это отредактировать файл модулей и закомментировать все модули, разместив хеш (#) в начале каждой строки. Когда все будет готово, файл конфигурации модулей должен выглядеть примерно так:

# Содержит список модулей для загрузки/выгрузки из /etc/init.d/dahdi.

#

# ПРИМЕЧАНИЕ: Пожалуйста добавьте/отредактируйте /etc/modprobe.d/dahdi или

# /etc/modprobe.conf если хотите добавить какие-либо параметры модуля.

#

# Формат этих файлов: список модулей, каждый на новой строке.

# Всё, что следует за ‘#’ будет игнорироваться, как начальные и конечные

# пробелы и пустые строки.

# Digium TE205P/TE207P/TE210P/TE212P: PCI dual-port T1/E1/J1

# Digium TE405P/TE407P/TE410P/TE412P: PCI quad-port T1/E1/J1

# Digium TE220: PCI-Express dual-port T1/E1/J1

# Digium TE420: PCI-Express quad-port T1/E1/J1

#wct4xxp

# Digium TE120P: PCI single-port T1/E1/J1

# Digium TE121: PCI-Express single-port T1/E1/J1

# Digium TE122: PCI single-port T1/E1/J1

#wcte12xp

# Digium T100P: PCI single-port T1

# Digium E100P: PCI single-port E1

#wct1xxp

# Digium TE110P: PCI single-port T1/E1/J1

#wcte11xp

# Digium TDM2400P/AEX2400: up to 24 analog ports

# Digium TDM800P/AEX800: up to 8 analog ports

# Digium TDM410P/AEX410: up to 4 analog ports #wctdm24xxp

# X100P — Single port FXO interface

# X101P — Single port FXO interface

#wcfxo

# Digium TDM400P: up to 4 analog ports

#wctdm

# Digium B410P: 4 NT/TE BRI ports

#wcb4xxp

# Digium TC400B: G729 / G723 Transcoding Engine #wctc4xxp

# Xorcom Astribank Devices

#xpp_usb

Вы также можете использовать dahdi_genconf modules для создания правильного пустого файла конфигурации. Приложение dahdi_genconf будет искать вашу систему для аппаратного обеспечения, и если ничего не найдено создаст файл modules, который не загружает какие-либо аппаратные модули.

Затем вы можете перезапустить свой DAHDI-процесс, чтобы выгрузить все существующие драйверы, которые были загружены, и загрузить только модуль dahdi_dummy с помощью скрипта инициализации:

$ sudo /etc/init.d/dahdi restart

Unloading DAHDI hardware modules: done

Loading DAHDI hardware modules:

No hardware timing source found in /proc/dahdi, loading dahdi_dummy

Running dahdi_cfg: [ OK ]

Однако, прежде чем вы сможете начать использовать свое оборудование, вам необходимо настроить файл /etc/dahdi/system.conf; этот процесс описан в разделе «Настройка цифровых линий» и «Настройка аналоговых линий».

Настройка цифровых линий

Цифровая телефония была разработана провайдерами как способ снизить стоимость междугородных связей, а также улучшить качество передачи. Вся магистраль ТфОП была полностью цифровой уже много лет. Суть цифровой линии заключается в оцифровке звука, но цифровые линии связи также обеспечивают более сложную и надежную сигнализацию. Несколько стандартов были разработаны и развернуты, и для каждого стандарта могут быть и региональные различия.

Вы можете использовать dahdi_hardware и lsdahdi, чтобы помочь определить какое аппаратное обеспечение телефонии содержит ваша система. Вы также можете использовать dahdi_genconf modules для создания файла /etc/asterisk/modules для вас на основе найденного оборудования.

PRI ISDN. Primary Rate Interface ISDN (широко известный как PRI) — это протокол, предназначенный для работы в основном на линии DS1 (T1 или E1, в зависимости от того, где вы находитесь) между провайдером и клиентом. PRI использует один из каналов DS0 в качестве канала сигнализации (называемый D-каналом). Таким образом, типичная схема PRI разбивается на группу B-каналов (каналы-носители, которые фактически несут вызовы) и D-канал для сигнализации. Хотя наиболее часто обнаруживается, что линия PRI переносится по одной физической линии (такой как T1 или E1), возможно иметь несколько каналов DS1 в цепи PRI и даже иметь несколько D-каналов.⁸

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

При установке аппаратного обеспечения телефонии обязательно обновите файл /etc/dahdi/modules, чтобы включить соответствующие модули для вашего устройства, а затем перезагрузите DAHDI с помощью скрипта инициализации (/etc/init.d/dahdi). Вы можете использовать команду dahdi_genconf modules для создания файла модулей для вашей системы.

Большинство линий PRI в Северной Америке будут использовать T1 со следующими характеристиками:

• Код линии: B8ZS (биполярный с замещением 8-нулей)
• Кадрирование: ESF (расширенный суперкадр)

Вам нужно будет настроить два файла. Файл /etc/dahdi/system.conf должен выглядеть примерно так:

loadzone = us

defaultzone = us

span = 1,1,0,esf,b8zs

bchan = 1-23

echocanceller = mg2,1-23

hardhdlc = 24

И файл /etc/asterisk/chan_dahdi.conf должен выглядеть так:

[trunkgroups]

[channels]

usecallerid = yes

hidecallerid = no

callwaiting = yes

usecallingpres = yes

callwaitingcallerid = yes

threewaycalling = yes

transfer = yes

canpark = yes

cancallforward = yes

callreturn = yes

echocancel = yes

echocancelwhenbridged = yes

relaxdtmf = yes

rxgain = 0.0

txgain = 0.0

group = 1

callgroup = 1

pickupgroup = 1

immediate = no

switchtype = national ; обычно называемый NI2

context = from-pstn

group = 0

echocancel = yes

signalling = pri_cpe

channel => 1-23

Некоторые операторы будут использовать DMS-коммутатор Nortel, который обычно использует протокол DMS100 вместо национального ISDN 2. В этом случае вы установите для параметра switchtype значение DMS100:

switchtype = dms100

Вне Канады и США линии PRI будут передаваться по стандарту E1.

В Европе стандарт E1, используемый для PRI, обычно имеет следующие характеристики:

• Код линии: CCS
• Кадрирование: HDB3 (биполярный с высокой плотностью)

Файл /etc/dahdi/system.conf может выглядеть примерно так:

span = 1,0,0,ccs,hdb3,crc4

bchan = 1-15,17-31

hardhdlc = 16

И файл /etc/asterisk/chan_dahdi.conf должен выглядеть примерно так:

[trunkgroups]

[channels]

usecallerid = yes

hidecallerid = no

callwaiting = yes

usecallingpres = yes

callwaitingcallerid = yes

threewaycalling = yes

transfer = yes

canpark = yes

cancallforward = yes

callreturn = yes

echocancel = yes

echocancelwhenbridged = yes

relaxdtmf = yes

rxgain = 0.0

txgain = 0.0

group = 1

callgroup = 1

pickupgroup = 1

immediate = no

switchtype = qsig

context = pri_incoming

group = 0

signalling = pri_cpe

channel => 1-15,17-31

BRI ISDN. Basic Rate Interface ISDN (иногда называемый BRI, а иногда даже ISDN) должен был быть меньшим братом для PRI. BRI предоставляет только два 64-бкитных B-каналов и 16-кбитный D-канал. Использование BRI было несколько ограничено в Северной Америке (мы не рекомендуем использовать его по какой-либо причине), но в некоторых странах Европы он широко используется и почти полностью заменил аналоговый.

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

При установке аппаратного обеспечения телефонии обязательно обновите файл /etc/dahdi/modules, чтобы включить соответствующие модули для вашего оборудования, а затем перезагрузите DAHDI с помощью скрипта инициализации (/etc/init.d/dahdi). Вы можете использовать команду dahdi_genconf modules для создания файла modules для вашей системы.

MFC/R2. Протокол MFC/R2 можно рассматривать как предшественника ISDN. Сначала он использовался на аналоговых линиях, но теперь в основном используется в тех же линиях E1, которые также имеют ISDN-PRI. Этот протокол обычно не встречается в Канаде, США или Западной Европе, но он очень популярен в некоторых других частях мира (особенно в Латинской Америке и Азии), главным образом потому, что он, как правило, является менее дорогостоящим предложением от провайдеров.

Существует много разных вариантов этого протокола, каждая страна имеет свой региональный вариант.

Проект OpenR2 предоставляет библиотеку libopenr2, которая должна быть установлена в вашей системе, чтобы Asterisk поддерживал ваши линии R2. Однако перед установкой libopenr2 вам необходимо установить DAHDI.

Таким образом, порядок компиляции и установки:

1. DAHDI
2. libopenr2
3. Asterisk

Как только OpenR2 будет установлен, вы можете использовать приложение r2test, чтобы просмотреть список поддерживаемых вариантов:

$ r2test -l

Variant Code Country

AR Argentina

BR Brazil

CN China

CZ Czech Republic

CO Colombia

EC Ecuador

ITU International Telecommunication Union

MX Mexico

PH Philippines

VE Venezuela

Дополнительную информацию о настройке поддержки R2 в Asterisk см. В файле configs/chan_dahdi.conf.sample, включенном в дерево исходников Asterisk (поиск по «mfcr2»). Кроме того, OpenR2 содержит некоторые примеры файлов конфигурации для подключения Asterisk к линиям в разных странах. Чтобы прочитать информацию о некоторых вариантах стран, выполните поиск в папке /doc/asterisk и обратитесь к документам в соответствующем подкаталоге:

$ ls doc/asterisk/

ar br ec mx ve

В качестве примера OpenR2 предоставляет пример конфигурации для подключения к Telmex или Axtel в Мексике. Мы проведем вас через все шаги чтобы дать представление о процессе. Во-первых, вы должны настроить DAHDI, изменив /etc/dahdi/system.conf, как показано здесь:

loadzone = us

defaultzone = us

span = 1,1,0,cas,hdb3

cas = 1-15:1101

cas = 17-31:1101

span = 2,1,0,cas,hdb3

cas = 32-46:1101

cas = 48-62:1101

Затем вы должны настроить Asterisk, изменив /etc/asterisk/chan_dahdi.conf следующим образом:

signalling = mfcr2

mfcr2_variant = mx

mfcr2_get_ani_first = no

mfcr2_max_ani = 10

mfcr2_max_dnis = 4

mfcr2_category = national_subscriber

mfcr2_mfback_timeout = -1

mfcr2_metering_pulse_timeout = -1

; это для целей отладки

mfcr2_logdir = log

mfcr2_logging = all

; конец конфигурации отладки

channel => 1-15

channel => 17-31

Настройка аналоговых линий

Есть много компаний, производящих PSTN-карты для Asterisk. Для карты должны быть установлены драйверы, чтобы Linux мог ее распознать (DAHDI поставляется с этими драйверами для карт Digium). С этого момента конфигурация обрабатывается модулем Астериска chan_dahdi.

Вы можете использовать dahdi_hardware и lsdahdi для определения того, какое аппаратное обеспечение телефонии содержит ваша система.

При установке аппаратного обеспечения телефонии обязательно обновите файл /etc/dahdi/modules, чтобы включить соответствующие модули для вашего оборудования, а затем перезагрузите DAHDI с помощью скрипта инициализации (/etc/init.d/dahdi). Вы можете использовать команду dahdi_genconf modules для создания файла модулей для вашей системы.

Чтобы настроить FXO-карту для работы с Asterisk, необходимы два файла: первый не является файлом конфигурации Asterisk и поэтому находится в папке /etc/dahdi в вашей системе.⁹ Этот файл system.conf позволяет вам определить некоторые основные параметры, а также указать каналы, которые будут доступны вашей системе. В нашем примере используется четырехпортовая FXO-карта, но в зависимости от вашего оборудования возможно множество различных комбинаций:

loadzone = us ; определяет звуки, который должен произвести интерфейс (гудок, сигнал занятости, обратный звонок и тд.)

defaultzone = us ; определяет tonezone по умолчанию

fxsks = 1-4 ; какие каналы на карте будут иметь эти параметры

Как только ваша карта и каналы известны операционной системе, вы должны настроить их для Asterisk с помощью файла /etc/asterisk/chan_dahdi.conf:

[channels]

;

; Чтобы применить другие опции для этих каналов, поместите их перед «channel»

;

signalling = fxs_ks ; в Asterisk FXO каналы используют FXS сигнализацию

; (и наоборот FXS каналы используют FXO сигнализацию)

channel => 1-4 ; применяем все указанные настройки к этим каналам

В этом примере мы сказали Asterisk, что первые четыре канала DAHDI в системе являются портами FXO.

Расширениеs. Если вы подключаетесь к ТфОП с использованием аналоговых каналов, нам нужно объяснить расширение (добавочный номер) s. Когда вызовы входят в контекст без специального назначения (например, вызывающая линия FXO из ТфОП), они передаются на добавочный номер s (s означает «start», так как здесь начинается вызов, если с вызовом не передавалась никакая информация о добавочном номере). Этот номер также может быть полезен для принятия вызовов, которые были перенаправлены из других частей диалплана. Например, если бы у нас был список номеров прямого входящего набора (DID), которые все были в одном месте, мы могли бы указать каждый DID на добавочный номер s, вместо того, чтобы иметь код для дублирования логики диалплана для каждого DID.

Поскольку это именно то, что нам нужно для нашего диалплана, давайте начнем заполнять его. Мы будем выполнять три действия по вызову (ответить на него, воспроизвести звуковой файл и повесить трубку), поэтому нашему добавочному номеру потребуется три приоритета. Мы поставим три приоритета ниже [incoming], потому что мы решили, что все входящие вызовы должны начинаться в этом контексте:¹⁰

[incoming]

exten => s,1,Answer()

same => n,Playback(tt-weasels)

same => n,Hangup()

Очевидно, вы не хотели бы отвечать на звонок, а затем сразу вешать трубку. Как правило, на входящий вызов отвечает либо автоответчик, либо звонит напрямую на телефон (или группу телефонов).

VoIP

По сравнению с обширной историей телекоммуникаций, VoIP по-прежнему является относительно молодой концепцией. В течение столетия или около того до VoIP, единственный способ подключить вас к ТфОП — это использование линий, предназначенных для этой цели вашей местной телефонной компании. В настоящее время VoIP позволяет устанавливать соединения между конечными точками без участия ТфОП (хотя в большинстве сценариев VoIP в какой-то момент все еще будет компонент ТфОП, особенно если используется традиционный телефонный номер E.164).

Как справиться с преобразованием сетевых адресов (NAT)

Если вы собираетесь использовать VoIP через любую широкополосную сеть (например Интернет), вы будете иметь дело с брандмауэрами и преобразованием сетевых адресов (NAT).¹¹ Основное понимание того, как протоколы SIP и RTP работают вместе для создания VoIP-вызова, может помочь в понимании и отладке функциональных проблем (таких как очень распространенная проблема «одностороннего звука», часто возникающая при настройке конфигурации NAT). NAT позволяет использовать один внешний IP-адрес несколькими устройствами за маршрутизатором.

Поскольку NAT обычно обрабатывается в брандмауэре он также является частью уровня безопасности между частной сетью и Интернетом.

VoIP-вызов с использованием SIP состоит не только из сообщений сигнализации для настройки вызова (SIP-часть соединения). Он также требует потоков RTP (медиапотоков), которые несут фактическое аудиосоединение¹², как показано на Рисунке 7-1.

Использование отдельных протоколов для передачи звука — это то, что может сделать проблематичным обход NAT для VoIP-соединений, особенно если удаленные телефоны находятся за одним NAT, а АТС — за другим. Проблема связана с тем, что, хотя сигнализация SIP, как правило, может проходить через межсетевые экраны с обоих концов, потоки RTP могут не распознаваться как часть сеанса SIP, и, поэтому, они будут игнорироваться или блокироваться, как на Рисунке 7-2. Эффект блокирования одного или обоих потоков RTP отобразится в том, что пользователи будут жаловаться на то, что их звонки происходят, и можно ответить на них, но не слышно собеседника (или он не слышит).

В этом разделе мы обсудим некоторые из методов, которые вы можете использовать для устранения проблем, вызванных NAT. Существует два разных сценария, которые необходимо учитывать; каждый из которых требует определения параметров в файле sip.conf. Когда Вы начнете понимать, с каким сценарием вы сталкиваетесь,¹³ проблемы с NAT останутся в прошлом.

Устройства за NAT

Во-первых, давайте рассмотрим устройства, расположенные за удаленным NAT, подключенным к вашему Астериск, как показано на Рисунке 7-3.

Когда устройство пытается инициировать сеанс, оно составляет сообщение SIP, которое содержит его IP-адрес и некоторую дополнительную информацию. Когда Asterisk видит эту информацию, он использует ее, чтобы определить как реагировать. Поскольку устройство находится за NAT, SIP-сообщение будет иметь адрес ответа, который не будет маршрутизироваться (например, 192.168.1.104). Тем не менее, мы можем сказать Asterisk игнорировать этот адрес сообщения SIP и вместо этого использовать то, что предоставляется сетевым стеком. Мы включаем это через опцию nat в sip.conf. В Таблице 7-1 перечислены аргументы, которые мы можем установить с помощью опции nat.

Таблица 7-1. Аргументы доступные для nat в sip.conf

Аргумент	Описание
no	Не выполнять особую обработку NAT, кроме тех, что указаны в RFC 3581.a
force_rport	Даже если параметр rport не указан, действовать так, как если бы он был.
comedia	Отправляйте медиапоток обратно на порт, из которого он был получен и игнорировать запрошенный порт в заголовке SDP.
auto_force_rport	Если Asterisk может определить, что устройство находится за NAT, установить параметр force_rport. Это значение по умолчанию.
auto_comedia	Если Asterisk может определить, что устройство находится за NAT, установить параметр comedia.

^a http://www.ietf.org/rfc/rfc3581.txt

RFC 3581 позволяет устройству использовать параметр rport для передачи сигнала на дальний конец, чтобы он отвечал на IP-адрес и порт источника и отправлял запрос на него вместо адреса, указанного в заголовке SIP. Подстановка параметра rport может произойти, когда устройство знает, что оно находится за NAT и не может записать информацию, которая потребуется для двусторонней связи, в заголовке SIP. Asterisk всегда будет соблюдать параметр rport, если он установлен, но поскольку это не так часто как хотелось бы, мы можем заставить Asterisk предположить, что устройство предоставило бы параметр rport, если бы оно знало лучше. Делая это, мы поручаем Asterisk всегда отвечать на исходный IP-адрес и порт от которого он получил запрос. Если никакая настройка nat не определена явно, Asterisk по умолчанию будет устанавливать auto_force_rport в качестве значения параметра nat. Вы можете заставить делать это принудительно установив nat=force_rport.

Опция comedia (connection-oriented media) может использоваться для указания Asterisk отправки медиафайлов (RTP) на адрес и порт, из которых они поступают. Она используется, когда устройство находится за NAT и не может указать Asterisk правильное местоположение для отправки медиа.

Вы также можете указать несколько параметров для параметра nat, разделив аргументы запятой. Например, принято устанавливать как force_rport, так и comedia в качестве метода обработки NAT (с которого мы рекомендуем начать):

nat=force_rport,comedia

Важно отметить, что если параметр nat в общем разделе отличается от того, который находится в секции пира, тогда становится возможным обнаружить действительные пиры в системе. Это проблема безопасности, и очень рекомендуется указывать значения для nat в общем разделе. Обнаружение пиров осуществляется путем проверки системы, и эти пиры с разными настройками nat будут реагировать по-разному, тем самым позволяя потенциальному злоумышленнику обнаружить, какие пиры действительны в системе.

Еще один трюк при работе с устройствами за NAT — это возможность выбора опции qualify. Во многих системах NAT, если диалог не поддерживается периодически, то устройство, предоставляющее NAT, может закрыть соединение. Используя сигнал готовности (qualify), Астериск отправит запрос в дальний конец, на который следует ответ. По умолчанию, если вы используете qualify=yes для пира, время для этих транзакций составляет каждые 2000 миллисекунд (2 секунды). Вы также можете указать время в миллисекундах вместо использования yes:

qualifyfreq=60 ; зондировать конечное устройство пира каждые 60 секунд

qualify=120000 ; разрешить 10 секунд для ответа (qualify)

Сохранение открытости удаленного брандмауэра

Иногда возникает проблема с SIP-телефоном, при которой телефон регистрируется и функционирует при первой загрузке, но затем внезапно становится недоступным. Причина этого заключается в том, что удаленный брандмауэр, не видя активности закрывает внешнее соединение с телефоном, и, таким образом, АТС теряет возможность отправки пакетов. Эффект заключается в том, что, если АТС пытается отправить вызов на телефон, то не сможет подключиться (удаленный брандмауэр отклонит соединение). Если, с другой стороны, пользователь делает вызов, в течение нескольких минут телефон снова сможет принимать входящие вызовы. Естественно, это может вызвать путаницу у пользователей.

Относительно простое решение этой проблемы¹ включает установку таймера регистрации на удаленном телефоне на достаточно низкое значение, которое будет стимулировать подключение каждую минуту или около того, и таким образом убедить брандмауэр, что этому соединению может быть разрешено существовать еще немного. Это немного похоже на взлом, но вариант оказался успешным. Проблема с предложением универсального решения заключается в том, что существует множество различных моделей брандмауэров, от недорогих единиц потребительского класса до сложных пограничных контроллеров сеанса, и это одно из немногих решений, которое, по-видимому, почти полностью устраняет проблему.

Этот подход лучше всего подходит для небольших систем (менее 100 телефонов). Большая система с сотнями или тысячами телефонов не будет хорошо обслуживаться этим решением, так как будет увеличена нагрузка на систему из-за почти постоянного потока регистраций с удаленных телефонов. В таком случае потребуется более продуманное решение об общей конструкции (например, вместо Asterisk можно использовать выделенный сервер регистратора для обработки трафика регистрации).

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

Астериск за NAT

Второй сценарий заключается в том, что Астериск находится за NAT, как показано на Рисунке 7-4.

В этом случае у нас есть несколько способов написать заголовки SIP в дружеской манере к другому концу.

Существуют два основных параметра, когда Asterisk находится за NAT: externip и externhost. Использование этих параметров — является решением либо-одно-либо-другое, поскольку они эффективно выполняют ту же функциональность: составляют заголовок SIP, используя внешний адрес интерфейса. Поскольку у нашего Asterisk будет немаршрутизируемый через Интернет IP-адрес (мы за NAT), мы можем указать Asterisk, каков его внешний адрес маршрутизации, чтобы разместить его в заголовках нашего SIP-сообщения.

Если наш внешний IP-адрес был чем-то вроде 98.139.183.24, мы могли бы установить externip следующим образом:

externip=98.139.183.24

Мы также можем указать номер порта, на который следует ответить:

externip=98.139.183.24:9999

Если номер порта не указан, будет использоваться номер порта, указанный с помощью параметра udpbindaddr.

В качестве альтернативы вы можете использовать опцию externhost, которая похожа на externip, но IP-адрес будет установлен каждый раз, когда chan_sip.so загружается в память (или при последующих перезагрузках).¹⁵ Формат похож на externip, за исключением того, что вы используете имя хоста. Вы также можете указать номер порта. Например:

externhost=pbx.shifteight.org:9999

Если вы хотите периодически обновлять внешнее имя хоста, вы можете использовать опцию externrefresh. Значение указано в секундах:

externhost=pbx.shifteight.org:5060

externrefresh=300

Если вы развернули сервер Asterisk за NAT вполне вероятно что к нему также будут подключены локальные телефонные аппараты. Мы не хотим искажать заголовки SIP-сообщений, которые отправляем нашим локальным аппаратам, поэтому мы можем указать, какие IP-адреса считаются частью нашей локальной сети. Таким образом, Asterisk будет отвечать просто с заголовками, как они были бы во внутренней сети. Мы используем параметр localnet, чтобы указать, какие сети считаются локальными для нашей системы Asterisk.

Также важно установить параметр localnet, даже если никакие локальные устройства не будут взаимодействовать с Asterisk, поскольку сама система Asterisk является частью локальной сети. Использование опции localnet в сочетании с externip или externhost поможет Asterisk понять, какие сетевые адреса нужно искать в заголовках SIP, чтобы переписать.

Опция localnet принимает формат IP-адреса и маски подсети. Вы можете использовать нотацию CIDR или точечную нотацию. Допускается несколько записей:

externip=98.139.183.24

localnet=172.16.0.0/24

localnet=192.168.100.0/255.255.255.0

Обработка медиапотоков (RTP)

В этом разделе мы рассмотрим, как Asterisk обрабатывает медиапотоки и наметим некоторые доступные вам параметры. Если у вас простая сетевая топология, где Asterisk подключается напрямую к ТфОП через традиционное оборудование (аналоговые или цифровые соединения), а ваши пиры находятся в одной локальной сети где и Asterisk, конфигурация по умолчанию, вероятно, прекрасна, и вы можете перейти к в следующему разделу. Если вы подключаетесь к провайдеру интернет-телефонии (ITSP) через SIP вы можете начать с установки directmedia=no в файле sip.conf. Если у вас нет причины перенаправлять медиаданные вне Asterisk, то использование directmedia=no обычно упрощает конфигурацию:

• Asterisk всегда будет использовать симметричный режим RTP, как определено в RFC 4961,¹⁶ что означает, что Asterisk всегда будет отправлять пакеты из того же порта, на который он первоначально принимал их. Текст в RFC 4961 довольно короткий и полезно прочитать о том, как Asterisk будет обрабатывать RTP между конечными точками. Эти знания должны упростить ваши усилия по созданию сети, если вы планируете обрабатывать пиров вне локальной сети в любой момент в будущем.
• Если вам нужно переопределить IP-адрес, используемый для медиапотока, вы можете сделать это с помощью параметра media_address. Эта опция позволит вам игнорировать медиа-адрес, указанный в заголовках SDP¹⁷, и направлять медиапоток в другое место. Использование параметра media_address не может быть установлено для пира: это только общая (глобальная) опция.
• По умолчанию Asterisk будет пытаться сделать re-INVITE медиапотока непосредственно между конечными точками. Перенаправление медиа происходит, когда Asterisk определяет, что ему не нужно оставаться на пути к медиапотокам. (Времена, когда Asterisk должен находиться на медиа-пути, включают запись вызова и прослушивание DTMF.) Когда Asterisk находится за пределами сети, где конечные точки находятся за NAT, перенаправление медиа работает не очень хорошо (или вообще). В этом случае вы должны использовать опцию directmedia=no, чтобы предотвратить перенаправление медиапотока. Значение по умолчанию — directmedia=yes, поэтому, если у вас есть конечные точки за NAT, которые не являются частью Asterisk, вы должны установить опцию directmedia=no.

Изменение параметра directmedia влияет только на re-INVITE медиапотоков, а не на другие случаи re-INVITE, такие, как во время переговоров T.38.

Существует опция, позволяющая Asterisk перенаправлять медиапотоки между конечными точками в той же сети, что и Asterisk, по крайней мере, как это определено в ядре RTP. Включение перенаправления медиапотоков в локальной сети может осуществляться с помощью directmedia=nonat. Если вы хотите выполнить UPDATE вместо re-INVITE при перенаправлении медиапотока, вы можете сделать это с помощью directmedia=update. Если вы комбинируете update с nonat (например, directmedia=nonat,update), вы фактически выполняете directmedia=yes.

Если у вас есть пир, который, как вы знаете, сам собирается отправить Asterisk re-INVITE при входящем вызове, вы можете установить directmedia=outgoing, чтобы дать указание Asterisk не беспокоиться о попытке re-INVITE для медиа от этого пира (поскольку ожидается что это попытается сделать дальний конец). Установка этой опции помогает избежать ситуаций, когда оба конца одновременно пытаются перенаправить медиапоток после начальной настройки вызова (см. Рисунки 7-5 и 7-6).

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

Asterisk также может попытаться настроить медиапотоки непосредственно между пирами без re-INVITE, включив directrtpsetup=yes. Однако использование directrtpmedia связано с некоторыми предостережениями; он считается экспериментальным и не будет работать для видео или случаев, когда вызываемый отправляет RTP-сообщения и заголовки fmtp в 200 OK, которые не соответствуют INVITE вызывающего. Кроме того, эта опция не может использоваться, когда узлы находятся за NAT.

Вы можете контролировать, какие конечные точки могут пытаться отправлять directmedia друг другу с помощью directmediadeny и directmediapermit. Это полезно в ситуациях, когда ваша сетевая топология не позволяет определенным сетям передавать медиа друг другу, вместо этого требуется, чтобы медиапоток протекал через Asterisk. Примером использования было бы запретить все медиа-потоки между сетями, а затем явно разрешить определенным сетям отправлять directmedia:

directmediadeny=0.0.0.0/0

directmediapermit=192.168.101.0/24

directmediapermit=172.16.1.0/24

Как вы можете видеть, существует несколько параметров, которые позволяют вам контролировать, как медиапотоки обрабатываются Asterisk. Такая гибкость делает Asterisk настолько привлекательным для использования во многих сетях. С правильным набором опций (и большим количеством терпения) вы должны иметь возможность обрабатывать практически любые сетевые препятствия.

Терминация ТфОП

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

Asterisk может использоваться в качестве точки терминации ТфОП. Фактически, учитывая что Asterisk легко справляется с преобразованием протоколов, это может быть отличным использованием для системы Asterisk.

Чтобы обеспечить терминацию Asterisk должен будет обрабатывать все протоколы, которые вы хотите подключить к ТфОП. В общем, это означает, что вашему Asterisk потребуется схема PRI для обработки вызовов между ТфОП и SIP-каналами, поступающими из сети VoIP. Основополагающий принцип тот же, независимо от того, используете ли вы небольшую систему, предоставляющую соединительные линии ТфОП в офис, полный VoIP-телефонов, или сложную сеть шлюзовых машин, развернутых в стратегических сетях, предлагая терминацию тысячам абонентов.

Вызовы из сети VoIP будут поступать в диалплан в любом контексте, который вы назначили входящим SIP-каналам, а диалплан будет передавать вызовы через интерфейс ТфОП. В самом простейшем случае часть диалплана, поддерживающая терминацию, может выглядеть так:

[from-voip-network]

exten => _X.,1,Verbose(2, Call from VoIP network to ${EXTEN})

same => n,Dial(DAHDI/g0/${EXTEN})

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

Учитывая, что большинство линий ТфОП позволят вам набирать любой номер в любом месте в мире и учитывая, что вы будете оплачивать все расходы, мы не можем подчеркнуть важность безопасности на любом шлюзовом компьютере, предоставляющем терминацию ТфОП. Преступники приложили немало усилий для взлома телефонных систем (особенно плохо защищенных систем Asterisk), и если вы не будете уделять пристальное внимание всем аспектам безопасности, вы станете жертвой мошенничества с платной подпиской. Это только вопрос времени.

Не допускайте никаких незащищенных VoIP-соединений в любой контекст, который содержит терминацию ТфОП.

Инициирование ТфОП

Очевидно, что если вы хотите передавать вызовы из вашей VoIP-сети в ТфОП, вы также можете иметь возможность принимать вызовы из ТфОП в вашу VoIP-сеть. Процесс выполнения этого обычно называют инициированием (оригинацией). Это просто означает, что вызов инициирован в ТфОП.

Для обеспечения инициирования требуется номер телефона. Поэтому вам нужно будет получить линию от вашей местной телефонной компании, которую вы подключите к вашей системе Asterisk. В зависимости от того, где вы находитесь в мире, существует несколько различных типов линии, которые могут обеспечить эту функциональность, от базовой аналоговой линии POTS до конвейера несущей SS7.

Телефонные номера, используемые для целей инициирования, обычно называются номерами прямого входящего набора (DID). Это не относится строго ко всем ситуациям (например, номер телефона на традиционной аналоговой линии не будет считаться DID), но термин достаточно полезен, чтобы прижиться. Исторически DID ссылался на номер телефона, связанный с транком, подключенным к оборудованию клиента (CPE).

Поскольку номера телефонов контролируются традиционной телекоммуникационной отраслью, вам нужно будет получить номер либо от поставщика напрямую, либо от одной из многих компаний, которые покупают номера оптом и перепродают их в меньших блоках. Если вы получите линию, такую как PRI, вы, как правило, сможете заказать номера DID, которые будут подключены по этой линии.

Чтобы принять вызов из сети, которую вы используете для инициирования, вам, как правило, придется обрабатывать передачу номера телефона, который был вызван. Это связано с тем, что соединительные линии ТфОП обычно могут обрабатывать более одного номера телефона, и поэтому поставщику необходимо определить, какой номер был вызван, чтобы ваша система Asterisk знала, как маршрутизировать вызов. Номер, который был набран, обычно называется номером сервиса предоставления информации о набранном номере (Dialed Number Information Service — DNIS). Номер DNIS и DID не должны совпадать,¹⁸ но как правило будут. Если вы заказываете линию у поставщика, вам нужно попросить, чтобы он отправил DNIS (если он этого не понимает, вы можете рассмотреть другого поставщика).

В диалплане вы связываете входящую линию с контекстом, который будет знать, как обрабатывать входящие номера. Например, он может выглядеть примерно так:

[from-pstn]

; Этот контекст будет указан в файле конфигурации для схемы

; (например chan_dahdi.conf)

exten => _X.,1,Verbose(2,Incoming call to ${EXTEN})

same => n,Goto(number-mapping,${EXTEN},1)

[number-mapping]

; Этот контекст не является строго обязательным, но он облегчит

; отслеживание ваших DID в одном месте в вашем диалплане.

; Отсюда Вы можете передать вызов другой части диалплана,

; где будет выполняться фактическая обработка в диалплане

exten => 4165551234,1,Dial(SIP/0000FFFF0001)

exten => 4165554321,1,Goto(autoattendant-context,start,1)

exten => 4165559876,1,VoiceMailMain() ; удобный черный ход для прослушки голосовых сообщений

exten => i,1,Verbose(2,Incoming call to invalid number)

В контексте number-mapping вы явно перечисляете все DID, которые вы планируете обрабатывать, а также недопустимый обработчик для любых DID, которые не указаны (вы можете отправить недопустимые числа на ресепшен или автосекретарю или в какой-то контекст который воспроизводит оповещение о неверном назначении).

VoIP в VoIP

В конце концов, потребность в ТфОП, скорее всего, исчезнет и большинство голосовых коммуникаций будет происходить по сетевым соединениям.

Первоначальное представление, лежащее в основе протокола SIP, состояло в том, что он должен был быть протоколом одноранговой сети. Технически это все еще так. Тем не менее, такие вопросы, как безопасность, конфиденциальность, корпоративные политики, интеграция, централизация и т.д. сделали вещи немного более сложными, чем просто размещение URI в SIP-телефон и возможность иметь телефон SIP где-то в другом месте.

Неавторизованные вызовы через SIP

Как мы отметили в Главе 5, вы можете настроить контекст unauthenticated в разделе general файла sip.conf и установить allowguest=yes. Делая это, вы разрешаете неаутентифицированные звонки в ваш диалплан. Это требование справедливо и когда вы хотите принимать вызовы так же, как и по электронной почте. (SIP URI будет похож на sip:[email protected], который похож на mail:[email protected].) После того, как вы настроили свой неаутентифицированный контекст в extensions.conf, просто включите все, что вы хотели бы сделать общедоступным из внешнего мира; или создайте новый контекст для включения в ваш неаутентифицированный контекст. Например, вы можете создать GoSub(), который может искать электронные адреса и внутренние номера пользователей в вашей базе данных или сервере LDAP и маршрутизировать вызовы на основе SIP URI, которые соответствуют их адресам электронной почты.

Протокол SIP стал раздутым и сложным. Внедрение систем и сетей на базе SIP, возможно, станет еще более сложным, чем внедрение традиционных телефонных АТС и сетей.¹⁹

Мы не собираемся заниматься сложностями проектирования и реализации VoIP-сетей в этой книге, но мы обсудим некоторые из способов, которыми вы можете настроить Asterisk для поддержки VoIP-подключения к другим системам VoIP.

Настройка транков VoIP

В Asterisk нет необходимости явно устанавливать ваши VoIP-модули (если по какой-то причине вы не скомпилировали Asterisk с необходимыми модулями). Существует несколько протоколов VoIP, которые вы можете использовать с Asterisk, но мы сосредоточимся на двух самых популярных: SIP и IAX.

Настройка SIP-транков между Астериск-системами

SIP — это самый популярный VoIP-протокол — настолько, что многие люди считают, что другие протоколы VoIP устарели (это не так, но нельзя отрицать, что SIP доминирует в VoIP уже много лет).

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

Соединение двух систем Asterisk посредством SIP. Возможность одновременного соединения двух систем Asterisk, позволяющих осуществлять вызовы между ними, является довольно распространенным требованием. Возможно, у вас есть компания с двумя офисами и вы хотите иметь АТС в каждом из них, или, может быть, вы являетесь администратором УАТС компании, и вам нравится Asterisk так сильно, что вы также хотели бы установить его дома. В этом разделе приводится краткое руководство по настройке двух серверов Asterisk для передачи вызовов друг другу по протоколу SIP. В нашем примере мы будем ссылаться на два сервера как serverA и serverB.

Первый файл, который необходимо изменить, — /etc/asterisk/sip.conf. Это основной конфигурационный файл для настройки учетных записей SIP. Во-первых, эта запись должна быть добавлена в sip.conf на serverA. Он определяет SIP-пиров для другого сервера:

[serverB]

;

; Укажите тип учетной записи SIP как ‘peer’. Это означает, что входящие

; вызовы будут сопоставляться по IP-адресу и номеру порта. Таким образом,

; когда Астериск получает вызов от 192.168.1.102 и стандартный SIP порт 5060,

; он будет соответствовать этой записи в sip.conf. Затем он попросит

; аутентификацию и ожидает что пароль будет соответствовать, указанному

; здесь в поле ‘secret’.

;

type = peer

;

; Это IP-адрес удаленного сервера (serverB). Эта опция также может быть

; представлена как имя хоста.

;

host = 192.168.1.102

;

; Когда мы отправляем вызовы этому SIP-пиру и предоставляем аутентификацию

; мы используем ‘serverA’ как наше имя пользователя по умолчанию.

;

defaultuser = serverA

;

; Это общий с serverB пароль. Он будет использоваться в качестве

; пароля при принятии вызова от serverB, либо при отправке вызова на serverB.

;

secret = apples

;

; При получении вызова от serverB сопоставляйте его с внутренними номерами

; в контексте «incoming» из extensions.conf.

;

context = incoming

;

; Начните с запрета списка разрешенных кодеков.

;

disallow = all

;

; Разрешите только кодек ulaw.

;

allow = ulaw

Обязательно измените параметр host, чтобы он соответствовал IP-адресу для вашей собственной настройки.

Теперь добавьте следующую запись в /etc/asterisk/sip.conf на serverB. Она почти идентична содержимому записи, помещенной на serverA, но имя пира и IP-адрес будут изменены:

[serverA]

type = peer

host = 192.168.1.101

defaultuser = serverB

secret = apples

context = incoming

disallow = all

allow = ulaw

На этом этапе вы должны убедиться, что конфигурация была успешно загружена в Астериск с использованием некоторых команд CLI. Первая команда, которую нужно попробовать, это sip show peers. Как следует из названия, в нем будут показаны все настроенные SIP-узлы:

*CLI> sip show peers

Name/username Host Dyn Forcerport ACL Port Status

serverB/serverA 192.168.1.101 5060 Unmonitored

1 sip peers [Monitored: 0 online, 0 offline Unmonitored: 1 online, 0 offline]

Вы также можете попробовать sip show peer serverB. Эта команда покажет гораздо больше деталей.

Последним шагом в настройке SIP-вызовов между двумя серверами Asterisk является изменение диалплана в файле /etc/asterisk/extensions.conf. Например, если вы хотите, чтобы любые вызовы, сделанные с serverA на внутренние номера с 6000 по 6999 поступали на serverB, вы должны использовать эту строку в диалплане:

exten => _6XXX,1,Dial(SIP/${EXTEN}@serverB)

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

Если вы будете получать звонки от провайдера, то он, скорее всего, потребует, чтобы ваш сервер зарегистрировался на одном из его серверов. Для этого вы должны добавить строку регистрации в раздел [general] в /etc/asterisk/sip.conf:

[general]

…

register => username:[email protected]

…

Затем вам нужно будет создать запись пира в sip.conf для вашего провайдера. Вот пример записи для пира:

[myprovider]

type = peer

host = your.provider.tld

defaultuser = username

secret = password

; Большинство провайдеров не будут аутентифицироваться, когда отправляют вам

; звонки, поэтому вам нужна эта строка, чтобы просто принять их вызовы.

insecure = invite

dtmfmode = rfc2833

disallow = all

allow = ulaw

Теперь, когда учетная запись определена, вы должны добавить некоторые расширения в диалплан, чтобы отправлять звонки своему провайдеру:

exten => _1NXXNXXXXXX,1,Dial(SIP/${EXTEN}@myprovider)

Шифрование SIP-вызовов. Asterisk поддерживает TLS для шифрования SIP-сигнализации и Secure Realtime Transport Protocol (SRTP) для шифрования медиапотоков телефонного вызова. В этом разделе мы будем настраивать вызовы с использованием SIP TLS и SRTP между двумя серверами Asterisk. Первым шагом является обеспечение правильных зависимостей. Убедитесь, что установлены как OpenSSL, так и LibSRTP. Если один из них не был установлен, переустановите Asterisk после установки этих зависимостей чтобы включить поддержку TLS и SRTP. После завершения убедитесь, что модуль res_srtp был скомпилирован и установлен. Чтобы установить OpenSSL, необходим пакет openssl-devel на RHEL и libssl-dev на Ubuntu. Для установки LibSRTP пакет будет libsrtp-devel на RHEL и libsrtp0-dev на Ubuntu.

Затем мы настроим SIP TLS. Вы должны включить TLS, используя глобальную опцию tlsenable в разделе [general] в /etc/asterisk/sip.conf на обоих серверах. Вы можете указать адрес для привязки, если хотите ограничить прослушивание TLS-соединений одним IP-адресом в системе. В этом примере у нас есть адрес подкаталога IPv6, указанный для разрешения соединений TLS на всех адресах IPv4 и IPv6 в системе:

[general]

tlsenable = yes

tlsbindaddr = ::

Следующий шаг — получить сертификаты. В целях демонстрации конфигурации и функциональности мы собираемся создавать самоподписанные сертификаты, используя вспомогательный скрипт, распространяемый вместе с Asterisk. Если вы устанавливаете его в производственной среде, вы можете не захотеть использовать самоподписанные сертификаты. Однако, если вы это сделаете, есть несколько приложений, которые помогают упростить управление вашим собственным центром сертификации (Certificate Authority — CA), например TinyCA.

Сценарий, который мы собираемся использовать, — ast_tls_cert, который находится в каталоге /contrib/scripts дерева исходников Asterisk. Нам нужно создать сертификат CA и два сертификата сервера. Первый вызов ast_tls_cert будет генерировать сертификат CA и серверный сертификат для serverA. Второй вызов ast_tls_cert будет генерировать серверный сертификат для serverB:

$ cd contrib/scripts

$ mkdir certs

$ ./ast_tls_cert -d certs -C serverA -o serverA

$ ./ast_tls_cert -d certs -C serverB -o serverB -c certs/ca.crt -k certs/ca.key

$ ls certs

ca.cfg ca.crt ca.key serverA.crt serverA.csr serverA.key serverA.pem

serverB.crt serverB.csr serverB.key serverB.pem tmp.cfg

Теперь, когда сертификаты созданы, их необходимо перенести в соответствующие места на serverA и serverB. Мы будем использовать каталог /var/lib/asterisk/keys для хранения сертификатов. Переместите следующие файлы на serverA:

• ca.crt
• serverA.pem

И переместите эти файлы на serverB:

• ca.crt
• serverB.pem

Имея сертификаты, мы можем завершить настройку Asterisk. Нам нужно указать Asterisk на сертификат сервера, который мы только что создали. Поскольку мы используем самоподписанные сертификаты, нам также нужно указать сертификат CA. В разделе [general] файла /etc/asterisk/sip.conf на serverA добавьте следующие параметры:

[general]

tlscertfile = /var/lib/asterisk/keys/serverA.pem

tlscafile = /var/lib/asterisk/keys/ca.crt

Внесите те же изменения в sip.conf на serverB:

[general]

tlscertfile = /var/lib/asterisk/keys/serverB.pem

tlscafile = /var/lib/asterisk/keys/ca.crt

Когда вы создаете сертификат сервера, поле «Common Name» должно соответствовать имени хоста сервера. Если вы используете скрипт ast_tls_cert, это значение задается с параметром -­C. Если при выполнении вызова возникает проблема с проверкой сертификата сервера, вам может потребоваться исправить поле «Common Name». В качестве альтернативы, для тестирования вы можете установить для параметра tlsdontverifyserver значение yes в разделе [general] в файле /etc/asterisk/sip.conf, и Asterisk разрешит вызов даже если он не сможет проверить сертификат сервера.

В разделе «Соединение двух систем Asterisk посредством SIP» мы создали конфигурацию, необходимую для передачи вызовов между серверами. Теперь мы собираемся изменить эту конфигурацию, чтобы Asterisk знал, что вызовы между двумя серверами должны быть зашифрованы. Единственное изменение, которое необходимо сделать, это добавить параметр transport=tls в запись пира для другого сервера.

На serverA:

[serverB]

type = peer

host = 192.168.1.102

defaultuser = serverA

secret = apples

context = incoming

disallow = all

allow = ulaw

transport = tls

На serverB:

[serverA]

type = peer

host = 192.168.1.101

defaultuser = serverB

secret = apples

context = incoming

disallow = all

allow = ulaw

transport = tls

Теперь, когда вы совершаете вызов с использованием Dial(SIP/serverA) или Dial(SIP/serverB), сигнализация SIP будет зашифрована. Вы можете изменить диалплан, чтобы заставить исходящие вызовы иметь зашифрованную сигнализацию, установив для функции CHANNEL(secure_bridge_signaling) значение 1:

[default]

exten => 1234,1,Set(CHANNEL(secure_bridge_signaling)=1)

same => n,Dial(SIP/1234@serverB)

На стороне принимающей вызов, вы можете проверить зашифрована ли сигнализация входящего вызова с помощью функции диалплана CHANNEL(secure_signaling). Рассмотрим следующий пример диалплана:

[incoming]

exten => _X.,1,Answer()

same => n,GotoIf($[«${CHANNEL(secure_signaling)}» = «1»]?secure:insecure)

same => n(secure),NoOp(Signaling is encrypted.)

same => n,Hangup()

same => n(insecure),NoOp(Signaling is not encrypted.)

same => n,Hangup()

Когда вызов отправляется с serverA на serverB с помощью этой конфигурации, вы можете видеть из вывода в консоли Asterisk, что диалплан определяет, что передача сигнала входящего вызова шифруется:

— Executing [1234@incoming:1] Answer(«SIP/serverA-00000000», «») in new stack

— Executing [1234@incoming:2] GotoIf(«SIP/serverA-00000000», «1?secure:insecure») in new stack

— Goto (incoming,1234,3)

— Executing [1234@incoming:3] NoOp(«SIP/serverA-00000000», «Signaling is encrypted.») in new stack

— Executing [1234@incoming:4] Hangup(«SIP/serverA-00000000», «») in new stack

Теперь, когда SIP TLS настроен для вызовов между serverA и serverB, мы настроим SRTP так, чтобы медиапотоки, связанные с вызовом, также были зашифрованы. К счастью, это довольно легко настроить, по сравнению с тем, что требовалось для работы SIP TLS. Во-первых, убедитесь, что у вас есть модуль res_srtp, загруженный в Asterisk:

*CLI> module show like res_srtp.so

Чтобы включить SRTP, установите для функции CHANNEL(secure_bridge_media) значение 1:

[default]

exten => 1234,1,Set(CHANNEL(secure_bridge_signaling)=1)

same => n,Set(CHANNEL(secure_bridge_media)=1)

same => n,Dial(SIP/1234@serverB)

Это означает, что для исходящего вызова требуется зашифрованный медиапоток. Когда вызов отправляется через SIP, Asterisk потребует использования SRTP или вызов завершится с ошибкой.

Используя все эти инструменты, вы можете гарантировать, что вызовы между двумя серверами Asterisk будут полностью зашифрованы. Те же методы должны применяться для шифрования вызовов между Asterisk и SIP-телефоном.

Функции диалплана предоставляют механизм для проверки состояния шифрования входящего вызова и принудительного шифрования исходящего вызова. Однако, имейте в виду, что эти инструменты предоставляют только средства для управления шифрованием для одного хопа пути вызова. Если вызов проходит через несколько серверов, эти инструменты не гарантируют, что вызов зашифрован по всему пути вызова. Важно внимательно рассмотреть какие требования необходимы для безопасных вызовов, и предпринять все необходимые шаги для обеспечения соблюдения этих требований на протяжении всего пути вызова. Безопасность сложная и тяжелая работа.

Настройка IAX-транков между системами Астериск

Протокол Inter-Asterisk eXchange 2 версии (наиболее известный как IAX), является собственным VoIP-протоколом Asterisk. Он отличается от SIP тем, что сигнализация и медиапотоки переносятся в одном и том же соединении. Это различие является одним из преимуществ протокола IAX, поскольку он значительно упрощает работу IAX для работы с NAT-соединениями.

IAX транкинг. Одной из наиболее уникальных особенностей протокола IAX является IAX-транкинг. Транкинг соединения IAX может быть полезен на любом сетевом соединении, которое часто будет выполнять несколько одновременных VoIP-вызовов между двумя системами. Инкапсулируя несколько аудиопотоков в один пакет, IAX-транкинг сокращает накладные расходы при подключении к данным, что позволяет сэкономить полосу пропускания на сильно загруженном соединении.

IAX шифрование. Основным преимуществом шифрования IAX является то, что для файла /etc/asterisk/iax.conf требуется одно простое изменение:

[general]

encryption = yes

Для дополнительной защиты вы можете установить следующий параметр, чтобы гарантировать отсутствие соединения IAX без шифрования:

forceencryption = yes

Оба эти параметра можно указать в разделе [general], а также в разделах peer/user/friend в iax.conf.

Экстренный набор

В Северной Америке люди привыкли к тому, чтобы набирать номер 911 для получения экстренной помощи. За пределами Северной Америки общеизвестные номера службы экстренной помощи — 112 и 999. Если вы предоставляете свою систему Asterisk людям, вы обязаны (во многих случаях регламентируется) обеспечить, чтобы звонки могли идти в службы экстренной помощи с любого подключенного телефона (даже с телефонов, которые ограничиваются выполнением вызовов).

Одна из существенных частей информации, которую должна знать организация реагирования на чрезвычайные ситуации — это место чрезвычайной ситуации (например, куда отправлять пожарные машины). В традиционном ТфОП транке эта информация уже известна поставщику услуг и затем передается вместе с Public Safety Answering Point (PSAP). С помощью VoIP-схем все может усложниться, поскольку VoIP-линии физически не привязаны к географическому положению.

Вам необходимо убедиться что ваша система будет правильно обрабатывать вызовы 911 с любого телефона, подключенного к ней, и вам нужно сообщить, что доступно вашим пользователям. Например, если вы разрешаете пользователям регистрироваться в системе с софтфонов на своих ноутбуках; что происходит, если они находясь в гостиничном номере в другой стране, набирают номер 911?²⁰

Диалплан для обработки экстренных вызовов не должен быть сложным. На самом деле, будет гораздо лучше, если сохранить его простым. Люди часто испытывают соблазн внедрить всевозможные причудливые функции в частях своих диалпланов для аварийных служб, но если ошибка в одной из ваших причудливых функций приводит к сбою в экстренном вызове, жизнь может быть подвержена риску. Это не место для игры. Раздел [emergency-services] вашего диалплана может выглядеть примерно так:

[emergency-services]

exten => 911,1,Goto(dialpsap,1)

exten => 9911,1,Goto(dialpsap,1) ; некоторые люди наберут ‘9’, потому что

; привыкли так делать с УАТС

exten => 999,1,Goto(dialpsap,1)

exten => 112,1,Goto(dialpsap,1)

exten => dialpsap,1,Verbose(1,Call initiated to PSAP!)

same => n,Dial(${LOCAL}/911) ; ЗАМЕНИТЕ 911 НА ДРУГОЙ

; СООТВЕТСТВУЮЩИЙ ВАШЕЙ МЕСТНОСТИ

[internal]

include => emergency-services ; это должно быть в любом контексте

; в котором есть пользователи

В тех контекстах, где вы знаете, что пользователи не находятся на месте (например, удаленные пользователи со своими ноутбуками), что-то вроде этого может быть лучше:

[no-emergency-services]

exten => 911,1,Goto(nopsap,1)

exten => 9911,1,Goto(nopsap,1) ; для людей, набирающих ‘9’ для внешних вызовов

exten => 999,1,Goto(nopsap,1)

exten => 112,1,Goto(nopsap,1)

exten => nopsap,1,Verbose(1,Call initiated to PSAP!)

same => n,Playback(no-emerg-service) ; вам нужно записать это приглашение

[remote-users]

include => no-emergency-services

В Северной Америке правила обязывали многих VoIP-операторов предлагать то, что широко известно как E911.²¹ Когда вы подписываетесь на эти услуги, они потребуют адресную информацию для каждого DID, который вы хотите связать с исходящими вызовами. Затем эта адресная информация будет отправлена в PSAP, соответствующий этому адресу, и ваши вызовы с чрезвычайной ситуацией должны обрабатываться так же, как если бы они были набраны на традиционной линии ТфОП.

Суть в том, что вам нужно убедиться, что созданная вами телефонная система позволяет совершать экстренные вызовы.

Вывод

Мы считаем, что ТфОП, в конце концов, полностью исчезнет. Однако, прежде чем это произойдет, потребуется широко распространенный и надежный механизм распределения, позволяющий организациям и частным лицам публиковать адресную информацию, чтобы их можно было найти. Мы рассмотрим некоторые из способов, которые уже возможны в Главе 12.

1Но не требуйте 200 долларов.

2В ключевой системе каждая линия имеет соответствующую кнопку на каждом телефоне, а линии доступны по нажатию нужной клавиши.

3Вы можете назвать как пожелаете. Слова «local» и «toll» не имеют никакого встроенного значения для диалплана Астериска.

4Для получения дополнительной информации о шаблонах см. Главу 6.

5Вы бы использовали ту же самую карту, если бы хотели подключить традиционную домашнюю телефонную линию к вашей системе Asterisk.

6Не спрашивайте.

7Существуют и другие способы получения источника синхронизации, и если вам нужна действительно плотная система, можно запустить Asterisk без DAHDI, но это не то, что мы рассмотрим здесь.

8 Иногда схемы ссылаются на количество B- и D-каналов, которые они содержат, поэтому один T1, использующий протокол PRI в Северной Америке, может называться 23B + D, а двойная схема T1 с резервным D-каналом будет a 46B + 2D. Мы даже видели PRI, на который ссылается как nB + nD, хотя это может стать немного педантичным.

9Теоретически эти карты могут использоваться для любого программного обеспечения, поддерживающего DAHDI; поэтому основная конфигурация карты не входит в Asterisk.

10В любом контексте нет ничего особенного. Мы могли бы назвать этот контекст [stuff_that_comes_in], и до тех пор, пока это был контекст, назначенный в определении канала в sip.conf, iax.conf, chan_dahdi.conf и др., канал войдет в диалплан в этом контексте. Сказав это, настоятельно рекомендуется указывать имена ваших контекстов, которые помогут вам понять их цель. Некоторые хорошие имена контекстов могут включать в себя [incoming], [local_calls], [long_distance], [sip_telephones], [user_services], [experimental], [remote_locations] и т. д. Всегда помните, что контекст определяет, как канал входит в диалплан, поэтому укажите его соответствующим образом.

11Страница Википедии по трансляции сетевых адресов на самом деле неплоха. Узнайте больше о разных типах NAT и о том, как работает NAT в целом, проверьте его!

12SIP не является единственным протоколом VoIP с использованием RTP для переноса медиапотоков.

13Да, вы могли бы одновременно использовать оба сценария, которые в народе называют «двойным NAT».

14Является ли это лучшим решением, мы еще не обсудили.

15Причина, по которой мы подчеркиваем этот факт, заключается в том, что если у вас нет надежной службы DNS, вы будете испытывать всевозможные неприятные действия в Asterisk, так как он терпеливо ждет, пока имена хостов будут разрешены, в то время как вы неустанно ожидаете от драйвера канала SIP запуска работы (проблемы разрешения DNS могут вызвать всевозможные странные действия в Asterisk).

16http://www.ietf.org/rfc/rfc4961.txt

17Session Description Protocol — компонент сообщения SIP, который определяет параметры мультимедиа.

18В традиционных АТС целью DID было разрешить подключение непосредственно к внутреннему номеру в офисе. Многие АТС не могли поддерживать такие понятия, как перевод чисел или гибкие длины цифр, и, таким образом, поставщику пришлось передавать внутренний номер в виде номера DID, а не номера, который был набран (номер DNIS). Например, номер телефона 416-555-1234, возможно, был отображен на добавочный номер 100, и, таким образом, оператор отправил цифры 100 в АТС вместо DNIS 4165551234. Если вы когда-либо заменяли старую АТС системой Астериск , вы можете найти этот перевод на месте, и вам нужно будет получить список сопоставлений между номерами, которые набираются абонентом, и номерами, которые отправляются в АТС. Также широко распространено мнение, что носитель передает только последние четыре цифры номера DNIS, который затем АТС преобразует во внутренний номер.

19На рынке существует много проприетарных систем АТС, которые имеют базовую конфигурацию, которая будет работать прямо из коробки. Развертывание Asterisk является гораздо более гибким, но редко бывает простым.

20 Не думайте, что этого не может случиться. Когда кто-то звонит 911, это потому, что у них случилась чрезвычайная ситуация, и небезопасно предположить, что они будут в адеквтном состоянии.

21На самом деле это предлагает не оператор, а скорее это возможность PSAP. E911 также используется на ТфОП транках, но поскольку она происходит без какого-либо участия с вашей стороны (поставщики ТфОП делают бумажную работу за вас), вы, как правило, не знаете, что у вас есть E911 на ваших местных линиях.