В предыдущей статье мы рассмотрели простое взаимодействие клиентов SIP без использования Proxy-сервера. Такое взаимодействие на практике встречается чрезвычайно редко, но отлично подходит для того, чтобы понять основы SIP.
Теперь, когда мы разобрались с базовыми вещами, предлагаю перейти к реальной работе протокола.
В этой статье я планирую рассмотреть три вопроса:
Поскольку протокол SIP поддерживает несколько транспортных протоколов (UDP, TCP, SCTP, TLS), необходимо каким-то образом определять, какой протокол использовать. Для этого существет несколько способов.
Первый способ предполагает явное указание транспорта в SIP URI (кроме TLS). Выглядит это вот так:
Если транспорт явно не указан, то действует следующий алгоритм:
Для того, чтобы лучше разобраться, рассмотрим пример, когда мы хотим связаться с клиентом sip:ivan@domain.ru:
Итак, мы выяснили, параметры Proxy-сервера Ивана. Теперь предлагаю рассмотреть использование Proxy в рамках SIP-диалога.
Ремарка для тех, кто не знает, что такое NAPTR. Я узнал, что есть такой тип DNS-записи только, когда писал эту статью, так что не отчаивайтесь. Чуть подробнее про NAPTR здесь.
Для чего же нам необходим SIP Proxy? Как я уже сказал, в примере из 1-ой части статьи клиенты знали IP-адреса друг друга и могли общаться напрямую. В реальной жизни клиенты чаще всего получают адреса динамически, поэтому нет смысла «запоминать» тот или иной IP. Первое, что приходит на ум в данной ситуации – использовать A-записи DNS и определить реальный действующий адрес. Однако тут кроется следующая проблема: IP-адрес идентифицирует конкретное устройство, а не пользователя на нем. Особенностью взаимодействия SIP является то, что обмен сообщения происходит не на уровне устройство-устройство, а на пользователь-пользователь. При этом один пользователь может одновременно использовать несколько SIP-клиентов: на мобильном телефоне, на рабочем компьютере, на домашнем компьютере и на SIP-телефоне. Как же быть?
Протокол SIP предлагает следующее решение: создается SIP Proxy и каждый пользователь регистрирует свои устройства на этом Proxy (точнее пользователи регистрируются на сервере регистрации, а Proxy имеет доступ к базе регистрации, но для простоты будем считать, что это один и тот же сервер). Как это делается, я покажу ниже. Пока просто запомните, что Proxy знает, как именно найти тот или иной клиент пользователя.
Когда Петр звонит Ивану, выполняется следующая последовательность действий:
На схеме это выглядит следующим образом:
Для тех, кто изучил первую часть статьи, все выглядит довольно знакомо; добавился только промежуточный Proxy-сервер. Соответственно и обмен сообщениями изменился незначительно.
Прежде, чем преступим к детальному рассмотрению, маленькая ремарка. В рамках SIP разделяют два типа URI. Первый из них – ползовательский URI, также известный как address of recorf (AOR). Запрос, отправленный на этот адрес предполагает поиск в базе данных Proxy и отправку запроса одному или несольким устройствам. Второй – URI устройства (а точнее – пользователя на устроястве). URI устройства обычно называется контакт и содержится, соответственно, в поле Contact SIP-сообщения. AOR содердится в полях From и To.
Итак, Петр посылает INVITE для Ивана на Proxy-сервер:
Proxy-сервер перенаправляет запрос всем SIP-клиентам Ивана. Для простоты предположим, что Иван использует только одно устройство. Чтобы SIP-клиент понимал, что запрос был перенаправлен через Proxy, сервер добавляет свое заголовочное поле via:
SIP-клиент Ивана шлет ответ 180 Ringing (Иван слышит звонок). При этом он добавляет tag в поле To и указывает свой контакт в поле Contact. Кроме того, в первом поле via добавился параметр received этот параметр показывает, с какого адреса клиент Ивана получил запрос (т.е. адрес Proxy-сервера, как его видит Иван). Это бывает полезно знать для решения возникающих проблем:
Proxy, соответственно, перенаправляет запрос клиенту Петра. При этом он убирает свой via:
После отправки 180 Ringing, как только Иван снимет трубку, клиент Ивана отправляет на Prxoy ответ 200 OK:
Proxy передает этот ответ Петру, убирая при этом via:
Теперь самое интересное. Клиент Петра отправляет сообщение АСК непосредственно клиенту Ивана в обход Proxy. Причем, если бы Иван одновременно использовал несколько клиентов SIP, ответ пришел именно на тот, который нужно. Благодаря чему это возможно?
200 ОК отправляется с клиента на котором Иван снял трубку. Более того, в поле Contact ответа 200 ОК содержится URI, соответствующий пользователю Иван на конкретном устройстве. Таким образом клиент Петра отправляет АСК именно на это устройство, после чего участие Proxy больше не требуется:
Все остальные сообщения, включая медиа-траффик идут в обход Proxy.
В конце разговора клиент Ивана отправляет BYE напрямую клиенту Петра:
Петр в ответ шлет подтверждение:
Здесь все, как в первой части статьи.
Итак, мы рассмотрели взаимодействие SIP-клиентов с участием Proxу-сервера. Остался один единственный вопрос: откуда Proxy узнал адреса клиентов Ивана? С помощью процедуры регистрации. Как это происходит, я расскажу ниже.
Регистрация выглядит следующим образом:
Давайте подробнее рассмотрим каждое из сообщений. Иван отправляет на сервер запрос Register (для простоты считаем, что роль сервера регистрации установлена на proxy.domain.ru). Самое важное в этом запросе – поле Contact. Это адрес Ивана на конкретном устройстве:
В ответ сервер присылает 401 Unauthorized, то есть требование авторизации. Самое важное поле в ответе — WWW-Authenticate. Не сложно догадаться, что realm — это домен, а algorithm указывает, какой хеш-алгоритм мы будем использовать. Интерес вызывает поле nonce:
Nonce — это сокращение от «number used once». Nonce — это одноразовая случайная последовательность, которую клиент Ивана cкомбинирует со строкой пароля, после чего сгенерирует MD5-хеш от полученной строки и поместит результат в новый запрос в поле WWW-Authenticate (на самом деле все несколько сложнее, но для простоты будем считать, что все именно так). Для этого служит параметр response.
Зачем нужен nonce? Если бы клиент генерировал MD5 от пароля и не использовал nonce, то хеш каждый раз получался бы один и тот же. Злоумешленник мог бы перехватить такой хеш и использовать для авторизации. Это было бы столь же небезопасно, как передавать пароль в открытом виде.
Если использовать nonce, MD5 каждый раз берется от новой строки и получается разным. Поэтому даже перехватив хеш, злоумышленник скорее всего не сможет его использовать для авторизации.
Кстати, обратите внимание, что новый запрос на регистрацию имеет CSeq на единицу больше:
Сервер также комбинирует nonce с паролем Ивана и получает MD5-хеш. После этого он сравнивает свой хеш с хешем, полученным от Ивана. Если они совпадают, то сервер присылает 200 ОК. Обратите внимание на то, что в поле Contact добавился параметр expires. В данном случае регистрация будет храниться в базе сервера в течение 3600 секунд или одного часа:
Если Иван хочет продлить регистрацию, то он должен отправить еще один REGISTER в течение этого часа.
Что делать, если Иван использует сразу несколько устройств с поддержкой SIP? Все очень просто – необходимо отправить запрос на регистрацию с каждого из них.
После того, как в базе данного сервера регистрации появится соответствующая запись, Proxy-сервер сможет перенаправлять запросы на SIP-клиенты Ивана.
Вы могли заметить, что, в ответ на запрос регистрации, сервер присылает ответ, содержащий To-tag:
Понятно, что при установке диалога данный tag помогает избежать повторного получения одного и того же сообщения. Для этого существует правило: если сообщение не содержит To-tag и UAS уже получал сообщение с таким же CSeq, From-tag и Call-ID, то сообщение отбрасывается. Для чего же нужен To-tag, если мы не устанавливаем диалог с сервером регистрации. Лучший ответ, который я смог найти — в RFC 3261 написано, что ответ 200 ОК, приходящий на запрос без To-tag должен содержать To-tag. То есть, это ни для чего не нужно, но так принято.
Надеюсь, что работа протокола SIP, после прочтения статьи, стала для вас более понятной. Буду рад вашим комментариям.
Источника: https://habrahabr.ru/post/189332/
Теперь, когда мы разобрались с базовыми вещами, предлагаю перейти к реальной работе протокола.
В этой статье я планирую рассмотреть три вопроса:
- Выбор транспортного протокола и поиск Proxy;
- Работа через Proxy;
- Регистрация на Proxy-сервере.
Выбор транспортного протокола и поиск Proxy
Поскольку протокол SIP поддерживает несколько транспортных протоколов (UDP, TCP, SCTP, TLS), необходимо каким-то образом определять, какой протокол использовать. Для этого существет несколько способов.
Первый способ предполагает явное указание транспорта в SIP URI (кроме TLS). Выглядит это вот так:
Если транспорт явно не указан, то действует следующий алгоритм:
- Если SIP URI содержит IP-адрес, то для SIP URI используется UDP, для SIPS (Secure SIP) – TCP.
- Если IP-адрес не укзаан, но укзаан порт, то для SIP URI используется UDP, для SIPS – TCP.
- Если отсутсвует IP-адрес и порт, но в DNS присутствует соответсвующая NAPTR-запись, тогда “SIP+D2U” соответствует UDP, “SIP-D2T” указывает на TCP и “SIP-D2S” — на SCTP. NAPTR содержит ссылку на SRV-запись, которая будет использоваться для поиска Proxy-сервера. Если NAPTR остуствует, то должен быть выполнен запрос на поиск SRV-записи.
- Результатом SRV запроса будет имя и порт Proxy-сервера.
- Если SRV-запись отсутствует, то выполняется A или AAAA-запрос. При это для SIP URI используется UDP, для SIPS – TCP.
Для того, чтобы лучше разобраться, рассмотрим пример, когда мы хотим связаться с клиентом sip:ivan@domain.ru:
Итак, мы выяснили, параметры Proxy-сервера Ивана. Теперь предлагаю рассмотреть использование Proxy в рамках SIP-диалога.
Ремарка для тех, кто не знает, что такое NAPTR. Я узнал, что есть такой тип DNS-записи только, когда писал эту статью, так что не отчаивайтесь. Чуть подробнее про NAPTR здесь.
Взаимодействие с использованием Proxy
Для чего же нам необходим SIP Proxy? Как я уже сказал, в примере из 1-ой части статьи клиенты знали IP-адреса друг друга и могли общаться напрямую. В реальной жизни клиенты чаще всего получают адреса динамически, поэтому нет смысла «запоминать» тот или иной IP. Первое, что приходит на ум в данной ситуации – использовать A-записи DNS и определить реальный действующий адрес. Однако тут кроется следующая проблема: IP-адрес идентифицирует конкретное устройство, а не пользователя на нем. Особенностью взаимодействия SIP является то, что обмен сообщения происходит не на уровне устройство-устройство, а на пользователь-пользователь. При этом один пользователь может одновременно использовать несколько SIP-клиентов: на мобильном телефоне, на рабочем компьютере, на домашнем компьютере и на SIP-телефоне. Как же быть?
Протокол SIP предлагает следующее решение: создается SIP Proxy и каждый пользователь регистрирует свои устройства на этом Proxy (точнее пользователи регистрируются на сервере регистрации, а Proxy имеет доступ к базе регистрации, но для простоты будем считать, что это один и тот же сервер). Как это делается, я покажу ниже. Пока просто запомните, что Proxy знает, как именно найти тот или иной клиент пользователя.
Когда Петр звонит Ивану, выполняется следующая последовательность действий:
- SIP-клиента Петра определяет адрес и протокол SIP Proxy Ивана (как это делается — см. выше)
- Клиент отправляет на Proxy запрос INVITE
- Proxy-сервер смотрит, на каких устройствах зарегистрировался Иван и отправляет запрос на все эти устройства
- Иван отвечает на звонок на одном из устройств и шлет 200 OK на Proxy
- Proxy перенаправляет 200 OK Петру
- Петр получает SIP-адрес Ивана на конкретном устройстве из поля Contact вответе 200 ОК и шлет ответ напрямую, минуя Prxoy
- Все последующее общение идет также напрямую
На схеме это выглядит следующим образом:
Для тех, кто изучил первую часть статьи, все выглядит довольно знакомо; добавился только промежуточный Proxy-сервер. Соответственно и обмен сообщениями изменился незначительно.
Прежде, чем преступим к детальному рассмотрению, маленькая ремарка. В рамках SIP разделяют два типа URI. Первый из них – ползовательский URI, также известный как address of recorf (AOR). Запрос, отправленный на этот адрес предполагает поиск в базе данных Proxy и отправку запроса одному или несольким устройствам. Второй – URI устройства (а точнее – пользователя на устроястве). URI устройства обычно называется контакт и содержится, соответственно, в поле Contact SIP-сообщения. AOR содердится в полях From и To.
Начало разговора
Итак, Петр посылает INVITE для Ивана на Proxy-сервер:
Proxy-сервер перенаправляет запрос всем SIP-клиентам Ивана. Для простоты предположим, что Иван использует только одно устройство. Чтобы SIP-клиент понимал, что запрос был перенаправлен через Proxy, сервер добавляет свое заголовочное поле via:
SIP-клиент Ивана шлет ответ 180 Ringing (Иван слышит звонок). При этом он добавляет tag в поле To и указывает свой контакт в поле Contact. Кроме того, в первом поле via добавился параметр received этот параметр показывает, с какого адреса клиент Ивана получил запрос (т.е. адрес Proxy-сервера, как его видит Иван). Это бывает полезно знать для решения возникающих проблем:
Proxy, соответственно, перенаправляет запрос клиенту Петра. При этом он убирает свой via:
После отправки 180 Ringing, как только Иван снимет трубку, клиент Ивана отправляет на Prxoy ответ 200 OK:
Proxy передает этот ответ Петру, убирая при этом via:
Теперь самое интересное. Клиент Петра отправляет сообщение АСК непосредственно клиенту Ивана в обход Proxy. Причем, если бы Иван одновременно использовал несколько клиентов SIP, ответ пришел именно на тот, который нужно. Благодаря чему это возможно?
200 ОК отправляется с клиента на котором Иван снял трубку. Более того, в поле Contact ответа 200 ОК содержится URI, соответствующий пользователю Иван на конкретном устройстве. Таким образом клиент Петра отправляет АСК именно на это устройство, после чего участие Proxy больше не требуется:
Все остальные сообщения, включая медиа-траффик идут в обход Proxy.
Конец разговора
В конце разговора клиент Ивана отправляет BYE напрямую клиенту Петра:
Петр в ответ шлет подтверждение:
Здесь все, как в первой части статьи.
Итак, мы рассмотрели взаимодействие SIP-клиентов с участием Proxу-сервера. Остался один единственный вопрос: откуда Proxy узнал адреса клиентов Ивана? С помощью процедуры регистрации. Как это происходит, я расскажу ниже.
SIP-регистрация
Регистрация выглядит следующим образом:
Давайте подробнее рассмотрим каждое из сообщений. Иван отправляет на сервер запрос Register (для простоты считаем, что роль сервера регистрации установлена на proxy.domain.ru). Самое важное в этом запросе – поле Contact. Это адрес Ивана на конкретном устройстве:
В ответ сервер присылает 401 Unauthorized, то есть требование авторизации. Самое важное поле в ответе — WWW-Authenticate. Не сложно догадаться, что realm — это домен, а algorithm указывает, какой хеш-алгоритм мы будем использовать. Интерес вызывает поле nonce:
Nonce — это сокращение от «number used once». Nonce — это одноразовая случайная последовательность, которую клиент Ивана cкомбинирует со строкой пароля, после чего сгенерирует MD5-хеш от полученной строки и поместит результат в новый запрос в поле WWW-Authenticate (на самом деле все несколько сложнее, но для простоты будем считать, что все именно так). Для этого служит параметр response.
Зачем нужен nonce? Если бы клиент генерировал MD5 от пароля и не использовал nonce, то хеш каждый раз получался бы один и тот же. Злоумешленник мог бы перехватить такой хеш и использовать для авторизации. Это было бы столь же небезопасно, как передавать пароль в открытом виде.
Если использовать nonce, MD5 каждый раз берется от новой строки и получается разным. Поэтому даже перехватив хеш, злоумышленник скорее всего не сможет его использовать для авторизации.
Кстати, обратите внимание, что новый запрос на регистрацию имеет CSeq на единицу больше:
Сервер также комбинирует nonce с паролем Ивана и получает MD5-хеш. После этого он сравнивает свой хеш с хешем, полученным от Ивана. Если они совпадают, то сервер присылает 200 ОК. Обратите внимание на то, что в поле Contact добавился параметр expires. В данном случае регистрация будет храниться в базе сервера в течение 3600 секунд или одного часа:
Если Иван хочет продлить регистрацию, то он должен отправить еще один REGISTER в течение этого часа.
Что делать, если Иван использует сразу несколько устройств с поддержкой SIP? Все очень просто – необходимо отправить запрос на регистрацию с каждого из них.
После того, как в базе данного сервера регистрации появится соответствующая запись, Proxy-сервер сможет перенаправлять запросы на SIP-клиенты Ивана.
Bonus для тех, кому интересно
Вы могли заметить, что, в ответ на запрос регистрации, сервер присылает ответ, содержащий To-tag:
Понятно, что при установке диалога данный tag помогает избежать повторного получения одного и того же сообщения. Для этого существует правило: если сообщение не содержит To-tag и UAS уже получал сообщение с таким же CSeq, From-tag и Call-ID, то сообщение отбрасывается. Для чего же нужен To-tag, если мы не устанавливаем диалог с сервером регистрации. Лучший ответ, который я смог найти — в RFC 3261 написано, что ответ 200 ОК, приходящий на запрос без To-tag должен содержать To-tag. То есть, это ни для чего не нужно, но так принято.
Надеюсь, что работа протокола SIP, после прочтения статьи, стала для вас более понятной. Буду рад вашим комментариям.
Источника: https://habrahabr.ru/post/189332/
Комментариев нет:
Отправить комментарий