SIP - разветвление

Иногда прокси-сервер пересылает один вызов SIP нескольким конечным точкам SIP. Этот процесс известен как разветвление. Здесь один вызов может одновременно звонить нескольким конечным точкам.

Благодаря SIP-разветвлению ваш настольный телефон может звонить одновременно с программным телефоном или SIP-телефоном на мобильном телефоне, что позволяет легко принимать вызовы с любого устройства.

Как правило, в офисе, предположим, что начальник не может выбрать вызов или уйти, SIP-разветвление позволяет секретарю отвечать на вызовы на свой добавочный номер.

Разветвление будет возможно, если есть доступный прокси с отслеживанием состояния, поскольку он должен работать и отвечать из множества полученных.

У нас есть два типа разветвления -

  • Параллельное разветвление
  • Последовательное разветвление

Параллельное разветвление

В этом сценарии прокси-сервер будет разветвлять INVITE, скажем, двум устройствам (UA2, UA3) одновременно. Оба устройства сгенерируют 180 звонков, и тот, кто получит звонок, сгенерирует 200 OK. Ответ (предположим, что UA2), который первым достигает отправителя, устанавливает сеанс с UA2. Для другого ответа будет запущена ОТМЕНА.

Если отправитель получает оба ответа одновременно, то на основе q-значения он пересылает ответ.

Последовательное разветвление

В этом сценарии прокси-сервер отправит сообщение INVITE одному устройству (UA2). Если UA2 в это время недоступен или занят, прокси-сервер отправит его на другое устройство (UA3).

Филиал - ID и тег

Идентификаторы веток помогают прокси-серверам сопоставлять ответы на разветвленные запросы. Без идентификаторов филиалов прокси-сервер не сможет понять ответвленный ответ. Идентификатор ветки будет доступен в заголовке Via.

Теги используются UAC для различения нескольких окончательных ответов от разных UAS. UAS не может определить, был ли запрос разветвлен или нет. Следовательно, необходимо добавить тег.

Прокси-серверы также могут добавлять теги, если он генерирует окончательный ответ, они никогда не вставляют теги в запросы или ответы, которые они пересылают.

Возможно, что один запрос может быть разветвлен также несколькими прокси-серверами. Таким образом, прокси, который будет разветвляться, должен добавлять свои собственные уникальные идентификаторы в созданные ветки.

Участок вызова и идентификатор вызова

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

UAC начинается с отправки ПРИГЛАШЕНИЯ. Из-за разветвления он может получить несколько 200 OK от разных UA. Каждый соответствует отдельному участку вызова в рамках одного вызова.

Таким образом, вызов - это группа ветвей вызова. Участок вызова относится к сквозному соединению между UA.

Пространства CSeq в двух направлениях ветви вызова независимы. В одном направлении порядковый номер увеличивается для каждой транзакции.

Голосовая почта

Голосовая почта сейчас очень распространена среди корпоративных пользователей. Это телефонное приложение. Когда вызываемый абонент недоступен или не может принять вызов, УАТС сообщит вызывающему абоненту, чтобы он оставил голосовое сообщение.

Пользовательский агент либо получит ответ 3xx, либо перенаправит на сервер голосовой почты, если номер вызываемой стороны недоступен. Однако требуется какое-то расширение SIP, чтобы указать системе голосовой почты, какой почтовый ящик использовать, то есть какое приветствие следует воспроизвести и где сохранить записанное сообщение. Есть два способа добиться этого -

  • Используя расширение поля заголовка SIP

  • Используя Request-URI для передачи этой информации

Предположим для пользователя sip:[email protected] имеет систему голосовой почты по адресу sip: voicemail.tutorialspoint.com, которая предоставляет голосовую почту, Request-URI сообщения INVITE, когда оно пересылается на сервер голосовой почты, может выглядеть так:

sip:voicemail.tutorialspoint.com;target = sip:[email protected];cause = 486

На следующем рисунке показано, как Request-URI переносит идентификатор почтового ящика и причину (здесь 486).