Архитектура и технологии NGN

Протокол сигнализации
SIP

Основы IP-телефонии
IP-сеть
(Интернет)
необходим механизм для того, чтобы сообщить о желании установить соединение
Протокол IP-телефонии

Основные принципы
Терминалы имеют IP-адреса, но более удобно использовать Е.164 номера, псевдонимы или текстовые адреса ⇒ необходимо преобразование IP-адресов в эти новые адреса
Терминалы имеют различные функциональные характеристики (кодек, скорость передачи, тип информации и т.д.) ⇒ необходим механизм оповещения удаленной стороны об этих характеристиках (Н.245, SDP)
Наличие некоторых отличий в типах сессий (передача текста, изображений, смена типа соединения во время сеанса и т.д.)

Установление соединения
Делится на две части (как правило,используются разные протоколы):
Уведомление о вызове, передача сигнала «контроль посылки вызова (КПВ), ответ, разъединение и т.д. (как в традиционной телефонии)
Соглашение о типе сессии и ее параметрах. (подобный механизм есть в ISDN)

Стандартизация SIP
Телефония
Международный союз электросвязи
ITU-T
(ех. CCITT)
H.323, E.164, Z.100
Интернет, VoIP
Группа разработчиков Интернет
(IETF – Internet Engineering Task Force)
RFC 3261 (RFC 2543) и прочие

Определение
«SIP является протоколом управления прикладного уровня для создания, изменения и завершения сеансов связи с одним или большим количеством участников. В понятие сеанса входят мультимедиа конференции, обучение на расстоянии, Internet-телефония и подобные приложения» (RFC 3261)
SIP – Session Initiation Protocol – Протокол инициализации сессии (сеанса связи), Протокол установления соединений

Принципы, заложенные в основу SIP при его разработке
Расширяемость протокола – возможность дополнения протокола новыми функциями
Масштабируемость сети – возможность увеличения элементов в сети при её расширении
Интеграция в стек существующих протоколов Интернет
Взаимодействие с другими протоколами сигнализации
Персональная мобильность - возможность быть доступными в любом месте с любым терминалам в любое время (сообщение REGISTER) → единый номер для всех услуг электросвязи

