Более подробную информацию и тарифы можно получить на сайте услуги.

• Минимизация отклонений от стандартной конфигурации Asterisk-realtime.
• Вся аутентификация — внутри Kamailio.
• Все звонки, в т.ч. и локальные — проходят через Asterisk.
• Все media потоки — проходят через Asterisk.
• Обработка SIP сообщений не связанных со звонками выполняется с помощью Kamailio.

Согласно предложенной схеме, регистрация выглядит следующим образом:

Аппарат А, отправляет запрос REGISTER и после успешной аутентификации регистрируется на Kamailio. Kamailio регистрируется на сервере Asterisk от имени клиента, указав в качестве котакта свой IP адрес. Таким образом при звонке с Asterisk к абоненту A, Asterisk отправит INVITE к Kamailio, а тот в свою очередь передаст его клиенту. Кстати о звонках, звонок между абонентами A и B выглядит следующим образом:

Для установки соединения между аппаратами A и B, аппарат A отправляет запрос INVITE по IP адресу сервера Kamailio. После успешной аутентификации, Kamailio отправляет INVITE к Asterisk. Asterisk, отправляет INVITE к абоненту B, однако в качестве контакта для абонента B указан IP адрес Kamailio. Получив INVITE от Asterisk для абонента B, Kamailio проверяет базу зарегистрированных пользователей (usrloc) и пытается перенаправить INVITE для абонента B по его фактическому адресу.

На мой взгляд: просто, элегантно, и, самое главное, масштабируемо. Я обычно использую несколько иную балансировку нагрузки, однако предложенная схема заслуживает самого тщательного изучения. Автор документа, Daniel-Constantin Mierla, обещает регулярно обновлять инструкцию, поддерживая её в актуальном состоянии.

1. Voice Over Internet Protocol Providers (VoIP) +179035%
2. Search Engines +1656%
3. eCommerce & Online Auctions +469%
4. Online Dating & Matchmaking +249%
5. Tank & Armored Vehicle Manufacturing +245%
6. Petrochemical Manufacturing +221%
7. Mining Support +187%
8. Wireless Telecommunications Carriers +183%
9. Biotechnology +182%
10. Warehouse Clubs and Supercenters +147%

Рынок VoIP вырос за 10 лет в 1790 раз! Это почти в 1000 раз больше роста рынка танков и броневиков. На первый взгляд, рост в +179035% выглядит подозрительно. Сразу же вспоминается VNIX с его ростом +2421,84 %. С другой стороны, вспомним ситуацию в 1999-2000 годах: операторов связи можно было пересчитать по пальцам одной руки, а их клиентов – по пальцам другой. Качество интернета вообще и «последней мили» в частности – было большой преградой для повсеместного внедрения IP телефонии. Сегодня, мы имеем качественно иную ситуацию. Широкополосный интернет есть везде, даже в России. А появление новых инструментов для IP-телефонии (в первую очередь Asterisk) позволило стать оператором связи – любому студенту Вероятней всего, большой рост рынка VoIP обусловлен эффектом мизерной базы. Вряд ли компания IBISWorld, функционирующая с 1971 года, позволит себе допустить ошибку в несложных расчётах.

Другой интересный нюанс, на который я хотел бы обратить внимание – структура десятки лидеров. Половина десятки это IT рынки, причём первая половина. Рост IT рынков существенно опережает рост рынков реального сектора экономики. Исследование никак не объясняет этот момент. Хочется верить что это, так же как и в случае с VoIP – лишь проявление эффекта малой базы, а не предвестие очередного пузыря доткомов.

• IBISWorld
• VoIP Named As Fastest Growing Technology Of The Past Decade

Не получилось и у талантливого программиста Jeremy McNamara, создателя chan_h323, основателя компании Nufone. В мае этого года он в очередной раз объявил о закрытии своей компании Nufone и приурочил к этому событию серию заметок «How Not To Do Business» первая из которых называется «How The Hell Happened To NuFone?» Но обо всём по порядку.

В 2002 году, работая инженером в VoIP компании штат Мичиган, Джереми предложил своему работодателю использовать Asterisk в качестве универсальной платформы предоставления услуг. По его словам, на тот момент в компании был зоопарк из разнородного оборудования: Cisco, Clarent и собственных разработок на базе Dialogic. Asterisk был отвергнут, только из-за того что он OpenSource.

Сразу после релиза Asterisk-oh323, Джереми вновь предложил работодателю использовать Asterisk. На этот раз дело дошло до тестов, однако реализация протокола H323 была очень слаба и Asterisk был снова отвергнут. Не смотря на провал попыток внедрить Asterisk у себя на работе, Джереми продолжил «играться» с ним, в свободное от работы время. Попытки исправить Asterisk-oh323 натолкнулись на нежелание автора вносить какие-либо чужие изменения в свой код. Тогда, за одни выходные, Джерими написал первый работоспособный вариант chan_h323, было это в январе 2003 года.

