предыдущих обсуждений вы должны помнить, что для каналов FXO и FXS используются противоположные типы протоколов обмена сигналами, поэтому для канала FXS мы зададим протокол FXO. В приведенном ниже примере канал 1 конфигурируется на использование протокола FXO с протоколом обмена сигналами kewlstart:
fxoks=1
fxsks=2
loadzone=us
defaultzone=us
После загрузки драйверов для своего оборудования можно проверить статус оборудования с помощью команды /sbin/ztcfg -vv:
Zaptel Configuration Channel map:
Channel 01: FXO Kewlstart (Default) (Slaves: 01)
Channel 02: FXS Kewlstart (Default) (Slaves: 02)
Конфигурация оборудования Zapata
Следующая конфигурация аналогична настройке канала FXO, добавлен только раздел для FXS-порта и строка immediate=no. Контекстом FXS-порта является phones, протокол обмена сигналами - fxoks (kewlstart), номер канала - 1.
Каналы FXS можно сконфигурировать на выполнение одного из двух различных действий при снятии трубки телефона. Наиболее часто используемым (и обычно предпочтительным) вариантом для Asterisk является воспроизведение тонального сигнала готовности линии и ожидание ввода пользователя. Это действие конфигурируется строкой immediate=no. Альтернатива для Asterisk - вместо воспроизведения тонового сигнала автоматическое выполнение набора инструкций, заданных в диалплане. Такое поведение определяется строкой immediate=yes[59]. Инструкции, которые должны выполняться для канала, находятся в заданном для него контексте и будут соответствовать добавочному номеру s (обе эти темы будут обсуждаться подробнее в следующей главе).
Вот наш новый файл zapata.conf:
[trunkgroups]
; описание всех магистральных групп
[channels]
; аппаратные каналы
; значения по умолчанию
usecallerid=yes
hidecallerid=no
callwaiting=no
threewaycalling=yes
transfer=yes
echocancel=yes
echotraining=yes
immediate=no
; описание каналов
context=incoming ; Входящие вызовы направляются в контекст [incoming],
; описанный в extensions.conf signalling=fxs_ks ; Для канала FXO используется протокол обмена сигналами FXS channel => 2 ; PSTN подключается к порту 2
Конфигурация диалплана
Мы воспользуемся простейшим диалпланом, сконфигурированным ранее в данной главе для тестирования FXS-порта с помощью приложения Echo(). Соответствующий раздел, который уже должен присутствовать в диалплане, выглядит следующим образом:
[internal]
exten => 500,1,Verbose(1|Echo test application) exten => 500,n,Echo() exten => 500,n,Hangup()
[phones]
include => internal Приложение Echo() будет возвращать все, что вы скажете.
Конфигурация SIP-телефонов
Протокол Session Initiation Protocol (SIP)[60], обычно применяемый в VoIP-телефонах (как аппаратных, так и программных), отвечает за установку и разъединение соединения, а также за любые изменения, происходящие во время соединения, такие как переадресации. Назначение SIP - помочь двум конечным точкам поговорить друг с другом (по возможности напрямую). Протокол SIP - это просто протокол обмена сигналами, то есть его задачей является лишь обеспечить возможность двум конечным точкам говорить друг с другом, но не работа с носителем вызова (голосом). Передача голоса осуществляется с помощью другого протокола - Real-Time Transport Protocol (транспортный протокол реального времени - RTP; RFC 3550) - для передачи медиа-данных непосредственно между двумя конечными точками.
Термин «медиа-данные» используется здесь для обозначения данных, передаваемых между конечными точками и используемых для воссоздания голоса на противоположном конце провода. Также он может использоваться в случае воспроизведения музыки или голосовых сообщений офисной АТС.
В мире SIP конечные точки называются агентами пользователя, которые могут быть двух типов: клиент и сервер. Клиент - это конечная точка, формирующая запрос, а сервер обрабатывает этот запрос и формирует ответ. Когда конечная точка желает выполнить вызов другой конечной точки (например, наш программный телефон звонит на другой программный телефон), она формирует запрос и отправляет его на прокси-сервер SIP[61]. Прокси-сервер принимает запрос, определяет его место назначения и направляет его туда. Если два агента пользователя успешно договорились и установили вызов, переносимый сигнал передается по RTP-протоколу и пересылается непосредственно от одного агента пользователя другому. SIP-прокси не обрабатывают медиа-данные; они просто работают с SIP- пакетами.
С другой стороны, Asterisk называют Back-To-Back User Agent (B2BUA). Это означает, что Asterisk действует как агент пользователя или в роли сервера (принимающий), или в роли клиента (посылающий). Итак, когда программный телефон звонит на добавочный номер, соединение устанавливается непосредственно между программным телефоном и Asterisk. Если логика, реализованная в Asterisk, определяет, что вызов адресован другому агенту пользователя, Asterisk действует как клиент и устанавливает другое соединение (известное как канал) с другим телефоном. При этом медиа-информация передается от телефона к телефону прямо через Asterisk[62]. С точки зрения телефонов они взаимодействуют непосредственно с Asterisk.
