Учебники

SIP – Мобильность

Персональная мобильность – это способность иметь постоянный идентификатор на нескольких устройствах. 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 перенаправляется новому поставщику услуг, который затем направляет вызов пользователю.

SIP Mobility

Для первой регистрации сообщение, содержащее 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:UA1@registrar1.in> 
From: Tom <sip:UA1@registrar1.in>;tag = 72d65a24 
Call-ID: 4e719d1c1fc9000803630373300@172.22.1.102 
CSeq: 1 REGISTER 
Contact: <sip:Tom@172.22.1.102: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:UA1@registrar2.in> 
From: Tom <sip:UA1@registrar2.in>;tag = 45375 
Call-ID:87nr43i@172.22.1.102 
CSeq: 6421 REGISTER 
Contact: <sip:UA1@registrar2.in> 
Content-Length: 0

Первое сообщение INVITE, представленное на рисунке выше, будет отправлено на sip: registrar2.in; второе сообщение INVITE будет отправлено по адресу sip: sip: Tom@registrar2.in, которое будет перенаправлено на sip: Tom@172.22.1.102 . Он достигает Тома и позволяет установить сессию. Периодически обе регистрации должны быть обновлены.

Мобильность во время разговора (повторное приглашение)

Пользовательский агент может изменить свой IP-адрес во время сеанса, когда он переключается из одной сети в другую. Базовый SIP поддерживает этот сценарий, так как повторное ПРИГЛАШЕНИЕ в диалоговом окне можно использовать для обновления URI контакта и изменения информации мультимедиа в SDP.

Посмотрите на поток вызовов, упомянутый на рисунке ниже.

  • Здесь Том обнаруживает новую сеть,

  • Использует DHCP для получения нового IP-адреса, и

  • Выполняет re-INVITE, чтобы разрешить передачу сигналов и медиа на новый IP-адрес.

Здесь Том обнаруживает новую сеть,

Использует DHCP для получения нового IP-адреса, и

Выполняет re-INVITE, чтобы разрешить передачу сигналов и медиа на новый IP-адрес.

Если агент UA может получать мультимедиа из обеих сетей, прерывание будет незначительным. Если это не так, несколько медиапакетов могут быть потеряны, что приведет к небольшому прерыванию вызова.

Мобильность во время звонка

Повторное ПРИГЛАШЕНИЕ будет выглядеть следующим образом –

INVITE sip:Jerry@TTP.com SIP/2.0  
Via: SIP/2.0/UDP 172.22.1.102:5060;branch = z9hG4bK918f5a84fe6bf7a 
Max-Forwards: 70 

To: <sip:Harry@TTP.com> 

From: sip:Tom@PPT.com;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 с заменами.

Мобильность в Midcall

Ниже приведены моменты, которые следует отметить в этом сценарии.

  • Существующий диалог между Томом и Джерри включает старый посещенный прокси-сервер.

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

  • В результате Том отправляет сообщение INVITE with Replaces, которое создает новое диалоговое окно, которое включает новый посещаемый прокси-сервер, но не старый посещенный прокси-сервер.

  • Когда Джерри принимает сообщение ПРИГЛАШЕНИЕ, автоматически отправляется BYE, чтобы завершить старый диалог, который проходит через старый посещенный прокси-сервер, который больше не участвует в сеансе.

  • Результирующий медиа-сеанс устанавливается с использованием нового IP-адреса Тома из SDP в INVITE.

Существующий диалог между Томом и Джерри включает старый посещенный прокси-сервер.

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

В результате Том отправляет сообщение INVITE with Replaces, которое создает новое диалоговое окно, которое включает новый посещаемый прокси-сервер, но не старый посещенный прокси-сервер.

Когда Джерри принимает сообщение ПРИГЛАШЕНИЕ, автоматически отправляется BYE, чтобы завершить старый диалог, который проходит через старый посещенный прокси-сервер, который больше не участвует в сеансе.

Результирующий медиа-сеанс устанавливается с использованием нового IP-адреса Тома из SDP в INVITE.

Сервис Мобильность

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

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

Резидентные услуги конечной точки доступны только тогда, когда конечная точка подключена к Интернету. Завершающая служба, такая как служба переадресации вызовов, реализованная в конечной точке, не будет работать, если конечная точка временно потеряла свое интернет-соединение. Следовательно, некоторые сервисы реализуются в сети с использованием прокси-серверов SIP.