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

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

Кейс: Пользователь А снимает трубку, набирает известный ему номер пользователя Б, вызов поступает на зарегистрированное устройство пользователя Б. Пользователь Б снимает трубку, устанавливается голосовое соединение.

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

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

  1. SG обрабатывая транзакцию INVITE выбирает случайным образом один из доступных B2BUA на сайте. В дальнейшем весь SIP-диалог инициирующего плеча этого звонка будет проходить именно через эти экземпляры SG и B2BUA. Этому служат специальные поля в запросах, относящихся к диалогу – Route и Record-Route.

  2. B2BUA с помощью DC осуществляет маршрутизацию звонка. Этот процесс происходит на текущем сайте, но возможно проксируется на сайты, обслуживающие затронутые домены. Маршрутизация – алгоритмически сложный процесс, поддерживающий среди прочего и передачу ответственности в другой домен. Результатом маршрутизации является список учетных записей, их доменов и правил их вызова, например время вызова и правила переадресации по неудачам. Процесс может протекать последовательно на нескольких сайтах – в силу маршрутизации в другой домен, либо в силу звонка с устройства, зарегистрированное в роуминге.

  3. В текущем кейсе B2BUA по итогу маршрутизации получает результат, указывающий на учетную запись пользователя Б. С помощью Registrar осуществляет поиск зарегистрированных устройств пользователя Б. Этот процесс происходит на текущем сайте, но возможно проксируется на другой сайт, если инициатор зарегистрирован в роуминге, либо пользователь Б находится в другом домене, не обслуживаемом на текущем сайте. Стоит отметить, что вызов зарегистрированных телефонов – далеко не единственный возможный результат этапа маршрутизации. Вызовы могут идти также во внешние сети и на коды абонентских функций.

  4. B2BUA формирует B2B-диалог, создает в нем второе плечо и начинает этап вызова, отправляя SIP-запрос INVITE на SG, через который было зарегистрировано устройство пользователя Б. Если вдруг оказывается, что пользователь Б имеет несколько зарегистрированных устройств, то B2BUA вызывает их все разом, возможно отправляя INVITE-запросы на разные SG, в том числе и находящиеся на других сайтах. Этот процесс носит название форкинг, каждое вызываемое устройство – форк, под каждый форк создается отдельный SIP-диалог, но максимум один завершится успешно.

  5. На одном из устройств пользователь Б снимает трубку, и его устройство отправляет ответ 200 OK, а остальным отказ от вызова SIP-запросом CANCEL. Далее по протоколу, согласно схеме:

seq_sg_b2bua_sg

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

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

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

comp_actor_sites_b2bua_sg

Аудио и видео данные, связанные со звонком, передаются по протоколу 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_mg

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

b2b_mgc_mg_process

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

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

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

Table 1. Используемые термины
Термин Определение

SIP-диалог

!

B2B-диалог

!

Маршрутизация

!

Коды абонентских функций

!

Перехват

!

Медиа-трафик

!

Медиа-сервер

!

MG

!

RTX

!

Транскодинг

!

MGC

!

Группа MGC

!

Медиа-контекст

!

Медиа-терминейшен

!

Медиа-топология

!