Адресация в SIP
тип адреса пример
«имя@домен» - sip:[e-mail]
«имя@хост» - sip:[e-mail]
«имя@IP-адрес» - sip:vova@192.168.100.1
«№ телефона@шлюз» - sip:[e-mail]
В Интернет – URL (Uniform Resource Location) (http://www.protei.ru/index.html)
В SIP – SIP URL (sip:name@host)

Особенности протокола SIP
Основан на НТТР → проверенная технология для работы в Интернет
Использует и UDP, и TCP
Работает поверх различных транспортных протоколов (IP, IPX, X.25, ATM)
Использует адресацию типа e-mail ([e-mail])
Текстовый формат сообщений → простота и удобство техобслуживания и программирования
Высокая информативность сообщений → минимальное время установления соединения

Архитектура «клиент-сервер»

Элементы сети SIP
Агент пользователя (UA – User Agent)
Клиент агента пользователя (UAC) Сервер агента пользователя (UAS)
Прокси-сервер (proxy server)
Сервер переадресации (redirect server)
Сервер определения местоположения (location server), не стандартизирован SIP RFC

Агент пользователя

Прокси-сервер
Прокси-сервер принимает запросы и «берет» их обслуживание на себя
Бывает двух типов:
Stateless – принимает запросы, перенаправляет их дальше и забывает
Stateful – принимает запросы, перенаправляет их и ждет ответы

Прокси-сервер
Прокси-сервер

Сервер переадресации
Сервер переадресации предназначен для определения текущего адреса пользователя
Не генерирует своих запросов

Сервер переадресации
Сервер
переадресации

Сообщения SIP
Сообщения SIP
Запросы
Ответы
INVITE
ACK
BYE
CANCEL
OPTION
REGISTER
UPDATE
INFO
PRACK
PUBLISH
SUBSCRIBE
NOTIFY
REFER
MESSAGE
(всего 14)
Временные
Финальные
1хх - информационный
2хх – успех
3хх – перенаправление
4хх – ошибка клиента
5хх – ошибка сервера
6хх – глобальный сбой

Структура сообщений

Запросы (1)

Запросы (2)

Пример сценария Subscribe/Notify
Запрос на подписку о передаче состояний
Подтверждение подписки
Информация о текущем состоянии
Информация о текущем состоянии

Ответы
Шесть групп ответов:
1хх – информационные
2хх – успех
3хх – перенаправление
4хх – ошибка клиента
5хх – ошибка сервера
6хх – глобальная ошибка

Ответы 1хх
100 Trying - Запрос обрабатывается, например, сервер обращается к базам данных, но местоположение вызываемого пользователя в настоящий момент не определено
180 Ringing - Местоположение вызываемого пользователя определено. Ему дается сигнал о входящем вызове

Ответы 2хх
200 ОК - Kоманда успешно выполнена

Ответы 3хх
300 Multiple Choices - Вызываемый пользователь доступен по нескольким адресам. Вызывающий пользователь может выбрать любой из них.
301 Moved Permanently - Пользователь изменил свое местоположение, его новый адрес указан в поле Contact
302 Moved Temporarily Пользователь временно изменил свое местоположение, его новый адрес указан в поле Contact

Ответы 4хх
400 Bad Request - В запросе обнаружена синтаксическая ошибка

Ответы 5хх
500 Internal Server Error - Внутренняя ошибка сервера

Ответы 6хх
600 Busy Everywhere Вызываемый пользователь занят и не желает принимать вызов в данный момент. Ответ может указывать подходящее для вызова время.

Заголовки
Заголовок Call-ID – уникальный идентификатор сеанса связи (call reference - DSS-1): [e-mail]
Заголовок То – определяет адресата. Если необходим визуальный вывод имени пользователя, например, на дисплей, то имя пользователя также размещается в поле То.
Заголовок From – идентифицирует отправителя запроса; по структуре аналогичен полю То.
Заголовок CSeq - уникальный идентификатор запроса, относящегося к одному соединению. Он служит для корреляции запроса с ответом на него. CSeq: 2 INVITE.

Заголовки
Заголовок Via указывается весь путь, пройденный запросом: каждый прокси-сервер добавляет поле со своим адресом.
Например, запрос на своем пути обрабатывался двумя прокси-серверами: сначала сервером loniis.ru, потом sip.telecom.com. Тогда в запросе появятся следующие поля:
Via: SIP/2.0/UDP sip.telecom.com:5060;branch=721e418c4.1
Via: SIP/2.0/UDP loniis.ru:5060
Заголовок Content-Type определяет формат описания сеанса связи. Само описание сеанса, например, в формате протокола SDP включается в тело сообщения.
Заголовок Content-Length указывает размер тела сообщения

Пример запроса и ответа
Запрос
INVITE sip: [e-mail] SIP/2.0
Via: SIP/2.0/UDP kton.bell-tel.com
From: A. Bell
To: T. Watson
Call-ID: [e-mail]
Cseq: 1 INVITE
Content-Type: application/sdp
Content-Length: ...
v=0
o=bell 53655765 2353687637 IN IP4 128.3.4.5
C=IN IP4 kton.bell-tel.com
m=audio 3456 RTP/AVP 0 3 4 5
Ответ
SIP/2.0 200 OK
Via: SIP/2.0/UDP kton.bell-tel.com
From: A. Bell
To:
;
Call-ID: [e-mail]
Cseq: 1 INVITE
Content-Type: application/sdp
Content-Length: ...
v=0
o=watson 4858949 4858949 IN IP4 192.1.2.3
c=IN IP4 boston.bell-tel.com
m=audio 5004 RTP/AVP 0 3

Сравнение с сообщением Н.323
{
q931pdu = {
protocolDiscriminator = 8
callReference = 4039
from = originator
messageType = Setup
IE: Bearer-Capability = {
88 80 a5 ...
}
IE: Display = {
76 6f 76 61 00 vova.
}
IE: Called-Party-Number = {
81 39 37 36 33 37 .97637
}
IE: User-User = {
20 b8 06 00 08 91 4a 00 02 01 40 03 00 76 00 6f .....J...@..v.o
00 76 00 61 22 c0 09 00 00 3d 16 45 71 75 69 76 .v.a"....=.Equiv
61 6c 65 6e 63 65 20 4f 70 65 6e 50 68 6f 6e 65 alence OpenPhone
00 00 06 31 2e 32 2e 30 00 00 00 01 02 00 ca 96 ...1.2.0........
a0 c0 a8 64 68 06 b8 00 40 7e f5 64 ad e9 18 10 ...dh...@~.d....
80 5f 00 20 18 3a bf c6 00 5d 1d 80 07 00 c0 a8 ._. .:...]......
64 b4 04 63 11 00 40 7e f5 64 ad e9 18 10 80 60 d..c..@~.d.....`
00 20 18 3a bf c6 79 04 1d 40 00 00 06 04 01 00 . .:..y..@......
4c 20 13 80 11 1c 00 01 00 c0 a8 64 b4 13 88 00 L .........d....
c0 a8 64 b4 13 89 13 00 00 64 0c 20 13 80 0b 0d ..d......d. ....
00 01 00 c0 a8 64 b4 13 89 80 22 40 00 00 06 04 .....d...."@....
01 00 48 71 03 51 00 80 01 00 80 11 1c 00 02 00 ..Hq.Q..........
c0 a8 64 b4 13 8a 00 c0 a8 64 b4 13 8b 22 40 00 ..d......d..."@.
00 06 04 01 00 48 6b 03 51 00 80 01 00 80 11 1c .....Hk.Q.......
00 02 00 c0 a8 64 b4 13 8a 00 c0 a8 64 b4 13 8b .....d......d...
01 00 01 00 01 00 01 00 02 80 01 80 ............

Сравнение с сообщением Н.323 (продолжение)
h225pdu = {
h323_uu_pdu = {
h323_message_body = setup {
protocolIdentifier = 0.0.8.2250.0.2
sourceAddress = 1 entries {
[0]=h323_ID 4 characters {
0076 006f 0076 0061 vova
}
}
sourceInfo = {
vendor = {
vendor = {
t35CountryCode = 9
t35Extension = 0
manufacturerCode = 61
}
productId = 23 octets {
45 71 75 69 76 61 6c 65 6e 63 65 20 4f 70 65 6e Equivalence Open
50 68 6f 6e 65 00 00 Phone
}
versionId = 7 octets {
31 2e 32 2e 30 00 00 1.2.0
}
}
terminal = {
}
mc = FALSE
undefinedNode = FALSE
}
destinationAddress = 1 entries {
[0]=dialedDigits "97637"
}
destCallSignalAddress = ipAddress {
ip = 4 octets {
c0 a8 64 68 dh
}

Протокол SDP
SDP (Session Description Protocol) - это протокол описания параметров сеанса для передачи потоковых данных.
Первое описание протокола было опубликовано Инженерной проблемной группой Интернета (IETF) как RFC 2327 в апреле 1998 года, а на сегодняшний день актуален RFC 4566.

Протокол SDP
Описание сеанса состоит из описаний уровня сеанса (детали, относящиеся к сеансу в целом и ко всем медиа-потокам) и нескольких необязательных описаний уровня медиа-носителя (детали, относящиеся к отдельному медиа-потоку).

Элементы протокола SDP
Описание сеанса связи:
v= (версия протокола)
o= (параметры вызывающего абонента и идентификатор сеанса связи)
s= (наименование сеанса связи)
i=* (информация о сеансе связи)
u=* (URI описания сеанса связи)
e=* (адрес электронной почты)
p=* (телефонный номер)
c=* (информация для соединения – не вставляется, если присутствует в медиа параметрах)
b=* (ноль или более информационных строк о полосе пропускания)
z=* (корректировка временной зоны)
k=* (ключ шифрования)
a=* (ноль или более атрибутов сеанса связи)

Элементы протокола SDP
Временные параметры:
t= (время активности сеанса связи)
r=* (количество повторений времени)
Описание медиа носителя
m= (наименование медиа-потока и адрес транспортировки)
i=* (медиа заголовок)
c=* (информация соединения)
b=* (ноль или более информационных строк о полосе пропускания)
k=* (ключ шифрования)
a=* (количество медиа атрибутов)

Пример SDP
v=0
o=jdoe 2890844526 2890842807 IN IP4 10.47.16.5
s=SDP Seminar
i=A Seminar on the session description protocol
u=http://www.example.com/seminars/sdp.pdf
e=[e-mail] (Jane Doe)
c=IN IP4 224.2.17.12/127
t=2873397496 2873404696
a=recvonly
m=audio 49170 RTP/AVP 0
m=video 51372 RTP/AVP 99
a=rtpmap:99 h263-1998/90000

Особенности SDP
■ Вызывающий абонент включает SDP-описание в запросы INVITE или ACK. Вызываемый абонент обязан включить SDP-описание в тело отклика «200 OK» или промежуточных откликов 180/183.
■ Модель взаимодействия налагает жёсткие ограничения на использование и изменение потоков. В частности, новые потоки могут порождаться в новых запросах, но потоки не могут удаляться.
■ Принимающая сторона, если она приняла описание потоков в виде SDP, должна использовать тот же состав потоков.

Процедура регистрации
Запрос REGISTER:

Запрос REGISTER (1)
REGISTER sip:registrar.protei.ru SIP/2.0
Via:SIP/2.0/UDP serv3.protei.ru:5060;branch=z9hG4bKnashds7
Max-Forwards:70
To:Bob
From:Bob
;tag=456248
Call-ID:843817637684230@998sdasdh09
CSeq:1826 REGISTER
Contact:
Expires:7200
Content-Length:0
Срок действия регистрации истекает через два часа.
Ответ 200 OK (2)
SIP/2.0 200 OK
Via:SIP/2.0/UDP serv3.protei.ru:5060;branch=z9hG4bKnashds7
;received=192.0.2.4
To: Bob
;tag=2493k59kd
From: Bob
;tag=456248
Call-ID: 843817637684230@998sdasdh09
CSeq: 1826 REGISTER
Contact:
Expires: 7200
Content-Length: 0
Процедура регистрации
Сервер регистрации
Protei.ru
Example

Алгоритм работы сервера перенаправления
Разговор

Алгоритм работы прокси-сервера
или Softswitch NGN
UA
UA
Softswitch
Сервер определения
местоположения
Разговор

Особенности реализации ДВО в SIP

Безусловная переадресация

Удержание вызова

Горячая линия

Применения SIP
Сотовые сети нового поколения 3G
SIP для установления мультимедийных сеансов связи
SIP for Telephony (SIP-T)

Особенности взаимодействия SIP с протоколами управления ТфОП

SIP-T (SIP for Telephony)
Требование к сети IP-телефонии это возможность так называемой прозрачности услуг относительно ТфОП.
Традиционные телефонные услуги, такие как call waiting, услуга 800 и т.д. должны иметь возможность реализации с помощью системы сигнализации №7.
SIP-T (SIP-I)
Инкапсуляция сообщений ОКС7/DSS-1 в сообщения SIP
Трансляция информации из сообщений ОКС7/DSS-1
Один протокол SIP

Отличия SIP-T от SIP-I
SIP-T was developed by the IETF
* - Кроме того у протоколов есть незначительные несоответствия в интерпретации различных параметров сообщений

Процедуры при взаимодействии ТфОП и сети VoIP

Инкапсуляция
IAM 2 = IAM 1

INVITE sip:[e-mail] SIP/2.0
Via: SIP/2.0/UDP anton.loniis.ru
From: sip:[e-mail]
To: sip:[e-mail]
Call-ID: [e-mail]
CSeq: 8348 INVITE
Contact:
Content-Length: 436
Content-Type: multipart/mixed; boundary=unique-boundary-1
MIME-Version: 1.0
--unique-boundary-1
Content-Type: application/SDP; charset=ISO-10646
v=0
o=jpeterson 2890844526 2890842807 IN IP4 126.16.64.4
s=SDP seminar
c=IN IP4 MG122.loniis.ru
t= 2873397496 2873404696
m=audio 9092 RTP/AVP 0 3 4
--unique-boundary-1
Content-Type: application/ISUP; version=nxv3;
base=etsi121
Content-Disposition: signal; handling=optional
01 00 49 00 00 03 02 00 07 04 10 00 33 63 21
43 00 00 03 06 0d 03 80 90 a2 07 03 10 03 63
53 00 10 0a 07 03 10 27 80 88 03 00 00 89 8b
0e 95 1e 1e 1e 06 26 05 0d f5 01 06 10 04 00
--unique-boundary-1
Пример сообщения INVITE (содержит информацию SDP и инкапсулированное сообщение IAM)

Трансляция
Трансляция включает в себя два компонента:
Преобразование сигнализации ISUP в SIP на уровне сообщений. В SIP – T предполагается использование MGC, которые создают сообщения ISUP из поступающих сообщений SIP и наоборот. Для этого необходимо точное определение правил преобразования между сообщениями ISUP и SIP, каждое сообщение ISUP должно быть транслировано в конкретное сообщение SIP. Например, IAM в INVITE, REL в BYE и т.д.
Преобразование параметров сообщения ISUP в заголовок SIP сообщения: Запрос SIP, который используется для установки соединения, должен содержать необходимую для маршрутизации прокси-серверами информацию, например это может быть телефонный номер, набранный вызывающим абонентом.

Поддержка передачи сигнальной информации во время сеанса
SIP INFO
RTP

Обеспечение безопасности
Аутентификация
Шифрование частей тела сообщения SIP

Взаимодействие 2-х сетей
инкапсуляции сообщений ISUP в тело запросов SIP
трансляция части информации сообщения ISUP, необходимой для правильной маршрутизации, в заголовок запроса SIP
позволяет элементам в сети SIP правильно маршрутизировать сообщение
Основа взаимодействия:

Взаимодействие с ТфОП
Разговор
ISUP
ISUP
SIP
RLC
RLC
REL

Взаимодействие с ТфОП. Неуспешное установление соединения

Преобразование сообщений
INVITE <-> IAM

Преобразование сообщений

Преобразование сообщений

Преобразование сообщений

Заключение
SIP – перспективный современный подход к построению сетей IP-телефонии
SIP – удобный и простой для реализации и техобслуживания
SIP легко интегрируем в существующий стек протоколов Интернет
SIP выбран в качестве протокола установления соединения в сотовых сетях поколения 3G

Литература