Шаг 15. Удержания и переводы звонков

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

Поскольку каждый B2B-диалог представлен двумя SIP-диалогами – плечо А и плечо Б, то важно обеспечить подстановку правильного плеча при подмене. Без этого устройство Варвары не сумеет обнаружить подменяемый диалог, и подмены не произойдет – вместо этого устройство либо откажет в вызове, либо произведет прием второго вызова. Проблема существует постольку, поскольку устройство Алисы знает о диалоге с Варварой только свое плечо А, а его идентификаторы отличаются от плеча Б, то есть от того, что знает об этом же диалоге устройство Варвары. Устройство Алисы отправляет запрос REFER с подменой, указывая в качестве подменяемого параметры своего плеча А диалога с Варварой, а устройству Варвары для успешной подмены требуются параметры плеча Б того же диалога.

Эту проблему роль B2B решает самостоятельно путем прямой коммуникации между её экземплярами (безотносительно сайтов, на которых они располагаются). Либо в момент трансляции запроса REFER+replaces, либо в момент обработки INVITE+Replaces, экземпляр роли B2B производит прямой запрос к смежному экземпляру роли B2B, где обслуживается целевой диалог, и с помощью него производит модификацию идентификаторов плеча.

Целевой B2B (в примерах B2B-2) обнаруживается непосредственно. Каждый экземпляр B2B проводя через себя вызов в каждое из плеч размещает "говорящие" идентификаторы. Для плеча А генерируется To-Tag, а для всех плеч Б генерируется From-Tag и Call-ID. В каждом из сгенерированных значений содержатся данные, по которым с помощью конфигурации можно установить адрес экземпляра B2B, произведшего генерацию. Таким образом, для замены идентификационных значений одного плеча на значения другого плеча достаточно иметь оба тега: From-Tag и To-Tag, по ним выяснить обслуживающий экземпляр B2B, и с помощью него произвести замену. Так функция и работает. В запросе REFER в атрибуте Replaces содержатся Call-ID, From-Tag, To-Tag. А в запросе INVITE в заголовках Replaces, Refer-To содержится те же идентификаторы плеча, и возможно признак уже совершенной замены.

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

Таким образом, одно устройство в рамках этого диалога отправляет оппоненту запрос REFER, а тот отправляет в обратную сторону запросы NOTIFY, транслируя все получаемые ответы. Только после получения NOTIFY с транслированным ответом 200 OK, устройство инициатора перевода прекращает переводимый диалог. Соответственно, получая NOTIFY с финальным неудачным ответом, устройство инициатора снова соединяется в переводившемся диалоге. Если речь идет об устройстве (телефоне), то всё время после отправки им запроса REFER он находится в пассивном режиме. Если трубка на телефоне лежит, то телефон начинает вызов своего пользователя и только после этого соединяется в переводившемся диалоге.

Роль B2B транслирует запросы REFER и NOTIFY и ответы на них.

Что происходит с медиа-серверами (роли MGC, MG, BGMG)? В соответствии с разобранным на шаге 11 каждый экземпляр роли B2B подключает к каждому обслуживаемому им диалогу медиа-сервер MG посредством медиа-контроллера MGC. Выбор MGC и MG происходит в пределах того же сайта, где и экземпляр B2B.

Схема показывает, что в любом B2B-диалоге вне зависимости от того, * какие типы абонентов в нем участвуют – внутренние пользователи, внешние абоненты или внутренние сервисы, * каким доменам принадлежат абоненты, * какая конфигурация сайтов настроена, * каким образом создан диалог – путем прямого вызова, перевода на номер или перевода с подменой, обслуживание диалога производится на SIP-сервере (роль B2B) и медиа-сервере (роль MG), находящимся на одном из сайтов, к которым подключены участники этого диалога.

Таким образом при условии неразличимости медиа-серверов внутри сайта, трафик всегда передается по кратчайшему возможному маршруту. SIP-сигнализация передается через 3 сервера, RTP-трафик – через 1 медиа-сервер при условии видимости сетей и через 2 или 3, если требуется трансляция медиа-трафика из одной подсети в другую на границе (шага 14). При наличии сайтов в Москве, Красноярске и Владивостоке, если абонент из Красноярска звонит в Москву – обслуживают серверы Красноярска, консультационный звонок из Москвы во Владивосток обслуживается серверами Москвы, переведенный звонок из Красноярска во Владивосток будет обслуживаться серверами Красноярска. А в случае обратного перевода абонента из Владивостока на абонента Красноярска – их диалог будет обслуживаться серверами Владивостока.