Проводя большое количество времени в Asterisk сообществе (IRC, список рассылки и т.д.). Джереми заметил, что существует большой неудовлетворенный спрос на «Asterisk-friendly» провайдеров. На этот раз он предложил своему работодателю партнёрскую схему: колокейшен, электричество и PRI в обмен на любые настройки и консультации по Asterisk. Работодатель не устоял и сдался под натиском Джереми. Так появился nufone.

Первый сервер был обычным компьютером, с чужой Zaptel/DAHDI картой на 4 потока без каких либо отказоустойчивых/дублированных подсистем. Более года аккаунты заводились вручную в текстовом файле. С появлением «портала», в июне 2004 года, где пользователи могли регистрироваться самостоятельно, рост клиентской базы и трафика получил взрывной характер. За несколько дней были выбраны все 4 имевшихся потока, и срочно понадобилось расширение. По словам Джереми, «Nufone рос быстрее, чем желал расти вышестоящий оператор». За полтора года деятельности Джереми из наёмного работника превратился в крупнейшего клиента. Вероятно, вышестоящего оператора не устраивала маржа получаемая с Nufone, поэтому у Джереми начались неприятности.

Первой ласточкой было письмо о якобы неоплаченном счёте на 125 000 $. На основании этого письма, оборудование Nufone (тот самый суперсервер) выключали несколько раз. Не сложно представить, что такое для телефонной компании, отключение на 5 минут. Это колоссальный удар по репутации. Последнее отключение продлилось несколько дней. Это, фактически, была первая (клиническая ) смерть nufone.

Во время вынужденного простоя, Джереми сумел оперативно переехать на колокейшен к другому оператору. На этом увлекательное повествование заканчивается, Джереми обещал продолжить рассказ, но прошло уже пол года, а продолжения пока нет.

Возвращаясь к тому, с чего я начал: невозможно стать хорошим бизнесменом в одно мгновение. Бизнес это не только успешные продажи, бизнес, в первую очередь, это план развития. Успешно начав, можно потерять всё, только потому, что инфраструктура не будет успевать за клиентской базой. Не стоит так же забывать про организованность и порядок, про хороший – здоровый педантизм. Нельзя заниматься бизнесом с бардаком в голове, есть риск остаться без головы .

В общем случае система мониторинга состоит из 3х частей: сбор данных, обработка и уведомления. К слову, Nagios использует именно это концепцию, дополняя её разнообразными удобствами (визуальное отображение, расписания и т.д.). Уведомление по электронной почте, первое, что приходит в голову, однако оно не всегда оперативное. Самым оперативным уведомлением на сегодня является SMS сообщение. Отправку SMS сообщений можно организовать «на коленке» с помощью мобильного телефона подключенного к серверу.

Большинство телефонов представляют собой модем, к которому можно подключиться через интерфейс RS-232 (COM порт). Основным отличием мобильного телефона от обычного модема является поддержка расширенных AT команд. Эти команды используются для управления функциями специфичными для мобильного телефона, например, приёмом и отправкой коротких сообщений (SMS).

Традиционно считается, что для отправки SMS с ПК лучше всего подходят мобильные телефоны Siemens. Для реализации мобильных уведомлений, я запасся несколькими моделями: парочкой ME45 и одним A50. Первая неудача с телефонами Siemens ждала меня на этапе подсоединения к ПК. Оказывается, не все дата-кабели одинаковые.

Вот, этот например, определялся телефоном как гарнитура, и имел большое количество распаянных контактов внутри. Однако соединение по RS-232 установить с таким кабелем невозможно. Конечно, нельзя исключать, что мне попался бракованный экземпляр, но, как говорится, осадок то остался.

А вот так выглядит правильный дата-кабель доработанный мной. GND, RX, TX – все что нужно для работы по RS-232. Однако после доработки кабеля всплыла вторая проблема с телефонами Siemens. Все аппараты, имевшиеся у меня, выключались вскоре после того как аккумулятор был полностью заряжен. Т.е. их невозможно было эксплуатировать постоянно подключенными к сети. Вероятно это такой способ защиты аккумуляторов. Списать это на случайность не получится при всём желании.

В принципе, на этом можно было и остановить некрофильские эксперименты с аппаратурой фирмы Siemens, однако совесть потребовала идти до конца. Как я уже писал выше, для приёма и отправки текстовых сообщений через GSM модем используется специальный набор AT команд. Подробней об этом наборе можно почитать здесь. В общем случае отправка SMS выглядит вот так:

# picocom /dev/ttyS0
AT
OK
AT+CMGF=1
OK
AT+CMGS="+85291234567"
It is easy to send text messages.^Z

Если телефон поддерживает текстовый режим отправки SMS, или вот так:

