Что такое invite в sip телефонии
Взаимодействие клиентов SIP. Часть 1
Месяц назад я начал свое знакомство с IP-телефонией, а именно с Lync и Asterisk. И заметил следующую картину: в сети очень много интересных статей по практической стороне вопроса (как и что делать) и очень мало внимания уделено теории (в конце статьи приведены ссылки). Если Вы хотите разобраться с SIP, то извольте либо читать RFC 3261, либо одну из «этих толстых книг». Это, естественно, полезно, но многим хочется в начале изучить некую выжимку, а уж потом бросаться в омут с головой. Эта статья как раз для таких людей.
Чтобы не перегружать читателя, я решил разбить статью на две части. В первой части мы рассмотрим работы протокола SIP при взаимодействии двух клиентов.
Простое взаимодействие клиентов
Взаимодействие клиентов в рамках SIP чаще всего осуществляется в виде диалога.
Диалог – это равноправное взаимодействие двух User Agent (UA) в виде последовательности SIP-сообщений между ними. При этом, существуют запросы, не образующие диалогов. Однако обо всем по-порядку.
Ниже приведен пример простого взаимодействия между двумя устройствами с поддержкой SIP:
Петр хочет начать обмен сообщениями с Иваном, для этого он посылает INVITE-сообщение с данными о типе сессии (простая, мультимедиа и т.д.). Сообщения имеют следующий формат: стартовая строка, одно или несколько полей заголовка, пустая строка, обозначающая конец полей заголовка и необязательное тело сообщения.
Стартовая строка содержит метод, Request-URI и версию SIP (актуальная – 2.0). Request-URI – это SIP-адрес ресурса, которому посылается запрос.
Поля заголовков имеют следующий формат: :
Первая строка начинается с заголовка Via. Каждое SIP-устройство, создающее или пересылающее сообщение, добавляет свой адрес в поле Via (как это происходит, я планирую показать в следующей части статьи). Обычно адрес представляет собой имя хоста, которое может быть разрешено с помощью DNS-запроса. Поле Via содержит версию SIP, знак “/”, пробел, транспортный протокол (UDP, TCP, TLS, SCTP), двоеточие, номер порта и branch – идентификатор транзакции. Ответы на этот запрос будут содержать такой же номер транзакции.
Чаще всего, значение branch начинается с “z9hG4bK”. Это значит, что запрос был сгенерирован клиентом, поддерживающим RFC 3261 и параметр уникален для каждой транзакции этого клиента.
Следующее поле, Max-Forwards, содержит относительно большое целое число. Каждый сервер SIP, который пересылает сообщение, уменьшает это число на единицу. Данное поле обеспечивает простой механизм обнаружение петель (loop).
Следом идут поля From и To, которые описывают отправителя и получателя запроса. Важно, что SIP-запросы маршрутизируются исходя из Request-URI, указанного в стартовой строке (см. выше). Это объясняется тем, что поля From и To могут быть изменены при пересылке. Если используется отображаемое имя (например, Ivan Ivanov), то SIP URI помещается внутрь пары угловых скобок. Параметр tag в поле From генерирует отправляющая сторона. В свою очередь принимающая сторона поместит свой tag в поле To.
Поле Call-ID – идентификатор вызова. Совокупность tag’ов из полей From и To и Call-ID однозначно идентифицируют данный диалог. Это необходимо, так как между клиентами может идти сразу несколько диалогов.
Следующее поле, Cseq, содержит порядковый номер запроса и название метода. В данном случае – INVTITE. Номер увеличивается с каждым новым запросом.
Поля Via, Max-Forwards, To, From, Call-ID и CSeq составляют минимальный необходимый набор полей заголовков SIP-сообщения.
Для сообщения INVITE также необходимо поле заголовка Contact, в котором содержится SIP URI, относящийся к коммуникационному устройству отправляющей стороны. Это поле используется, чтобы из всех устройств, которыми одновременно может пользоваться Петр, ответ был отправлен именно на данное устройство. Обратите внимание на значения полей From и Contact. Первый раз я не заметил разницу:
В сообщении присутствует опциональное поле Subject, то есть тема сообщения. Некоторые SIP-клиенты могут выводить значение этого поля на экран. Для маршрутизации и идентификации диалога поле не используется и может быть произвольным.
Поля Content-Type и Content-Length отвечают за описание тела сообщения. В данном случае будет использоваться Session Description Protocol (SDP). Размер сообщения вычисляется с учетом символов перевода строки:
Детальное описание работы протокола SDP заслуживает отдельной статьи, поэтому ниже приведена только краткая расшифровка:
В ответ на INVITE SIP-клиент Ивана отправляет два сообщения: 180 Ringing и 200 OK. Первое сообщает, что на стороне Ивана SIP-клиент подает звуковой сигнал звонка, второе – подтверждает установку диалога. Разберемся с каждым из них.
Так будет выглядеть сообщение 180 Ringing:
Бледным выделен текст, который не изменился по сравнению с сообщением INVITE.
Обратите внимание на поля заголовков To и From. Несмотря на то, что данное сообщение идет со стороны Ивана, значения полей остаются такими же, как были в первоначальном запросе (от Петра к Ивану). Это объясняется тем, что данные поля определяют направление запроса, а не сообщения.
Строка Via также перекочевала из исходного запроса, в конце строки добавлен параметр received этот параметр содержит IP-адрес, с которого пришел запрос. Обычно это адрес, который может быть получен путем разрешения URI, содержащегося в Via.
Как я и обещал, в поле To добавился tag, идентифицирующий диалог. Все последующие сообщения в рамках диалога будут содержать неизменные значения tag.
Наконец, в поле Contact содержится актуальный адрес Ивана.
Так выглядит сообщение 200 ОК, которое отправил SIP-клиент Ивана:
Думаю, смысл всех полей, относящихся к протоколу SIP теперь ясен.
В ответ на 200 ОК клиент Петра отправляет подтверждение:
Данное сообщение подтверждает, что клиента Петра успешно получил ответ от клиента Ивана. Оба клиента договорились о параметрах меди-сессии, которая будет осуществляться по протоколу RTP.
Обратите внимание, что номер последовательности CSeq все еще равен единице, но в качестве метода уже стоит ACK. Параметр Branch в поле Via содержит новый идентификатор транзакции, так как ACK, отправляемый в ответ на 200 OK считает новой транзакцией.
Теперь давайте рассмотрим, как происходит завершение медиа-сессии. Клиент Петра посылает BYE-запрос для завершение сессии:
Получив запрос на завершение сессии, клиент Ивана посылает подтверждение:
Мы рассмотрели простой вариант работы протокола SIP. Обратите внимание, что в разные моменты времени клиенты Ивана и Петра выступали то в роли сервера, то в роли клиента, поэтому во всех SIP-клиентах должна функционировать как серверная (User Agent Server или UAS), так и клиентская часть (User Agent Client или UAC).
В следующей статье я планирую рассмотреть взаимодействие клиентов SIP с использованием Proxy-сервера и регистрацию клиентов на Proxy-сервере.
SIP-телефония
SIP (Session Initiat Protocol, протокол установки соединения) не является первопроходцем в области IP-телефонии. Протокол H.323 уже давно используется для целей IP-телефонии, однако изначально он не разрабатывался для IP-сетей, что снижает «оптимальность» их совместной работы. За годы работы с протоколом H.323 накоплен большой опыт использования, который позволил выявить как его положительные черты, так и недостатки, которые были учтены при разработке протокола SIP. <>pПротокол H.323 использует двоичный формат. Одним из следствий этого является необходимость стандартизации всех возможностей данного протокола, так как в случае если определенная возможность не поддерживается устройством, то такие устройства из-за двоичного формата не смогут работать друг с другом. SIP-протокол использует текстовый формат сообщений, если одному из устройств не знаком определенный тип сообщения или заголовка, то оно просто игнорируется (как и в HTTP, который по своему формату очень похож формат протокола SIP). К тому же сам протокол SIP значительно проще H.323.
Возможности протокола SIP
Основные преимущества протокола SIP:
Протокол SIP разрабатывался с расчетом на возможность использования любых транспортов, но, тем не менее, наиболее предпочтительным является использование UDP-пакетов (это позволяет повысить производительность по сравнению с использованием протокола TCP, но требует использования дополнительных механизмов проверки доставки сигнальных сообщений).
Собственно сама передача голоса осуществляется благодаря использованию протокола RTP (Real-time Transport Protocol, протокол транспортировки в реальном времени). Сам протокол SIP непосредственного участия в передаче голосовых, видео и других данных не принимает, он отвечает только за установление связи (по протоколам SDP, RTP и др.), поэтому под SIP-телефонией понимается не передача голоса по протоколу SIP, а передача голоса с использованием протокола SIP. Использование протокола SIP предоставляет новые возможности установления соединений (а также возможность беспроблемного расширения данных возможностей), а не непосредственной передачи голосового и других видов трафика.
Формат адресов используемых протоколом SIP напоминает формат E-Mail-адреса: имя@идентификатор_хоста. В начале адреса ствится приставка «SIP:» (пример: SIP: user@host.com Этот e-mail адрес защищен от спам-ботов, для его просмотра у Вас должен быть включен Javascript ). В качестве идентификатора хоста может служить его IP-адрес, домен или имя хоста (IP-адрес определяется с использованием DNS, так что в итоге все равно получается обращение по адресу SIP: имя@IP-адрес).
Стандартными элементами в SIP-сети являются:
Сообщения SIP-протокола имеют следующую структуру:
В заголовках содержатся сведения об источнике, адресате, пути следования сообщения и др. Этих заголовков может быть достаточно много и это количество может меняться на пути следования пакетов. В протоколе SIP версии 2.0 существует 6 типов запросов (тип запроса задается в стартовой строке):
Информационные ответы сообщают о стадии выполнения запроса, они не являются завершением запроса. Остальные же классы ответов завершают выполнение запроса.
Пользователь Alice (SIP: alice@atlanta.com Этот e-mail адрес защищен от спам-ботов, для его просмотра у Вас должен быть включен Javascript ) вызывает пользователя Bob (SIP: bob@biloxi.com Этот e-mail адрес защищен от спам-ботов, для его просмотра у Вас должен быть включен Javascript ).
Пока сообщения установления соединения (INVITE) ходят между прокси-серверами и неизвестно доступен ли вызываемый пользователь, в ответ на INVITE посылается ответ 100 (Trying), сообщающий о попытке установления соединения.
Так как прокси-сервер может устанавливать собственные соединения, его использование позволяет вызовам без проблем преодолевать NAT. Также возможно построение нескольких прокси-серверов в одну цепочку, что позволяет преодолевать сразу несколько NAT.
Для передачи звука и видео используются различные алгоритмы сжатия и кодирования данных. Эти алгоритмы называются кодеками. Различные кодеки используют различную ширину полосы пропускания, а также вносят различные задержки и обеспечивают различное качество сервиса. Для звуковых кодеков бычно ширина полосы пропускания составляет от 4-х до 64 кбит/с
Основное направления тестирования SIP-телефонии заключается в рассмотрении качества передачи голоса при ограничении ширины полосы пропускания. Также будет рассматриваться качество передачи голоса при динамическом изменении числа сеансов IP-телефонии и изменении загруженности канала связи. При тестировании IP-маршрутизаторов будет также рассматриваться поведение потоков трафика при установлении сеансов IP-телефонии. Более четкая методика будет разрабатываться по мере нарастания основательной базы результатов тестирования SIP-оборудования различных производителей.
По прогнозам производителей оборудования IP-телефонии, популярность SIP-телефонии будет расти и темпы этого роста будут превосходить темпы роста IP-телефонии в целом, поэтому сами производители возлагают на SIP большие надежды. По тем же прогнозам резкое возрастание интереса к SIP-протоколу (и соответственно оборудованию использующему SIP-протокол) со стороны конечных пользователей придется как раз на 2006 год. По этой причине за выпуск оборудования использующего протокол SIP вплотную взялись многие компании, работающие в области коммуникаций
SIP-телефония
Вместо вступления…
В последнее время наблюдается повышенный интерес к технологиям IP-телефонии, использование которой позволяет в значительной мере снизить стоимость телефонной связи. При этом становится возможным использование сети Интернет, что позволяет сразу достичь «глобальных масштабов», а необходимость прокладки магистральных коммуникаций попросту отпадает.
Целью данной статьи является поверхностное рассмотрение возможностей IP-телефонии, использующей протокол SIP, для ознакомления с общими принципами ее работы.
Протокол SIP (Session Initiat Protocol, протокол установки соединения) не является первопроходцем в области IP-телефонии. Протокол H.323 уже давно используется для целей IP-телефонии, однако изначально он не разрабатывался для IP-сетей, что снижает «оптимальность» их совместной работы. За годы работы с протоколом H.323 накоплен большой опыт использования, который позволил выявить как его положительные черты, так и недостатки, которые были учтены при разработке протокола SIP.
Протокол H.323 использует двоичный формат. Одним из следствий этого является необходимость стандартизации всех возможностей данного протокола, так как в случае если определенная возможность не поддерживается устройством, то такие устройства из-за двоичного формата не смогут работать друг с другом. SIP-протокол использует текстовый формат сообщений, если одному из устройств не знаком определенный тип сообщения или заголовка, то оно просто игнорируется (как и в HTTP, который по своему формату очень похож формат протокола SIP). К тому же сам протокол SIP значительно проще H.323.
Возможности протокола SIP
Основные преимущества протокола SIP:
1. Масштабируемость — возможность увеличения количества клиентов при расширении сети.
2. Мобильность — возможность получения сервиса вне зависимости от местоположения (как например электронная почта), а каждому пользователю выдается персональный идентификатор, по которому он может быть найден.
3. Расширяемость — возможность дополнения протокола новыми функциями (за счет введения новых заголовков и сообщений). Как уже говорилось выше, если устройству встречается неизвестное ему расширение протокола, оно попросту игнорируется. Так как протокол H.323 использует сообщения двоичного формата, то неизвестные функции могут привести к невозможности предоставления сервиса.
Протокол SIP разрабатывался с расчетом на возможность использования любых транспортов, но, тем не менее, наиболее предпочтительным является использование UDP-пакетов (это позволяет повысить производительность по сравнению с использованием протокола TCP, но требует использования дополнительных механизмов проверки доставки сигнальных сообщений).
Так как телефония с использованием протокола SIP позволяет использовать большое количество разнообразных сервисов (помимо передачи голоса, возможна передача видео, текстовых сообщений, факсов и др.), необходим механизм обмена информацией о том, какие сервисы может использовать вызываемаявызывающая стороны. Для этой цели используется протокол SDP (Session Description Protocol) — протокол описания сессии. Данный протокол позволяет определить какие звуковые (видео и другие) кодеки и иные возможности может использовать удаленная сторона.
Собственно сама передача голоса осуществляется благодаря использованию протокола RTP (Real-time Transport Protocol, протокол транспортировки в реальном времени). Сам протокол SIP непосредственного участия в передаче голосовых, видео и других данных не принимает, он отвечает только за установление связи (по протоколам SDP, RTP и др.), поэтому под SIP-телефонией понимается не передача голоса по протоколу SIP, а передача голоса с использованием протокола SIP. Использование протокола SIP предоставляет новые возможности установления соединений (а также возможность беспроблемного расширения данных возможностей), а не непосредственной передачи голосового и других видов трафика.
Формат адресов используемых протоколом SIP напоминает формат E-Mail-адреса: имя@идентификатор_хоста. В начале адреса ствится приставка «sip:» (пример: sip:user@host.com). В качестве идентификатора хоста может служить его IP-адрес, домен или имя хоста (IP-адрес определяется с использованием DNS, так что в итоге все равно получается обращение по адресу sip: имя@IP-адрес).
Архитектура SIP-сети
Стандартными элементами в SIP-сети являются:
1. User Agent: по протоколу SIP устанавливаются соединения «клиент-сервер». Клиент устанавливает соединения, а сервер принимает вызовы, но так обычно телефонный аппарат (или программный телефон) может как устанавливать так и принимать звонки, то получается что он одновременно играет роль и клиента и сервера (хотя в реализации протокола это не является обязательным критерием) — в этом случае его называют User Agent (UA) или терминал.
2. Прокси-сервер: прокси сервер принимает запросы и производит с ним некоторые действия (например определяет местоположение клиента, производит переадресацию или перенаправление вызова и др.). Он также может устанавливать собственные соединения. Зачастую прокси-сервер совмещают с сервером определения местоположения (Register-сервер), в таком случае его называют Registrar-сервером.
3. Сервер опредления местоположения или сервер регистрации (Register): данный вид сервера служит для регистрации пользователей. Регистрация пользователя производится для определения его текущего IP-адреса, для того чтобы можно было произвести вызов user@IP-адрес. В случае если пользователь переместится в другое место и/или не имеет определенного IP-адреса, его текущий адрес можно будет определить после того, как он зарегистрируется на сервере регистрации. Таким образом клиент останется доступен по одному и тому же SIP-адресу вне зависимости от того, где на самом деле находится.
4. Сервер переадресации: обращается к серверу регистрации для определения текущего IP-адреса пользователя, но в отличие от прокси сервера только «переадресует» клиента, а не устанавливает собственные соединения.
Прокси-серверы в SIP-сети также могут вносить изменения в передаваемые сообщения — это позволяет беспрепятственно преодолевать NAT в случае если прокси-сервер стоит на NAT-маршрутизаторе (также возможна настройка прокси сервера, находящегося за NAT в случае если на последнем невозможно установить прокси сервер — для этого потребуется задать параметры переадресации так, чтобы получился прокси-сервер стал «виртуальным сервером»). Помимо этого прокси-серверы можно объединять в «цепочки», которые позволяют использовать телефонию, даже если конечная точка (UA) находится сразу за несколькими NAT-шлюзами.
Сообщения SIP
Стартовая строка различается в зависимости от того является ли сообщение запросом или ответом (в случае запроса — в ней сообщается тип запроса, адресат и номер версии протокола, а в случае ответа — номер версии протокола, статус и текстовую расшифровку статуса).
В заголовках содержатся сведения об источнике, адресате, пути следования сообщения и др. Этих заголовков может быть достаточно много и это количество может меняться на пути следования пакетов.
Информационные ответы сообщают о стадии выполнения запроса, они не являются завершением запроса. Остальные же классы ответов завершают выполнение запроса.
Пример
Рассмотрим пример процесса установления соединения с использованием SIP-протокола (пример взят из RFC 3261). Данный пример отражает работу базовых функций телефонии и соответственно не затрагивает такие возможности как видеосвязь передача текстовых сообщений и др. — общий принцип работы протокола остается неизменным.
Пользователь Alice (sip:alice@atlanta.com) вызывает пользователя Bob (sip:bob@biloxi.com).
1. Пользователь Alice посылает сообщение INVITE прокси-серверу по умолчанию (atlanta.com) Если бы пользователю Alice был известен IP-адрес пользователя Bob и он мог к нему обратиться напрямую, то запрос INVITE в этом случае мог быть послан непосредственно вызываемому пользователю.
2. Прокси-сервер посылает запрос INVITE серверу вызываемого абонента (biloxi.com).
3. Далее прокси-сервер пользователя Bob при необходимости определяет его текущий IP-адрес и посылает ему сообщение INVITE — у пользователя начинает звонить телефон, о чем сообщается в ответе 180 (Ringing).
4. Если вызываемый пользователь ответил на звонок, то на запрос INVITE высылается ответ 200 (OK).
5. Вызывающий пользователь отправляет сообщение ACK, сообщающее вызываемому о том, что он получил ответ на свой запрос INVITE, им задаются окончательные параметры соединения. На этом этапе все готово к установлению соединения по протоколу RTP (Real-time Transport Protocol).
6. Устанавливается RTP-соединение с заранее согласованными параметрами.
7. Для завершения соединения, завершающим пользователем (кладет трубку) высылается запрос BYE, на которое высылается ответ 200 (OK)
Пока сообщения установления соединения (INVITE) ходят между прокси-серверами и неизвестно доступен ли вызываемый пользователь, в ответ на INVITE посылается ответ 100 (Trying), сообщающий о попытке установления соединения.
Так как прокси-сервер может устанавливать собственные соединения, его использование позволяет вызовам без проблем преодолевать NAT. Также возможно построение нескольких прокси-серверов в одну цепочку, что позволяет преодолевать сразу несколько NAT.
Кодеки
Для передачи звука и видео используются различные алгоритмы сжатия и кодирования данных. Эти алгоритмы называются кодеками. Различные кодеки используют различную ширину полосы пропускания, а также вносят различные задержки и обеспечивают различное качество сервиса. Для звуковых кодеков обычно ширина полосы пропускания составляет от 4-х до 64 кбит/с.
Методика тестирования
Основное направления тестирования SIP-телефонии заключается в рассмотрении качества передачи голоса при ограничении ширины полосы пропускания. Также будет рассматриваться качество передачи голоса при динамическом изменении числа сеансов IP-телефонии и изменении загруженности канала связи. При тестировании IP-маршрутизаторов будет также рассматриваться поведение потоков трафика при установлении сеансов IP-телефонии.
Более четкая методика будет разрабатываться по мере нарастания основательной базы результатов тестирования SIP-оборудования различных производителей.
Заключение
По прогнозам производителей оборудования IP-телефонии, популярность SIP-телефонии будет расти и темпы этого роста будут превосходить темпы роста IP-телефонии в целом, поэтому сами производители возлагают на SIP большие надежды. По тем же прогнозам резкое возрастание интереса к SIP-протоколу (и соответственно оборудованию использующему SIP-протокол) со стороны конечных пользователей придется как раз на 2006 год. По этой причине за выпуск оборудования использующего протокол SIP вплотную взялись многие компании, работающие в области коммуникаций.