Шаг 11. Первый звонок

Устройства зарегистрированы. Будем совершать звонок.

По известной из шага 10 схеме SIP-запрос INVITE попадает на SG и проксируется на B2BUA.

Особенность транзакции запроса INVITE состоит в том, что она наделена состояниями и управляема, в частности по ней можно отправить предварительные ответы, ее можно отменить запросом CANCEL. Результатом удачно отработанного запроса INVITE является создание SIP-диалога между двумя UA. Повтор: Обрабатывая SIP-запросы INVITE на совершение звонков, B2BUA выступает для инициатора запроса оппозитным UА. Он организует проверку авторизованности, маршрутизацию, поиск ответной стороны, а также организует второе плечо диалога, в том числе множественный вызов. Для обоих абонентов (вызывающего и вызываемого) он является полноценным UA, таким образом объединяя в рамках одного звонка два SIP-диалога. Различаются понятия SIP-диалог и B2B-диалог.

Следствие 1: При звонке от одного пользователя к другому между двумя SIP-устройствами всегда находится ровно 3 SIP-узла в цепочке – SG, B2B, SG. При этом если они зарегистрированы через один экземпляр SG, то это один и тот же SG, обслуживающий два плеча, то есть два SIP-диалога.

Следствие 2: SG инициатора звонка и B2BUA всегда располагаются на одном сайте, а SG получателя звонка может быть на любом сайте.

Следствие 3: B2BUA создает B2B-диалоги только по инициативе извне, таким образом в любом B2B-диалоге есть инициатор и есть получатель звонка. Тем не менее здесь есть одно исключение – функция перехвата – в одном диалоге соединяются два инициатора. Абонент А – тот из них, кто инициировал изначальный вызов, а абонент Б – кто вызвал код абонентской функции перехвата.

Аудио и видео данные, связанные со звонком, передаются по протоколу RTP. В рамках транзакции установления соединения стороны А и Б обмениваются дескрипторами медиа-стримов по протоколу SDP (завернут в тело запроса INVITE и ответа 200 OK). Передачей медиа-трафика занимается медиа-сервер в рамках роли MG. Производительность этой функции очень критична, и она реализована в отдельном приложении RTX, входящем в состав платформы. По сути роль MG есть обертка над медиа-сервером RTX.

MG (посредством медиа-сервера RTX) осуществляет обмен трафиком, микширование звука в конференциях, транскодингом – перепаковку трафика из одного кодека в другой (аудио или видео). Один средний сервер может обслуживать 200-500 одновременных звонков. Точное количество зависит от большого числа факторов: производительность процессора, участие сервера в других задачах кроме медиа-серверных, наличие в звонках транскодинга, наличие в звонках видео-трафика и транскодинга видео. Таким образом расширение на сайте количества серверов, выделенных под медиа-серверы, растет вместе с ростом требований к количеству одновременно обслуживаемых звонков. Они резервируются и масштабируются в режиме Active-Active.

RTX управляется по протоколу MEGACO. Оппозитной стороной, реализующей протокол MEGACO является роль MGC. Ее основные ответственности – выбор наиболее свободного подходящего медиа-сервера из своей группы и трансляция управления медиа-контекстами звонков: создание медиа-контекста, добавление в него медиа-терминейшенов, установка медиа-топологии, свойств терминейшенов, запуск воспроизведения и записи. На сайте может быть настроено несколько групп MGC, каждая из которых резервируется в режиме Active-Passive и управляет несколькими MG.

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

Следствие 4: Обмен трафиком звонка производится медиа-сервером того сайта, где расположен обслуживающий звонок экземпляр B2BUA.

Следствие 5: Как бы ни были разбросаны площадки – трафик всегда передается по кратчайшему маршруту через сайт, к которому подключено устройства инициатора звонка.

Следствие 6: Для того, чтобы звонки между двумя сайтами проходили, необходимо обеспечить прямую сетевую видимость между всеми экземплярами B2BUA, SG и MG этих сайтов.