# picocom /dev/ttyS0
AT
OK
AT+CMGS=42
07915892000000F0
01000B9158922143
65F7000021493A28
3D0795C3F33C88FE
06CDCB6E32885EC6
D341EDF27C1E3E97
E72E^Z

- если текстовый режим телефоном не поддерживается. Для активации текстового режима используется команда AT+CMGF=1, чтобы узнать, какие режимы поддерживаются Вашим телефоном, следует выполнить команду AT+CMGF=?.

Как вы уже догадались, третья проблема с телефонами Siemens заключалась в том, что ни один из имевшихся телефонов не поддерживал текстовый режим. Работая с PDU режимом Вы вынуждены генерировать сложную структуру содержащую в себе множество разнообразных параметров. Для работы с данной структурой Вам придётся либо изобрести велосипед и написать собственное API либо воспользоваться одной из существующих библиотек/программ (gsmlib, xgsmlib, Gammu и т.д.). Лучшим вариантом, на мой взгляд, является программа Gnokii

Намучавшись с сименсами, я решил опробовать устройство, которое изначально было бы рассчитано на постоянное использование в паре с ПК. Выбор мой пал на GSM/GPRS модем Teleofis RX201 (USB EDGE).

Приобрел я этот девайс за 3700 рублей, дороговато, по сравнению с рекламируемыми GPRS модемами от БиЛайн/Мегафон/МТС. По заверениям производителя (ООО КБ «Телеофис»), устройство произведено в России – мелочь, а приятно.

При подключении к ПК с linux, устройство определяется как «USB FTDI Serial Converter». Соответствующий модуль (ftdi_sio) автоматически создаёт файл устройства /dev/ttyUSBN. Этот файл вы можете использовать для связи с модемом, с помощью вашего любимого терминала (например picocom). Хочу обратить внимание на то, что устройство RX201 по умолчанию рассчитано на скорость 460800 кб/сек. Драйвер, идущий с Fedora 10 (ftdi_sio: v1.4.3) такую скорость не поддерживает. Что бы понизить скорость на модеме, к нему необходимо подключиться из альтернативной ОС и выполнить команду AT+IPR=115200&W.

Модем Teleofis RX201 отлично подружился с программой gnokii. Для отсылки sms с помощью gnokii сперва необходимо изменить конфигурационный файл /etc/gnokiirc. Вот пример рабочего конфига:

[global]
port = /dev/ttyUSB0
model = AT
initlength = default
connection = serial
use_locking = no
serial_baudrate = 115200

Обратите внимание на параметр use_locking, если Вы собираетесь рассылать SMS из Nagios, следует использовать use_locking = yes, что бы избежать конфликтов при рассылке уведомлений нескольким адресатам. Отправляется SMS очень просто:

echo 'ya sms-ko !' | gnokii --sendsms +79260000000

Вот и всё! SMS с текстом ‘ya sms-ko !’ будет отправлена на номер +79260000000.

Модем Teleofis RX201 работает уже почти месяц. В среднем в сутки отправляется около 10 сообщений. Никаких претензий и нареканий за этот небольшой срок не возникло, однако настораживает наличие модели Teleofis RX201-R единственное отличие которой – встроенный таймер перезагрузки.

• Nagios
• Short Message Service / SMS Tutorial
• Gnokii
• ООО КБ «Телеофис»

Лёгкость в установке и настройке Asterisk-a, привлекла большое количество низко квалифицированных IT-шников в сегмент IP-телефонии. Этим объясняются простые пароли для SIP логинов (или пароли, совпадающие с логином) и, соответственно, простота их подбора.

Наиболее заметными событиями в информационном поле стали: Публикация на сайте news.com.au о том, как маленькая Австралийская компания получила счёт на 120000$ после того как её корпоративную систему IP телефонии взломали и слили 11000 международных звонков за 46 часов и длиннющий тред в списке рассылки Asterisk-biz, начавшийся в начале февраля и закончившийся лишь к концу марта. Убыток во втором случае не столь впечатляющ, всего лишь 2000$. Однако последующее обсуждение имеет большую ценность.

Многие участники рассылки, используют программу fail2ban, которая умеет парсить лог-файлы различного формата и добавлять засветившиеся там IP адреса в iptables для блокирования. Подробную инструкцию как настроить Asterisk и fail2ban на совместную работу, можно прочитать здесь. Данная схема замечательна, заслуживают самого пристального внимания и оперативного внедрения. Однако я бы хотел обратить внимание на некоторые моменты:

Не доверяйте автоматике на 100%

Автоматической системе на основе fail2ban нельзя доверять на 100%. Дело в том, что использую SIP в Asterisk, мы используем протокол UDP. Реальность такова, что UDP пакеты с поддельным IP адресом отправителя без каких либо проблем проходят несколько автономных систем. Таким образом, автоматическая система на основе fail2ban может быть использована против Вас для отказа в обслуживании Ваших клиентов.

