Что такое sip прокси
IP-Телефония: Архитектура сети SIP
Архитектура сети SIP
Рис. 2 Архитектура «клиент-сервер»
Клиент выдает запросы, в которых указывает, что он желает получить от сервера. Сервер принимает запрос, обрабатывает его и выдает ответ, который может содержать уведомление об успешном выполнении запроса, уведомление об ошибке или информацию, затребованную клиентом.
Управление процессом обслуживания вызова распределено между разными элементами сети SIP. Основным функциональным элементом, реализующим функции управления соединением, является терминал. Остальные элементы сети отвечают за маршрутизацию вызовов, а в некоторых случаях предоставляют дополнительные услуги.
Кроме терминалов определены два основных типа сетевых элементов SIP: прокси-сервер (proxy server) и сервер переадресации (redirect server).
Сервер первого типа хранит в памяти входящий запрос, который явился причиной генерации одного или нескольких исходящих запросов. Эти исходящие запросы сервер также запоминает Все запросы хранятся в памяти сервера только до окончания транзакции, т.е. до получения ответов на запросы.
Сервер первого типа позволяет предоставить большее количество услуг, но работает медленнее, чем сервер второго типа. Он может применяться для обслуживания небольшого количества клиентов, например, в локальной сети. Прокси-сервер должен сохранять информацию о состояниях, если он:
- — использует протокол TCP для передачи сигнальной информации;
— работает в режиме многоадресной рассылки сигнальной информации;
— размножает запросы.
Последний случай имеет место, когда прокси-сервер ведет поиск вызываемого пользователя сразу в нескольких направлениях, т.е. один запрос, который пришел к прокси-серверу, размножается и передается одновременно по всем этим направлениям.
Алгоритм работы пользователей с прокси-сервером выглядит следующим образом. Поставщик услуг IP-телефонии сообщает адpec прокси-сервера своим пользователям. Вызывающий пользователь передает к прокси-серверу запрос соединения. Сервер обрабатывает запрос, определяет местоположение вызываемого пользователя и передает запрос этому пользователю, а затем получает от него ответ, подтверждающий успешную обработку запроса, и транслирует этот ответ пользователю, передавшему запрос. Прокси-сервер может модифицировать некоторые заголовки сообщений, которые он транслирует, причем каждый сервер, обработавший запрос в процессе его передачи от источника к приемнику, должен указать это в SIP-запросе для того, чтобы ответ на запрос вернулся по такому же пути.
Сервер переадресации предназначен для определения текущего адреса вызываемого пользователя. Вызывающий пользователь передает к серверу сообщение с известным ему адресом вызываемого пользователя, а сервер обеспечивает переадресацию вызова на текущий адрес этого пользователя. Для реализации этой функции сервер переадресации должен взаимодействовать с сервером определения местоположения.
Сервер переадресации не терминирует вызовы как сервер RAS и не инициирует собственные запросы как прокси-сервер. Он только сообщает адрес либо вызываемого пользователя, либо прокси-сервера. По этому адресу инициатор запроса передает новый запрос. Сервер переадресации не содержит клиентскую часть программного обеспечения.
Но пользователю не обязательно связываться с каким-либо SIP-сервером. Он может сам вызвать другого пользователя при условии, что знает его текущий адрес.
Для хранения текущего адреса пользователя служит сервер определения местоположения пользователей, представляющий собой базу данных адресной информации. Кроме постоянного адреса пользователя, в этой базе данных может храниться один или несколько текущих адресов.
Этот сервер может быть совмещен с прокси-сервером (в таком случае он называется registrar) или быть реализован отдельно от прокси-сервера, но иметь возможность связываться с ним.
В RFC 2543 сервер определения местоположения представлен как отдельный сетевой элемент, но принципы его работы в этом документе не регламентированы. Стоит обратить внимание на то, что вызывающий пользователь, которому нужен текущий адрес вызываемого пользователя, не связывается с сервером определения местоположения напрямую. Эту функцию выполняют SIP-серверы при помощи протоколов LDAP (RFC 1777), rwhois (RFC 2167), или других протоколов.
Резюмируя все сказанное выше, отметим, что сети SIP строятся из элементов трех основных типов: терминалов, прокси-серверов и серверов переадресации. На рис. 3 приведен пример возможного построения сети SIP.
Рис. 3 Пример построения сети SIP
Структурная схема организации услуг SIP-сервера представлена на рисунке 4.
Рис. 4 Структурная схема организации услуг SIP-сервера
Модуль управления услугами отвечает за предоставление услуг и за общее управление сервером. Принятые сервером запросы и ответы поступают в модуль управления услугами и обрабатываются им, на основании чего определяется реакция на полученные сообщения. Интерфейс человек-машина позволяет гибко менять настройки сервера и вести мониторинг сети.
База знаний
SIP прокси
Прокси,сервер (от английского proxy – представитель) представляет интересы пользователя в сети. Он принимает запросы, обрабатывает их и, в зависимости от типа запроса, выполняет определенные действия. Это может быть поиск и вызов пользователя, маршрутизация запроса, предоставление услуг и т.д. Прокси,сервер состоит из клиентской и серверной частей, поэтому может принимать вызовы, инициировать собственные запросы и возвращать ответы. Прокси,сервер может быть физически совмещен с сервером определения местоположения/сервером обработки регистраций (в этом случае он называется registrar) или существовать отдельно от этого сервера, но иметь возможность взаимодействовать с ним по протоколам LDAP (RFC 1777), rwhois
(RFC 2167) и по любым другим протоколам.
Предусмотрено два типа прокси,серверов – с сохранением состояний (stateful) и без сохранения состояний (stateless).
Сервер первого типа хранит в памяти входящий запрос, который явился причиной генерации одного или нескольких исходящих запросов. Эти исходящие запросы сервер также запоминает. Все запросы хранятся в памяти сервера только до окончания транзакции, т.е. дополучения ответов на запросы.
Сервер первого типа позволяет предоставить большее количество услуг, но работает медленнее, чем сервер второго типа. Он может применяться для обслуживания небольшого количества клиентов, например, в локальной сети. Прокси,сервер должен сохранять информацию о состояниях, если он:
Сервер без сохранения состояний просто ретранслирует запросы и ответы, которые получает. Он работает быстрее, чем сервер первого типа, так как ресурс процессора не тратится на запоминание состояний, вследствие чего сервер этого типа может обслужить большее количество пользователей. Недостатком такого сервера является то, что на его базе можно реализовать лишь наиболее простые услуги. Впрочем, прокси,сервер может функционировать как сервер с сохранением состояний для одних пользователей и как сервер без сохранения состояний – для других.
Алгоритм работы пользователей с прокси,сервером выглядит следующим образом. Поставщик услуг IP,телефонии сообщает адрес прокси,сервера своим пользователям. Вызывающий пользователь передает к прокси,серверу запрос соединения. Сервер обрабатывает запрос, определяет местоположение вызываемого пользователя и передает запрос этому пользователю, а затем получает от него ответ, подтверждающий успешную обработку запроса, и транслирует этот ответ пользователю, передавшему запрос.
Прокси,сервер может модифицировать некоторые заголовки сообщений, которые он транслирует, причем каждый сервер, обработавший запрос в процессе его передачи от источника к приемнику должен указать это в SIP,запросе для того, чтобы ответ на запрос вернулся по такому же пути.
Выдержка из SIP RFC:
С помощью записей DNS SRV, Вы можете назначить SIP прокси сервер для заданного домена, чтобы дать возможность вызова ваших абонентов с использованием URL, вместо использования жестко заданного SIP прокси сервера.
Взаимодействие клиентов SIP. Часть 2
В предыдущей статье мы рассмотрели простое взаимодействие клиентов SIP без использования Proxy-сервера. Такое взаимодействие на практике встречается чрезвычайно редко, но отлично подходит для того, чтобы понять основы SIP.
Выбор транспортного протокола и поиск Proxy
Поскольку протокол SIP поддерживает несколько транспортных протоколов (UDP, TCP, SCTP, TLS), необходимо каким-то образом определять, какой протокол использовать. Для этого существет несколько способов.
Первый способ предполагает явное указание транспорта в SIP URI (кроме TLS). Выглядит это вот так:
Итак, мы выяснили, параметры Proxy-сервера Ивана. Теперь предлагаю рассмотреть использование Proxy в рамках SIP-диалога.
Ремарка для тех, кто не знает, что такое NAPTR. Я узнал, что есть такой тип DNS-записи только, когда писал эту статью, так что не отчаивайтесь. Чуть подробнее про NAPTR здесь.
Взаимодействие с использованием Proxy
Для чего же нам необходим 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 узнал адреса клиентов Ивана? С помощью процедуры регистрации. Как это происходит, я расскажу ниже.
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, после прочтения статьи, стала для вас более понятной. Буду рад вашим комментариям.
Протокол SIP: инфраструктура, механизм обмена сообщениями, дополнительные возможности
Протокол SIP — (Session Initiation Protocol) — протокол установления сеанса связи. Данный протокол является одним из основных, используемых в IP-телефонии. Он был разработан в 1996 году Марком Хэндли, Джонатаном Розенбергом и Хеннигом Шульцринном, в 1999 году была выпущена версия 1.0 (RFC 2543), затем протокол был доработан, и в 2002 году и принят в качестве протокола […]
Протокол SIP — (Session Initiation Protocol) — протокол установления сеанса связи. Данный протокол является одним из основных, используемых в IP-телефонии. Он был разработан в 1996 году Марком Хэндли, Джонатаном Розенбергом и Хеннигом Шульцринном, в 1999 году была выпущена версия 1.0 (RFC 2543), затем протокол был доработан, и в 2002 году и принят в качестве протокола сигнализации в мобильной телефонии (RFC 3261). SIP был изначально разработан только для работы с сеансами связи (установка/завершение/изменение), но не для передачи данных.Отметим некоторые особенности работы протокола SIP:
Инфраструктура сетевых агентов протокола SIP
Протокол SIP разработан таким образом, что два конечных пира могут устанавливать соединение без участия каких-либо дополнительных элементов, однако, из соображений эксплуатации сетей были введены следующие типы агентов, которые взаимодействуют по модели клиент-сервер:
Обмен сообщениями в протоколе SIP
SIP является текстовым протоколом и его синтаксис во многом схож с HTTP. Сообщения в SIP разделяются на запросы и ответы. Первая строка запроса содержит метод, определяющий природу запроса, затем следует URI-адрес назначения запроса. Ответ содержит в первой строке код, определяющий результат поступившего запроса.
Запросы генерируются терминалами-клиентами к серверам и инициализируют функциональность протокола. Отправка запроса подразумевает получение ответа о результате транзакции. Рассмотрим подробно возможные варианты запросов SIP клиентов:
Ответы разделяются на классы, определяемые их цифровым кодом. Рассмотрим подробно классы возможных ответов:
Дополнительные возможности SIP
SIP-сжатие
Являясь текстовым протоколом, SIP может создавать высокую нагрузку на используемый транспортный протокол. Возможны случаи превышения максимального MTU при использования в качестве транспорта протокола UDP. Для обхода подобных проблемных ситуаций SIP предусматривает сжатие заголовков сообщений и передачу их в компактной форме. Компактная форма может быть заменена на обычную в любое время передачи сообщения, без изменения его семантики.
Сигнализация SIP DTMF
Протокол SIP использует четыре метода для передачи цифровых сигналов между терминальными агентами:
SIP Perfomance Tester
SIP Perfomance Tester является инструментом для тестирования ПО, либо инфраструктуры сети под нагрузкой. Он позволяет определить максимальное количество вызовов, количество вызовов в секунду, так же количество одновременных вызовов. Данный продукт имитирует SIP- и RTP- трафик для того, чтобы определить будет ли стабильно работать ваша конфигурация сервера или сети под нагрузкой. SIP Perfomance Tester измеряет такие показатели, как задержка ответа, соотношение запросов и ответов, потеря пакетов, время задержки приема или передачи.
Security SIP разработан для обеспечения безопасной передачи информации путем шифрования данных, передаваемых по протоколу SIP. SIPS использует TLS для обеспечения защищенного канала связи между клиентом и сервером с использованием механизма рукопожатия. Данные же упаковываются по протоколу SRTP в шифрованные IP-пакеты и их передача начинается только после того, как устанавливается SSL-туннель между клиентом и сервером. Важной особенностью использования SSIP является необходимость его поддержки всеми используемыми устройствами в сети, если хотя бы один узел не поддерживает SRTP/TLS, то установить защищенное соединение будет невозможно.
SIP ALG
SIP ALG это механизм маршрутизации SIP-трафика, несколько похожий на SIP Proxy. ALG является программным шлюзом и используется в прослойке между устройствами SIP и сетью. SIP ALG анализирует поступающий трафик и может управлять им разрешая, запрещая, либо перенаправляя его другим узлам сети. Данный программный шлюз позволяет синхронизировать входящие потоки либо сессии между клиентами и серверами. Также в число его возможностей входит использование динамических портов транспортных протоколов для взаимодействия с устройствами NAT. Этот механизм позволяет SIP-трафику беспрепятственно транслировать адреса назначения и отправителя через таблицы NAT. При использовании данной технологии маскарадинг адресов происходит на уровне самого шлюза ALG.
Kamailio SIP proxy: пример установки и минимальной настройки
В работе системного администратора, занимающегося внедрением систем телефонии на базе Asterisk, рано или поздно может возникнуть ситуация, когда аппаратных возможностей одного сервера для обработки всех вызовов уже недостаточно. Соответственно, возникает необходимость разделить нагрузку на несколько серверов. Одним из способов решения такой задачи является использование SIP proxy, но стоит признать, что в отличие от Asterisk, информации по SIP proxy, форумов, примеров и описаний, меньше как минимум на порядок. Цель этой статьи — показать на простом примере возможность использования SIP proxy Kamailio в связке с Asterisk так, чтобы максимально облегчить освоение SIP proxy для новичков.
Все настройки в рамках данного примера мы будем производить на виртуальных машинах, размещенных в локальной сети, хотя если бы они имели публичные адреса и находились бы в облаке, принципиальной разницы бы не было.
Предположим, что в организации уже установлен Asterisk, и сотрудники обрабатывают большое количество входящих звонков, с которым сервер уже не справляется. Мы добавим еще один сервер Asterisk (точнее, клонируем существующий), а SIP proxy возьмет на себя роль «распределителя» входящих звонков.
Начнем с выбора SIP proxy. На хабре есть хорошая статья на эту тему, в которой рассмотрена история развития основных проектов. В отличие от автора этой статьи, мой выбор пал на Kamailio и web-интерфейс для него под названием Siremis.
Установим Kamailio. В качестве ОС будем использовать CentOs 6.8.
В первую очередь, необходимо отключить SELinux, обновить пакеты и установить необходимые зависимости:
Нам потребуется доступ к 80 порту для работы с web-интерфейсом и к 5060 udp для работы с sip, поэтому добавим правила IPTables:
Создаем файл /etc/yum.repos.d/kamailio.repo с содержимым:
И устанавливаем kamailio:
Не забудем добавить демоны в автозагрузку:
Отредактируем файл /etc/kamailio/kamctlrc: нужно раскомментировать строку
и указать SIP_DOMAIN. В силу того, что мы настраиваем систему в локальной сети, достаточно будет указать ip-адрес, в моем случае
Ниже можно отредактировать параметры подключения к базе данных, но в случае учебного стенда менять их не обязательно.
Запустим MySQL и сгенерируем необходимые таблицы:
На все вопросы мастера отвечаем утвердительно.
Теперь отредактируем основной конфигурационный файл /etc/kamailio/kamailio.cfg. Логически он разбит на несколько секций: глобальные параметры, загрузка модулей, установка параметров модулей и маршруты. Каждый модуль Kamailio выполняет определенную функцию, поэтому можно загружать только необходимые для конкретной задачи библиотеки. Начало файла приведем к виду:
Как понятно из комментариев ниже, эти директивы включают необходимые модули, например WITH_MYSQL, определенный в начале файла, ниже приводит к загрузке модуля mysql.so:
Безусловно, можно загрузить все модули вручную, но использование директивы гораздо удобнее. WITH_AUTH, например, дает возможность пользователям регистрироваться на Kamailio с использованием имени и пароля, а все варианты выбора вы можете посмотреть в комментариях ниже.
Для дальнейшей корректной работы web-интерфейса и статистики внесем еще несколько изменений:
После всех строк loadmodule добавим загрузку еще двух:
Перед секцией маршрутов, которая отделяется строкой ####### Routing Logic ######## добавим параметры загруженных модулей:
И добавим дополнительный маршрут после последней секции route в районе 910 строки файла:
Запускаем Kamailio и проверяем, что он запустился:
Если Kamailio не запускается, нужно посмотреть лог /var/log/messages — именно туда будут попадать ошибки Kamailio, если дополнительно не настроить rsyslog, что не представляет большой сложности.
По умолчанию используется база MySQL kamailio c пользователем kamailio c паролем kamailiorw, если конечно не изменить установки по умолчанию в файле /etc/kamailio/kamctlrc перед созданием базы данных. В том случае, если вы изменили эти установки, будет нелишним пройтись автозаменой по основному конфигурационному файлу kamailio.cfg и внести корректные данные подключения к базе.
В принципе, Kamailio может работать и без базы данных — все необходимые значения для модулей можно задавать в конфигурационном файле или хранить во внешних файлах, но использование БД, особенно на крупных проектах, гораздо удобнее, плюс именно с базой будет работать web-интерфейс Siremis, который мы сейчас установим.
Нужно скачать, разархивировать файлы, скопировать их в директорию, с которой будет работать apache и дать верные права:
В секцию VirtualHost в конфигурации apache для Siremis добавим
При дальнейшей установке последней на момент написания статьи версии Siremis 4.3.0 могут возникнуть проблемы в случае, если у вас не задан date.timezone, поэтому рекомендуется сразу внести изменения в php.ini:
Для Siremis потребуется отдельная база данных. Добавим пользователя:
Вы можете изменить параметры подключения к базе, но не забудьте тогда задать верные значения в дальнейшем.
Теперь можно перезапустить apache и перейти к завершающему этапу установки Siremis — уже через браузер. Перейдите по адресу ваш-ip/siremis
Если проверка системы пройдена, можно начинать установку.
Обратите внимание: по умолчанию под звездочками скрываются дефолтные пароли от пользователей Kamailio и Siremis, так что если вы не вносили изменений ранее, то и на этом шаге можно не забивать пароли вручную.
Обязательно поставьте галочки на всех пунктах — Create Siremus DB, Import Dafault Data, Update SIP DB, Replace DB config.
Проверьте, что указаны корректные данные.
И на этом установка завершена.
Давайте попробуем осуществить первый звонок через Kamailio. Для этого перейдем на вкладку SIP Admin menu и добавим новый домен в Domain List. Kamailio будет обслуживать только перечисленные здесь домены (или ip-адреса).
В случае, если к адресу привязан домен, и пользователи могут регистрироваться как указав ip-адрес, так и указав домен, следует добавить и доменное имя в список. В нашем случае добавляем только ip-адрес сервера, к которому будут обращаться клиенты.
Теперь, используя софтфон, например Zoiper, мы можем зарегистрироваться на сервере и осуществить звонок с 101 на 102 номер или наоборот и убедиться в том, что все предыдущие действия были выполнены верно.
Перейдем к настройке распределения входящих вызовов. В локальной сети у нас есть 2 виртуальные машины с Asterisk на адресах 192.168.0.234 и 192.168.0.235, и нам нужно поровну распределить входящие звонки между ними. В данной ситуации мы будем использовать модуль dispatcher, который предоставляет необходимый функционал.
Вернемся в консоль, и добавим в kamailio.cfg в секцию загрузки модулей
а также два параметра — подключения к базе данных, в которой и будет храниться список серверов Asterisk, и частоту проверки этих серверов, чтобы звонок ни в коем случае не ушел на выключенный сервер:
Вообще, полный список модулей, их параметров и функций всегда можно посмотреть на официальном сайте. После подключения модуля перезапустим Kamailio и убедимся в том, что он запустился. В случае возникновения проблем (модули могут зависеть от других, требовать установки определенных параметров как для самого модуля, так и для тех, от которых он зависит) мы увидим ошибку в логе.
Теперь перейдем к секции маршрутов. Созданные по умолчанию маршруты в принципе обеспечивают необходимый минимум, например, при попытке зарегистрироваться с неверным паролем, Kamailio отдаст ошибку 401, а при попытке позвонить на несуществующее направление — 404. Сложность в понимании маршрутизации Kamailio представляют используемые переменные и функции, которые предоставляются различными используемыми модулями, и не всегда сходу можно понять, какая переменная или функция к какому модулю относится. Для наших учебных целей маршрут потребуется совсем простой — в самое начало главного маршрута мы добавим условие:
Если приходит запрос типа INVITE, то есть приглашение к началу разговора, то мы выбираем один из серверов, которые позже занесем в таблицу, из группы 1 по стратегии выбора 4 — round-robin. Затем посылаем ответ вызывающему и осуществляем перевод звонка на выбранное назначение. Обратите внимание, что теперь абсолютно любой INVITE будет обрабатываться таким образом, так что возможность позвонить с 101 номера на 102, которые мы создавали ранее, будет утрачена — звонки с них тоже будут улетать на один из серверов Asterisk, и поступающие извне запросы INVITE также будут напрямую уходить на Asterisk без всякой проверки источника запроса.
Для того, чтобы Asterisk мог обработать такие вызовы, нужно добавить peer следующего вида на каждый из серверов:
Теперь можно добавить сервера Asterisk в базу данных Kamailio через web-интерфейс:
Setid задаст к какой группе серверов относится новый сервер, Priority не используется в стратегии выбора round-robin, но может использоваться в других стратегиях, а Flags в данном случае устанавливает, что по умолчанию мы считаем сервер неактивным и проверяем его состояние.
Можно переходить к тестированию. Используя софтфон, например, Zoiper, можно осуществить вызов напрямую на Kamailio, без всяких аккаунтов и регистраций. Достаточно в поле набора ввести sip:1@192.168.0.237. Сразу после этого вызов будет переадресован на один из Asterisk и обработан в соответствии с диалпланом. Следующий вызов пойдет на второй сервер.
В принципе, стоявшую перед нами учебную задачу — распределять входящие вызовы поровну между серверами, — мы решили. Однако, далеко не каждый оператор связи готов отдавать звонки на ваш ip-адрес напрямую, без регистрации, и нужно будет посылать запросы типа REGISTER. Этот функционал реализует модуль uac. Добавим в нашу схему еще один Asterisk — он будет исполнять роль провайдера. На нем создадим какой-нибудь внутренний номер, например, 200200, который будет требовать регистрацию.
Загрузим модуль в конфигурационном файле:
И зададим пару обязательных в нашем случае параметров:
Кроме того, потребуется внести изменение в параметр другого модуля. Найдите в файле строку
Теперь можно настроить регистрацию, перезапустив предварительно Kamailio, чтобы модуль загрузился:
Обратите внимание на поле Realm. По умолчанию, вы можете ввести в него что угодно, но тогда регистрация проходить не будет, а в логе вы увидите то-то вроде:
Именно поэтому при возникновении каких-либо проблем не стоит сразу перечитывать мануал, искать другие инструкции и сомневаться в своих способностях — чаще всего объяснение можно найти в логе.
Остается только убедиться в том, что абонент 200200 зарегистрирован на Asterisk, играющем роль провайдера, и осуществить звонок с любого другого номера на 200200.
На этом пример настройки Kamailio мы заканчиваем, но обратите внимание, что в статье не рассмотрена работа за NAT, безопасность, маршрутизация исходящих вызовов и многое другое, что может потребоваться в реальной ситуации. Однако надеюсь, что эта статья облегчит для вас освоение Kamailio.