Персональная мобильность — это способность иметь постоянный идентификатор на нескольких устройствах. SIP поддерживает базовую персональную мобильность с помощью метода REGISTER, который позволяет мобильному устройству изменять свой IP-адрес и точку подключения к Интернету и при этом иметь возможность принимать входящие вызовы.
SIP также может поддерживать мобильность услуг — способность пользователя сохранять те же услуги, когда они мобильны
Мобильность SIP во время передачи обслуживания (предварительный вызов)
Устройство связывает свой контактный URI с адресом записи с помощью простой регистрации sip. В зависимости от IP-адреса устройства, регистрация разрешает автоматическое обновление этой информации в сети sip.
Во время передачи обслуживания пользовательский агент выполняет маршрутизацию между различными операторами, где он должен снова зарегистрироваться в Contact в качестве AOR с другим поставщиком услуг.
Например, давайте возьмем пример следующего потока вызовов. UA, который временно получил новый SIP URI с новым поставщиком услуг. UA затем выполняет двойную регистрацию —
-
Первая регистрация выполняется с новым оператором службы, который связывает URI контакта устройства с URI AOR нового поставщика услуг.
-
Второй запрос REGISTER направляется обратно к исходному поставщику услуг и предоставляет AOR нового поставщика услуг в качестве URI контакта.
Первая регистрация выполняется с новым оператором службы, который связывает URI контакта устройства с URI AOR нового поставщика услуг.
Второй запрос REGISTER направляется обратно к исходному поставщику услуг и предоставляет AOR нового поставщика услуг в качестве URI контакта.
Как показано ниже в потоке вызовов, когда запрос поступает в исходную сеть поставщика услуг, сообщение INVITE перенаправляется новому поставщику услуг, который затем направляет вызов пользователю.
Для первой регистрации сообщение, содержащее URI устройства, будет:
REGISTER sip:visited.registrar1.com SIP/2.0 Via: SIP/2.0/UDP 172.22.1.102:5060;branch = z9hG4bK97a7ea349ce0fca Max-Forwards: 70 To: Tom <sip:[email protected]> From: Tom <sip:[email protected]>;tag = 72d65a24 Call-ID: [email protected] CSeq: 1 REGISTER Contact: <sip:[email protected]:5060> Expires: 600000 Content-Length: 0
Второе регистрационное сообщение с роуминговым URI будет:
REGISTER sip:home.registrar2.in SIP/2.0 Via: SIP/2.0/UDP 172.22.1.102:5060;branch = z9hG4bKah4vn2u Max-Forwards: 70 To: Tom <sip:[email protected]> From: Tom <sip:[email protected]>;tag = 45375 Call-ID:[email protected] CSeq: 6421 REGISTER Contact: <sip:[email protected]> Content-Length: 0
Первое сообщение INVITE, представленное на рисунке выше, будет отправлено на sip: registrar2.in; второе сообщение INVITE будет отправлено по адресу sip: sip: [email protected], которое будет перенаправлено на sip: [email protected] . Он достигает Тома и позволяет установить сессию. Периодически обе регистрации должны быть обновлены.
Мобильность во время разговора (повторное приглашение)
Пользовательский агент может изменить свой IP-адрес во время сеанса, когда он переключается из одной сети в другую. Базовый SIP поддерживает этот сценарий, так как повторное ПРИГЛАШЕНИЕ в диалоговом окне можно использовать для обновления URI контакта и изменения информации мультимедиа в SDP.
Посмотрите на поток вызовов, упомянутый на рисунке ниже.
-
Здесь Том обнаруживает новую сеть,
-
Использует DHCP для получения нового IP-адреса, и
-
Выполняет re-INVITE, чтобы разрешить передачу сигналов и медиа на новый IP-адрес.
Здесь Том обнаруживает новую сеть,
Использует DHCP для получения нового IP-адреса, и
Выполняет re-INVITE, чтобы разрешить передачу сигналов и медиа на новый IP-адрес.
Если агент UA может получать мультимедиа из обеих сетей, прерывание будет незначительным. Если это не так, несколько медиапакетов могут быть потеряны, что приведет к небольшому прерыванию вызова.
Повторное ПРИГЛАШЕНИЕ будет выглядеть следующим образом —
INVITE sip:[email protected] SIP/2.0 Via: SIP/2.0/UDP 172.22.1.102:5060;branch = z9hG4bK918f5a84fe6bf7a Max-Forwards: 70 To: <sip:[email protected]> From: sip:[email protected];tag = 70133df4 Call-ID: 76d4861c19c CSeq: 1 INVITE Accept: application/sdp Accept-Language: en Allow: INVITE,ACK,CANCEL,BYE,INFO,OPTIONS,REFER,NOTIFY,SUBSCRIBE Contact: <sip:172.22.1.102:5060>; Content-Type: application/sdp Content-Length: 168 v = 0 o = PPT 40467 40468 IN IP4 192.168.2.1 s = - c = IN IP4 192.168.2.1 b = AS:49 t = 0 0 b = RR:0 b = RS:0 a = rtpmap:97 AMR/8000/1 m = audio 6000 RTP/AVP 96 a = fmtp:102 0-15 a = ptime:20 a = maxptime:240
Re-INVITE содержит новый IP-адрес Bowditch в полях заголовка Via и Contact и медиа-информацию SDP.
Мобильность в Midcall (с заменой заголовка)
При мобильности в середине разговора фактический набор маршрутов (набор прокси-серверов SIP, которые должны пройти сообщения SIP) должен измениться. Мы не можем использовать re-INVITE в мобильности midcall
Например, если для прохождения NAT необходим прокси-сервер, необходимо изменить контактный URI — необходимо создать новый диалог. Следовательно, он должен отправить новое сообщение INVITE с заголовком Replaces, который идентифицирует существующий сеанс.
Примечание. Предположим, что A и B оба находятся в вызове, и если A получает другое сообщение INVITE (скажем, от C) с заголовком замены (должно соответствовать существующему диалогу), то A должно принять сообщение INVITE и завершить сеанс с помощью B и передать все ресурсы. на вновь сформированный диалог.
Поток вызовов показан на следующем рисунке. Он аналогичен предыдущему потоку вызовов с использованием re-INVITE, за исключением того, что автоматически генерируется BYE для завершения существующего диалога, когда принимается сообщение INVITE с заменами.
Ниже приведены моменты, которые следует отметить в этом сценарии.
-
Существующий диалог между Томом и Джерри включает старый посещенный прокси-сервер.
-
Новый диалог с использованием новой беспроводной сети требует включения нового посещаемого прокси-сервера.
-
В результате Том отправляет сообщение INVITE with Replaces, которое создает новое диалоговое окно, которое включает новый посещаемый прокси-сервер, но не старый посещенный прокси-сервер.
-
Когда Джерри принимает сообщение ПРИГЛАШЕНИЕ, автоматически отправляется BYE, чтобы завершить старый диалог, который проходит через старый посещенный прокси-сервер, который больше не участвует в сеансе.
-
Результирующий медиа-сеанс устанавливается с использованием нового IP-адреса Тома из SDP в INVITE.
Существующий диалог между Томом и Джерри включает старый посещенный прокси-сервер.
Новый диалог с использованием новой беспроводной сети требует включения нового посещаемого прокси-сервера.
В результате Том отправляет сообщение INVITE with Replaces, которое создает новое диалоговое окно, которое включает новый посещаемый прокси-сервер, но не старый посещенный прокси-сервер.
Когда Джерри принимает сообщение ПРИГЛАШЕНИЕ, автоматически отправляется BYE, чтобы завершить старый диалог, который проходит через старый посещенный прокси-сервер, который больше не участвует в сеансе.
Результирующий медиа-сеанс устанавливается с использованием нового IP-адреса Тома из SDP в INVITE.
Сервис Мобильность
Услуги в SIP могут быть предоставлены либо в прокси, либо в UA. Обеспечение мобильности услуг наряду с персональной мобильностью может быть сложной задачей, если устройства пользователя не имеют одинаковую конфигурацию с теми же службами.
SIP может легко поддерживать мобильность услуг через Интернет. При подключении к Интернету агент UA, настроенный на использование набора прокси-серверов в Индии, все еще может использовать эти прокси при роуминге в Европе. Это не оказывает никакого влияния на качество сеанса мультимедиа, так как мультимедиа всегда передается напрямую между двумя UA и не пересекает прокси-серверы SIP.
Резидентные услуги конечной точки доступны только тогда, когда конечная точка подключена к Интернету. Завершающая служба, такая как служба переадресации вызовов, реализованная в конечной точке, не будет работать, если конечная точка временно потеряла свое интернет-соединение. Следовательно, некоторые сервисы реализуются в сети с использованием прокси-серверов SIP.