Sip realm что это
База знаний
Идентифиакция пользователей в SIP
Протокол SIP предоставляет статусонезависимый, основанной на технологии двухстороннего обмена, механизм для авторизации, который используется в протоколе HTTP. В любое время, когда прокси сервер или клиент (UA) принимает запрос (за исключением тех, что описаны в Разделе 22.1), он МОЖЕТ запросить у инициатора этого запроса гарантию подлинности его идентификации. Когда инициатор уже был идентифицирован, сторона, принимающая запрос, ДОЛЖНА убедиться может или нет, для этого авторизированного пользователя, быть выполнены действия указанные в запросе. В этом документе нет рекомендаций или обсуждений самих систем для авторизации.
Digest авторизация, описанная в этом разделе, предоставляет только механизм идентификации сообщений и защиту от повторного использования перехваченных данных авторизации, без модификации самого сообщения и не обеспечивая конфиденциальность данных сообщения. До и после идентификации, с помощью этого механизма Digest авторизации, должны быть предприняты дополнительные мероприятия по защите от действий по модификации содержания SIP запросов и ответов, которые могут предприняты атакующей стороной.
Обратите внимание, что из-за слабой защищенности, использование «Базовой» (Basic) схемы авторизации (где логин и пароль передаются по каналам связи незашифрованными) объявлено нежелательным. Все Сервера НЕ ДОЛЖНЫ подтверждать полномочия клиента, если используется «базовая» схема авторизации и НЕ ДОЛЖНЫ как-либо реагировать на запросы, которые используют эту схему авторизации. Эти изменения описаны в RFC 2543.
Что такое «realm»?
Какая авторизация должна использоваться: WWW или proxy-auth?
Если сервер, проверяющий авторизацию, не может принять авторизационные данные, переданные в запросе, то он ДОЛЖЕН ответить сообщением с кодом 401 (Unauthorized). Ответ ДОЛЖЕН включать в себя заголовочное поле: «WWW-Authenticate», содержащее, как минимум одну (и по возможности, заново сгенерированную) строку для проведения авторизации, пригодную к использованию запрашивающим клиентом. Если прокси сервер, проверяющий авторизацию, не может принять авторизационные данные, переданные в запросе, то он ДОЛЖЕН ответить сообщением с кодом 407 (Proxy Authentication Required). Ответ ДОЛЖЕН включать в себя заголовочное поле: «Proxy-Authenticate», содержащее, как минимум одну (и по возможности, заново сгенерированную) строку для проведения авторизации на прокси сервере, пригодную к использованию запрашивающим клиентом.
Авторизация для сообщений ACK и CANCEL
Digest авторизация в протоколе HTTP
Алгоритм работы HTTP Digest авторизации описан в документе: RFC2617 и расширен в документе RFC 3310.
Идентифиакция пользователей в SIP
Протокол SIP предоставляет статусонезависимый, основанной на технологии двухстороннего обмена, механизм для авторизации, который используется в протоколе HTTP. В любое время, когда прокси сервер или клиент (UA) принимает запрос (за исключением тех, что описаны в Разделе 22.1), он МОЖЕТ запросить у инициатора этого запроса гарантию подлинности его идентификации. Когда инициатор уже был идентифицирован, сторона, принимающая запрос, ДОЛЖНА убедиться может или нет, для этого авторизированного пользователя, быть выполнены действия указанные в запросе. В этом документе нет рекомендаций или обсуждений самих систем для авторизации.
Digest авторизация, описанная в этом разделе, предоставляет только механизм идентификации сообщений и защиту от повторного использования перехваченных данных авторизации, без модификации самого сообщения и не обеспечивая конфиденциальность данных сообщения. До и после идентификации, с помощью этого механизма Digest авторизации, должны быть предприняты дополнительные мероприятия по защите от действий по модификации содержания SIP запросов и ответов, которые могут предприняты атакующей стороной.
Обратите внимание, что из-за слабой защищенности, использование «Базовой» (Basic) схемы авторизации (где логин и пароль передаются по каналам связи незашифрованными) объявлено нежелательным. Все Сервера НЕ ДОЛЖНЫ подтверждать полномочия клиента, если используется «базовая» схема авторизации и НЕ ДОЛЖНЫ как-либо реагировать на запросы, которые используют эту схему авторизации. Эти изменения описаны в RFC 2543.
Что такое «realm»?
Какая авторизация должна использоваться: WWW или proxy-auth?
Если сервер, проверяющий авторизацию, не может принять авторизационные данные, переданные в запросе, то он ДОЛЖЕН ответить сообщением с кодом 401 (Unauthorized). Ответ ДОЛЖЕН включать в себя заголовочное поле: «WWW-Authenticate», содержащее, как минимум одну (и по возможности, заново сгенерированную) строку для проведения авторизации, пригодную к использованию запрашивающим клиентом. Если прокси сервер, проверяющий авторизацию, не может принять авторизационные данные, переданные в запросе, то он ДОЛЖЕН ответить сообщением с кодом 407 (Proxy Authentication Required). Ответ ДОЛЖЕН включать в себя заголовочное поле: «Proxy-Authenticate», содержащее, как минимум одну (и по возможности, заново сгенерированную) строку для проведения авторизации на прокси сервере, пригодную к использованию запрашивающим клиентом.
Авторизация для сообщений ACK и CANCEL
Digest авторизация в протоколе HTTP
Алгоритм работы HTTP Digest авторизации описан в документе: RFC2617 и расширен в документе RFC 3310.
ИТ База знаний
Полезно
— Онлайн генератор устойчивых паролей
— Онлайн калькулятор подсетей
— Руководство администратора FreePBX на русском языке
— Руководство администратора Cisco UCM/CME на русском языке
— Руководство администратора по Linux/Unix
Навигация
Серверные решения
Телефония
FreePBX и Asterisk
Настройка программных телефонов
Корпоративные сети
Протоколы и стандарты
Метод атаки на протокол SIP
Как взламывают самый популярный VoIP стандарт
Мы уже рассказывали об опасности атак на системы IP-телефонии, о том, как можно использовать скомпрометированную систему и кому это может быть выгодно.
Продвинутый курс по Asterisk
Концентрат редких знаний, для внедрения Asterisk в крупных предприятиях. Все это мы собрали в одном курсе для тебя.
В данной статье, подробно разберём один из способов атак на системы, работающие по протоколу SIP, через генерацию вредоносного пакета и последующую компрометацию учётной записи.
Внимание! Информация, представленная в данной статье, носит исключительно ознакомительный характер. Компания Мерион Нетворкс не несёт ответственности за последствия применения техник и способов, описанных в данном материале. Напоминаем, что неправомерный доступ к компьютерной информации преследуется по закону и влечет за собой уголовную ответственность.
Как показано на рисунке:
В стандартном процессе SIP аутентификации все запросы клиентов и ответы от сервера идут в строгой последовательности. Пользователь просто вводит учётные данные и клиент сам формирует пакеты для отправки на сервер, которые он может обработать. Если учётные данные не верны, то сервер не разрешит регистрацию и дальнейшее взаимодействие для осуществления звонков.
Давайте рассмотрим, что из себя представляет строка Authorization в повторном запросе REGISTER.
Как видно на рисунке, заголовок Authorization включает в себя следующие поля:
Поскольку SIP многое унаследовал от протокола HTTP, то и схема аутентификации в нём основана на HTTP аутентификации, которая также называется Дайджест (Digest) аутентификация. Эта схема применяется серверами для обработки учётных данных от клиентов. При этом, часть учётных данных передаётся в виде хэш-сумм, которые сервер комбинирует с открытыми данными и вычисляет пароль для данного клиента. Это значительно повышает уровень безопасности, но как мы убедимся в дальнейшем – не помогает при некорректной настройке учётной записи.
Согласно RFC 2069, который описывает HTTP дайджест аутентификацию, response вычисляется следующим образом:
Догадываетесь о чём идёт речь? О том, что если злоумышленник заполучит полную строку Authorization, то он может вычислить пароль клиента, зарегистрироваться на сервере и спокойно звонить куда ему вздумается.
Пространство для данной атаки достаточно обширное. Дело в том, что клиент может передавать строку авторизации в нескольких запросах – в уже известном нам REGISTER, INVITE или BYE.
Таким образом, атака может выглядеть следующим образом:
С точки зрения атакуемого, это будет выглядеть как простой звонок, на другой стороне трубки которого будет тишина. Он даже не будет подозревать о том, что его учётные данные вот-вот утекут к злоумышленнику. Атакующий в нужный момент разорвёт соединение, отправив BYE и затем сформированный вредоносный пакет.
Нагляднее всего приводить в пример прямое взаимодействие между клиентами. Такой сценарий становится, когда есть возможность отправлять SIP запросы напрямую до оконечного клиента. Например, когда телефон выставлен в открытую сеть по SIP порту. Помимо этого, уязвимости подвержены сервера, разрешающие прямое взаимодействия между оконечными клиентами. Лучше всего, пропускать все запросы через Proxy-сервер.
Итак, данной атаке могут быть подвержены:
Чтобы этого не случилось, даже если злоумышленник перехватит необходимую информацию, используйте стойкие пароли к учётным записям, да и вообще везде, где только можно. В этом Вам может помочь наш генератор паролей.
Продвинутый курс по Asterisk
Концентрат редких знаний, для внедрения Asterisk в крупных предприятиях. Все это мы собрали в одном курсе для тебя.
Обеспечиваем безопасность VoIP-сервиса и защиту от прослушивания
Корпоративная АТС на базе Asterisk предоставляет широкие возможности по обеспечению переговоров в IP-сетях, позволяет более эффективно управлять организацией и существенно экономить на звонках. Но из-за слабой защищенности или неправильной настройки VoIP-сервис может стать причиной серьезных финансовых потерь. В этой статье мы рассмотрим, как этого не допустить.
Проблемы защиты VoIP
Как и любое сетевое приложение, VoIP-сервис подвержен «классическим» атакам, но есть своя специфика. Например, в случае DDoS не обязательно «заваливать» сервер SYN-запросами. Можно «вмешаться» в разговор, отправляя пустые пакеты, на обработку которых сервис будет затрачивать ресурсы, это приведет к задержкам, и разговор вести станет невозможно (атака Call tampering).
Причем взлом VoIP является одним из самых удобных способов монетизации. Так, найдя ошибку в сервисе, злоумышленник может совершать звонки на платные сервисы, «продавать линию» или рассылать аудиоспам. В разное время уязвимости приходилось срочно закрывать безопасникам из Cisco, разработчикам Skype и Asterisk, и таких примеров очень много. Еще одна специфическая проблема — голосовой фишинг и спам (SPIT — spam over Internet telephony или VAM — voice/VoIP spam). В первом случае пользователь вместо того, чтобы работать, слушает рекламу, во втором — абонент получает предложение позвонить на «сервисный» номер (вроде PayPal) для уточнения некоторых вопросов. В итоге он оплачивает разговор по увеличенному тарифу или раскрывает персональные данные. Спит и фишинг еще не стали массовым явлением, но уже замечены, и объемы увеличиваются. Их реализация сама по себе не сложна, требуется всего лишь подготовленный файл и программа дозвона (Asterisk + Spitter).
Еще один частый способ атаки — подбор логинов и паролей, а также перехват данных VoIP. Чтобы реализовать MITM, не обязательно находиться в той же сети, достаточно изменить DNS-запись или перехватить сеанс (SIP registration hijacking). Так как SIP использует UDP, это упрощает атаку. Злоумышленник вклинивается в процесс подключения к серверу, отправляя ложные сведения о клиенте в пакете SIP REGISTER, и регистрируется от имени пользователя. В последующем он пропускает через себя весь трафик. Дальнейшая обработка также не вызывает проблем — снифер Cain & Abel умеет извлекать аудио и сохранять в формат WAV.
Защита VoIP
Увы, защита VoIP не включается одной кнопкой и должна планомерно строиться на всех уровнях, начиная с сетевого уровня (iptables, IPS) и заканчивая правильной настройкой плана набора.
Традиционные межсетевые экраны не могут полностью противостоять специфическим атакам, поскольку они работают на транспортном уровне и не умеют «смотреть» внутрь пакета. Здесь нужны специализированные решения, относящиеся к классу NGFW (Next-Generation Firewall). Сегодня они представлены такими вендорами, как Check Point, Certes Networks, SonicWall. Хотя, например, свободно распространяемые IPS Snort/Suricata уже имеют ряд правил, позволяющих распознать атаки на VoIP.
Могут быть эффективными традиционные мероприятия по борьбе с DoS — регулировка трафика на маршрутизаторе, использование пограничных контроллеров сессий (SBC, session border controllers), правильная настройка сервера и приложения. Так, контроллеры SBC, являясь единой точкой входа и анализируя пакеты в реальном времени, способны предотвращать DDoS-атаки, распространение спама и вирусные эпидемии. Плюс некоторые реализации SBC умеют шифровать трафик, обеспечивая защиту от перехвата в WAN. Под VoIP рекомендуется выделять отдельные сети (физические или VLAN), это позволит скрыть голосовой трафик от пользователей сети и лучше контролировать QoS для VoIP. Хотя не следует считать эту меру панацеей, так как сниферы без проблем найдут трафик VoIP VLAN.
Что касается атаки MITM, то защита от нее давно уже отлажена. Это проверка МАС-адреса на файрволе, использование протокола контроля доступа и аутентификации IEEE 802.1x, шифрование потока. Шифрование, наряду с продвинутыми методами аутентификации и правильной парольной политикой, позволяет защититься от подбора пароля.
В настоящее время реализовано несколько вариантов: VPN, TLS/SSL, SRTP (Secure Real Time Protocol) или ZRTP (Z and Real-time Transport Protocol). Виртуальные сети наиболее популярны у провайдеров услуг, но VPN, увеличивая накладные расходы на передачу пакетов, нередко сами становятся причиной задержек. Да и не с каждым протоколом VPN можно обеспечить соединение удаленному пользователю в конкретных условиях. Кроме того, обычно шифруется канал только между VPN-серверами, а внутри конкретного сегмента сети сотрудники ведут переговоры по незащищенному каналу.
Теперь рассмотрим реализацию этих методов на примере Asterisk.
Протокол SRTP/ZRTP
Оптимальным с точки зрения производительности является SRTP (RFC 3711), позволяющий шифровать (AES) медиапоток и обеспечивать проверку подлинности (HMAC-SHA-1) информации. Однако этот протокол не обеспечивает защиту процесса аутентификации, и необходимо дополнительно использовать сторонние инструменты вроде TLS/SSL. Связку SRTP + TLS/SSL можно легко организовать на Asterisk (с 1.8), FreeSWITCH, SIP-коммутаторе OpenSIPS и других подобных решениях. Кроме того, Asterisk и FreeSWITCH поддерживают протокол ZRTP, который специально разработан для VoIP Филиппом Циммерманном, создателем PGP (отсюда и первая буква Z в названии). Протокол обеспечивает безопасную аутентификацию и обмен данными, стандартизирован в RFC 6189. Во время инициализации ZRTP-звонка используется метод обмена ключами Диффи — Хеллмана, для аутентификации применяется SAS (Short Authentication String). Весь разговор шифруется, причем пара ключей генерируется для каждого сеанса автоматически, что очень удобно, так как позволяет легко встроить этот механизм в уже существующие продукты и не требуется инфраструктура PKI.
В дополнение к SRTP, в канальном драйвере chan_sip из состава Asterisk 11 реализована поддержка безопасного транспортного протокола DTLS-SRTP, предназначенного для передачи мультимедийных RTP-потоков c использованием шифрования, которая может быть задействована для абонентов, использующих WebRTC и SIP.
Конечно, с SRTP и ZRTP должны уметь работать и клиенты (софтофоны и аппаратные): Linphone (TLS, SRTP, ZRTP), Jitsi (TLS, SRTP, ZRTP), Blink (TLS, SRTP), MicroSIP (TLS, SRTP). Некоторая информация доступна на страничке. Сам Циммерманн предложил собственный софтофон Zfone, работающий по ZRTP (есть версии для Windows, Linux и OS X). В настоящее время Zfone находится в состоянии бета, но уже два года по техническим причинам его нельзя скачать с официального сайта.
Настройка SRTP + TLS/SSL в Asterisk
Сервер Asterisk поддерживает TLS между серверами и сценарий клиент — сервер. Для активации TLS достаточно прописать в настройках ( sip.conf ) всего несколько команд:
В настройках клиента ставим transport=tls.
Теперь подключение безопасно и подсмотреть регистрационные данные нельзя, хотя сами переговоры не шифруются. Штатный для Asterisk протокол IAX2, как и SIP, можно настроить на поддержку шифрования SRTP (AES128). Для этого необходимо добавить всего одну строку в конфиг iax.conf или sip.conf :
Команда iax show peers должна показать метку (E) напротив подключенных клиентов, означающую, что шифрование активно. В журналах появится запись вида encrypt_frame: Encoding.
Хакер #179. Интернет вещей — новый вектор атак
Защита от подбора пароля
Попытки подбора паролей к SIP-аккаунтам давно уже не редкость, тем более что готовые инструменты лежат в свободном доступе, а простой скрипт пишется за день. Например, комплект утилит SIPVicious позволяет получить списки SIP в указанном диапазоне IP, рабочие расширения (extensions) и подобрать к ним пароль.
Все это приводит к необходимости использовать только устойчивые к взлому пароли, обязательно отключать демоаккаунты и расширения. Имя пользователя, прописываемое в user, не должно быть простым (вроде 101, 102. ) и совпадать с названием расширения.
И конечно, надо использовать TLS/SSL, как показано выше, поскольку большинство скриптов просто не поддерживают такую возможность. Гостевые вызовы отключаются в sip.conf одной строкой:
Хотя надо иметь в виду, что некоторые SIP-устройства не смогут устанавливать соединения при такой настройке.
Отключение анонимного вызова в Elastix
Сервер, в случае ошибки запроса на соединение, отправляет одно из следующих сообщений:
Сканеры, определяющие расширения, анализируют эти ответы и таким образом выясняют, какие расширения доступны, впоследствии взломщик может попробовать подобрать к ним пароль, что, кстати, может заметно нагрузить сервер.
Но можно усложнить ему задачу, заставив сервер выдавать одну и ту же ошибку (401 Unauthorized) во всех случаях, для этого нужно внести запись:
По умолчанию сервер выдает полную информацию об используемой версии ПО, поэтому установим в sip.conf произвольные значения:
Сразу после установки в Asterisk доступно большое количество модулей (в Elastix, например, их 229), некоторые из них никогда не используются. Лишние следует убрать. Проверяем по команде module show и выгружаем — module unload chan_gtalk.so или, если постоянно, прописываем в modules.conf :
После установки Asterisk использует большое количество модулей
Следует ограничить возможность регистрации внутренних абонентов только с доверенных IP-адресов, задав для каждого экстеншна допустимый IP или диапазон, и задать МАС-адрес, если клиентское устройство стационарно.
Именованные ACL позволяют более тонко управлять доступом 
Настраиваем разрешенные IP-адреса
Желательно «заставить» сервер слушать только определенный интерфейс и изменить используемый порт по умолчанию, прописав в sip.conf следующие записи:
Для IAX настройки в iax.conf аналогичны (по умолчанию порт 4569). Изменение порта, конечно, при серьезном исследовании сети не спасет, но потребует дополнительной перестройки всех клиентов. Чтобы не возиться с этим, в некоторых ситуациях можно пробросить порт:
Хотя многие специализированные и самописные скрипты просто тестируют подключение на 5060 и, если он закрыт, игнорируют узел. А сканирование легко заблокировать при помощи IPS. И конечно же, файрволом следует прикрыть SIP-порты 5060/5061, чтобы они не светились наружу.
Что же делать сотрудникам, которые находятся вне LAN? Самые, наверное, простые и проверенные временем рекомендации: VPN или размещение VoIP-сервера с ограниченными возможностями в DMZ. Другой способ — организовать нечто вроде Captive-портала. Например, Travelin Man позволяет автоматически реконфигурировать Asterisk и iptables при подключении пользователя на специальную веб-страницу, после чего он может соединяться с SIP с указанными параметрами.
Еще один вариант — DISA (Direct Inward System Access), предоставляющий возможность через городской номер совершить дозвон до внутренних или внешних абонентов, хотя он подходит не для всех случаев.
Более экзотический способ — техника Port Knocking, позволяющая открыть нужный порт после выполнения определенной последовательности попыток подключения к закрытым портам. В Elastix, например, такая функциональность настраивается через веб-интерфейс.
Активация Port Knocking в Elastix
Настройки экстеншна
Междугородние звонки всем сотрудникам, как правило, не нужны, поэтому следует ограничить такую возможность только определенной группе абонентов. Входящие и исходящие звонки должны быть описаны в разных контекстах. Зачастую админы ленятся, используя в описании маршрутов символы замены, и получается что-то вроде:
Это может привести к тому, что сотрудник или злоумышленник может позвонить куда угодно. Поэтому следует жестко прописывать все цифры международных кодов, городов или мобильных операторов, четко указывая, куда можно звонить:
Вложенные контексты или специальные конструкции позволяют ограничить звонки в определенных направлениях в нерабочее время. Вариантов здесь несколько:
В случае нарушения можно предусмотреть отправку почтового сообщения на ящик админа:
Если сервис все-таки взломали, перед детальным разбором инцидента можно ограничить абонента количеством одновременных соединений, добавив в расширение параметр call-limit=1.
Используемую систему биллинга лучше сразу настроить на резкое возрастание количества междугородних звонков и установить лимит по расходам на абонента.
В поставке специальных дистрибутивов можно найти аддоны, позволяющие автоматически обнаруживать и блокировать попытки мошенничества, защищать от атак, определять аномалии в вызовах. Например, в Elastix доступны Humbug Analytics, Mango Analytics и Anti-Hacker.
Полезные скрипты для настройки Asterisk: bit.ly/HzOcQ8
Повышаем безопасность всеми доступными средствами
В Asterisk используется специальный SIP Security Event Framework, позволяющий в том числе собирать информацию о проблемах безопасности. Подключив соответствующий журнал в MARKDOWN_HASH225a5355dbea6e4872626e2101b5ea79MARKDOWN_HASH директивой security_log => security, мы можем блокировать все попытки перебора пароля при помощи fail2ban.
Заключение
Сервис VoIP — это сложное решение, и для его защиты следует применять комплексный подход, блокируя возможные угрозы на всех уровнях. Кроме прочего, следует побеспокоиться и о стандартных мероприятиях, таких как поддержание версии ПО и ОС сервера в актуальном состоянии, обновление прошивки и настройка безопасности оконечного оборудования.
Взаимодействие клиентов 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-сервере.