Session Initiation Protocol (SIP) - один из наиболее важных и самых распространенных сигнальных протоколов. SIP поддерживает наибольшее количество вендоров. SIP продолжает распространяться и уже сейчас является идеальным протоколом для подключения различных систем VoIP.
Именно поэтому на обсуждение этого замечательного протокола мы выделим несколько статей

Хотя цикл статей SIP и Call Manager заостряет внимание по работе SIP и CUCM (CUCME), данный материал применим и к другим системам, использующим SIP.

SIP был разработан как альтернатива для H.323, в отличие от которого SIP стал намного проще. SIP базируется на интуитивно понятной логике World Wide Web, его очень просто внедрять. SIP гораздо проще дебагить, поскольку все его внутренние команды производятся прямым текстом.

SIP работает на базе так называемых session invitations которые базируются на модели session invitation/responce. Т.е. одна сторона производит запрос на использование определенной функции или метода, а другая сторона подтверждает либо отклоняет.

Как и H.323 SIP является протоколом типа peer-to-peer.
В этой структуре существует понятие User Agent или клиент(например телефон), который может инициировать сессию (звонок).
Для того чтобы UA могли находить друг друга, SIP позволяет создать инфраструктуру обслуживающих серверов - Proxy Servers.
UA осуществляет множеcтво действий через Proxy Server: registrations, invitations to sessions и т.д.

Компоненты архитектуры SIP

Как было отмечено ранее, клиенты или участники сессии называются User Agents (UA).
UA может выступать в виде двух ролей:
- User Agent Client (UAC): Клиентское приложение инициирующее запрос SIP.
- User Agent Server (UAS): Серверное приложение которое получает SIP invitation и возвращает отправителю response от имени пользователя.

Один и тот же UA может работать и как UAC, и как UAS, это зависит от того кто инициировал request.
UAC инициирует запрос, а UAS принимает этот запрос.

С точки зрения архитектуры компоненты сети SIP можно разделить на две категории:

• Clients (endpoints)
  - IP Phone - От сессии к сессии выступает как UAC или UAS.
  - Gateway - Может работать как UAC или UAS и обеспечивает множество сервисов. Чаще всего соединяя разные сети, например сеть SIP и сеть PSTN.
• Servers - Обслуживающие устройства видов Registrar, proxy, redirect, location

SIP Servers

Существует несколько видов SIP серверов:

• Registrar server: Используются для регистрации UAC. Регистрация UAC необходима для отслеживания его текущего местоположения. Registrar server часто располагается рядом с остальными серверами, например Location Server.
• Proxy server: Выполняет посредническую роль. Получает запросы SIP от UAC и затем проксирует эти запросы от имени клиента на следующий SIP server. Следующим сервером может быть другой Proxy server или UAS.
• Redirect server: Отдает клиенту информацию "о том куда ему идти" или next hop. В результате UAC пересылает invotation на сервер, указанный в redirection message. В отличие от Proxy server, который идет за клиента сам куда надо, Redirect server предлагает клиенту все сделать самому.
• Location server: Сервер обеспечивает resolve addresses, т.е. понять тем или иным способом где находится абонент с данным адресом. Для resolve addresse могут использоваться самые разные механизмы: Finger protocol, whois, Lightweight Directory Access Protocol (LDAP) и т.д. Registrar server может также участвовать в резолвинге.

Примеры SIP Architecture

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

На следующем рисунке изображены примеры подключений в архитектуре SIP.
\

SIP Call Flows: UAC-to-UAS

На рисунке схематично изображен звонок SIP непосредственно от клиента UAC на сервер UAS.
Это самый простой случай, когда SIP клиент и SIP сервер общаются без посредников. Такое возможно если архитектура сети это может позволить. В сложных сетях для связи клиента с сервером необходимо участие SIP сервера-посредника.

SIP Call Flows с использованием Proxy Server

Наличие в сети Proxy Server прозрачно для клиента. Благодаря Proxy Server становится возможным централизованный контроль и управление процессом Call Setup. UAC теперь не должен как-то узнавать координаты UAS. Еще раз обратим внимание: Proxy Server участвует лишь в сигнализациии для Call Setup. Сессия RTP устанавливается между UAC и UAS.

SIP Call Flows с использованием Redirect Server

Redirect Server знает путь до UAS, но вместо того чтобы пересылать INVITE по назначению, Redirect Server возвращает UAC координаты следующего UA к которому нужно обратиться. Redirect Server во многом похож на Proxy server. Redirect Server тесно связан с Location Server, от которого собственно он узнает пути.

Адресация SIP

SIP базируется на логике www . Адреса SIP используют Internet URLs вида name@domain.
SIP URL определяет следующие понятия: originator, current destination, final recipient, contact party.

Для определения IP адреса UAS, UAC выполняет процедуру address resolution.

Примеры адресов:
sip:vs@ciscomaster.ru - Fully qualified domain name (FQDN)
sip:14085551234@gateway.com;user=phone - E.164 (PSTN) address
sip:14085551234;password=changeme@10.1.1.1 - Mixed format

Address Registration

Для того чтобы принимать звонки endpoint должен зарегистрироваться на Registrar Server. После регистрации информация об UAC помещается в Location Database, которой может воспользоваться Proxy Server, если понадобится связаться с данным UAC.

Address Resolution

Если endpoint производит попытку подключения, она должна в конечном счете получить IP адрес destination endpoint, т.е. из адреса SIP получить IP адрес.
Чаще всего Address Resolution выполняет Proxy Server.
Proxy Server может использовать локальную таблицу хостов, DNS lookup, или обратиться к Location Server.

SIP и кодеки

Перед инициализации потока RTP обоим сторонам необходимо "договориться" о таких параметрах как
- Transport protocol (RTP, порты UDP)
- Type of media (аудио или видео)
- Format of media ( кодеки аудио и видео)

SIP использует Session Description Protocol (SDP) для негоциирования кодеков аудио и видео. Технически SIP использует модель Offer/Answer , т.е. инициирующая сторона предлагает Offer list of capabilities - список ее устраивающих кодеков в порядке убывания. Принимающая сторона выбирает устраивающий ее кодек и формирует ответ.

Существуют два метода обмена сообщениями SDP Offer/Answer: Early Offer и Delayed Offer.
При Early Offer session initiator (тот кто звонит) отсылает свой Offer во время первого же Invite.
Cisco gateways поддерживают оба метода, но по умолчанию стоит Early Offer.

При Delayed Offersession initiator шлет только Invite, но Offer отсылает called device (тот кто принимает звонок).
Delayed Offer рекомендуется для SIP trunks. В CUCM есть возможность выбрать тот или иной метод.

Мы рассмотрели основные вопросы теории SIP. В следующих частях мы обсудим прикладные вопросы, а именно настройку SIP на оборудовании Cisco: CUCM, CUCME а также IOS Gateway.