Автоматическую систему на основе fail2ban следует дополнить списком «белых» IP, которые будут игнорироваться при создании блокирующих правил iptables. Все результаты деятельности fail2ban следует регулярно проверять.

Сохраняйте IP адреса для каждого SIP звонка внутри CDR

Стандартные CDR Asterisk-а не содержат IP адреса, с которого был совершён звонок. Это легко исправить. Если Вы используете cdr_addon_mysql для хранения CDR в базе данных, добавьте поле в таблицу cdr:

ALTER TABLE cdr 
add COLUMN remote_signal_ip 
VARCHAR(16) NOT NULL DEFAULT ''

Теперь измените свой диалплан так, что бы cdr переменная remote_signal_ip инициализировалась перед исходящим звонком. Например, вот так:

context dialout {
    _X. => {
        Noop();
        Set(CDR(remote_signal_ip)=${SIPCHANINFO(recvip)});
        Dial(SIP/myprovider/${EXTEN});
    }
}

Вот и всё! Функция SIPCHANINFO(recvip) вернёт IP адрес, с которого клиент производит вызов, а по окончании вызова модуль cdr_addon_mysql сохранит все переменные, имена которых совпадают с названиями колонок в таблице cdr.

Сохранение IP адреса для каждого звонка открывает большой потенциал для изучения миграции клиентов по IP сетям, выявления приоритетных партнёров для пиринга IP трафиком, решения проблем с утечками паролей и много чего ещё.

Используйте встроенные access-листы

chan_sip и некоторые другие модули сетевых протоколов имеют поддержку списков доступа в зачаточном состоянии. С помощью директив permit и deny вы можете ограничивать возможные IP адреса для каждого SIP аккаунта. Если у вас есть офисные номера, работающие в интранете, не ленитесь, пропишите для каждого аккаунта

deny=0.0.0.0/0.0.0.0
permit=192.168.1.0/255.255.255.0

Возможно, это спасёт Вас от судьбы той компании из Австралии.

Подходите к вопросу творчески: комбинируйте, изобретайте!

Не стоит сидеть, сложа руки и ждать, пока появятся проблемы. Лучше потратить немного усилий на превентивные меры, что бы обезопасить себя от форс-мажора. В вопросе безопасности, надо всегда быть на шаг впереди. Анализируйте свой трафик – каждый всплеск мг/мн трафика должен быть тщательно расследован. Не работайте по шаблонам – комбинируйте и изобретайте. Например, можно написать скрипт, который раз в месяц анализирует IP адреса из вашей таблицы cdr, и автоматически генерирует списки доступа (acess-list) для тех аккаунтов, чьи IP не менялись за прошедший месяц. Будьте креативными!

• Fail2ban
• Fail2Ban (with iptables) And Asterisk
• Small business gets $120,000 phone bill after hackers attack VoIP phone
• [asterisk-biz] PBX got Hacked

FCC, федеральная комиссия по связи, имеет замечательный сайт, посвященный различным аспектам CALEA. Фактически, это настольная энциклопедия для любого, кто хочет предоставлять услуги резидентам США. Сайт великолепно структурирован. Настоятельно рекомендую к изучению всем, кто связан с предоставлением услуг связи.

• СОРМ
• CALEA
• FCC: Communications Assistance for Law Enforcement Act
• Федеральный закон N 126-ФЗ «О связи»
• Федеральный закон N 144-ФЗ «Об оперативно-розыскной деятельности»

На сегодняшний день, БД проекта содержит уже более 10 операторов. А если воспользоваться поиском, можно найти интересные цены, так, например самой низкой ценой за минуту Москвы является 0.006$ – 17.5 копеек по курсу на сегодня. Это существенно ниже средней цены на межоператорском рынке Москвы.

Не смотря на то, что проекту еще меньше недели, я позволю себе указать некоторые недостатки:

• Отсутствие мультивалютности. Перед добавлением в БД проекта, все цены должны быть приведены к американским долларам.
• Не учитывается шаг округления (посекундно, поминутно и т.п.)
• Не указываются параметры маршрута ASR, ACD, проходят ли АОНы.
• Отсутствует API для встраивания функционала данного ресурса в собственные приложения (например AGI скрипт для Asterisk, вычисляющий путь звонка с минимальной ценой.

Кроме того, существует опасность появления нечистоплотных операторов, меняющих свои тарифы таким образом, что бы цены, попадающие в рейтинг, отличались от реальных (эффективных) цен, по которым услуги будут доступны большинству пользователей. Однако, не смотря на недостатки, ресурс обещает быть очень интересным и полезным для конечных потребителей и очень маленьких операторов IP телефонии. Я с удовольствием добавил этот ресурс в свои закладки.