Конфигурация канала FXS аналогична настройке канала FXO. Рассмотрим ее подробнее.

Ниже представлена минимальная конфигурация для канала FXS платы TDM400P. Эта конфигурация аналогична приведенной выше конфигурации канала FXO, добавлена только строка fxoks=1. Из наших предыдущих обсуждений вы должны помнить, что для каналов 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)

Следующая конфигурация аналогична настройке канала 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=phones ; Используется контекст [internal], описанный в ex.tensions.conf signalling=fxo_ks ; Для канала FXS используется протокол обмена сигналами FXO

channel => 1 ; Телефон подключается к порту 1

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 будет возвращать все, что вы скажете.

Протокол 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.