Студия Йэдин. Прямой эфир.

Сколько стоит сайт построить?

nospam@example.com (Алексей Фёдоров) — Thu, 28 Aug 2008 15:14:00 +0400

Из чего исходят различные студии web-дизайна при определении стоимости разработки сайта? Как не продешевить разработчикам? Как не переплачивать заказчикам?

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

После нескольких лет работы в сфере сайтостроительства у меня сформировалось собственное видение ценообразования на свои услуги. И сейчас я постараюсь изложить вам это самое видение.

Итак, чтобы понять, из чего складывается цена, надо сначала определить, из чего состоит разработка сайта. Сразу оговорюсь: в этой статье не будет речи о сайтах, выполненых целиком на "тяжелых" технологиях, таких как Flash или Java.

Этапы жизни сайта

Проектирование сайта (разработка технического задания):
- Анализ потребностей заказчика
- Разработка структуры сайта
- Определение требований к дизайну сайта
- Определение требований к системе управления сайтом
- Определение требований к графическому и текстовому наполнению сайта (контенту)
- Определение общих технических требований к системе
- Выбор эффективного доменного имени

Разработка макетов дизайна

Разработка системы управления

Верстка макетов дизайна

Выбор хостинг-провайдера

Заключение договора хостинга и регистрация доменного имени

Установка и настройка системы управления (в том числе, настройка шаблонов дизайна и подготовка структуры)

Написание или обработка контента сайта

Заполнение структуры сайта контентом

Полное тестирование и сдача готовой системы заказчику

Поддержка сайта и консультирование заказчика по дальнейшему развитию системы

Продвижение сайта в сети

Согласно такому плану заказчик получит не просто сайт, соответствующий его требованиям, а полноценное интернет-представительство, которое будет эффективно способствовать развитию бизнеса заказчика или популяризации его деятельности посредством сети Интернет.

Собственно разработка сайта заключена в этапах 1-4 и 7-10, с этим мы определились. Теперь посмотрим, где же здесь деньги, и что сколько стоит.

Я привык вычислять стоимость работ по трудозатратам. По опыту мне кажется это наиболее эффективным и точным способом расчета. Давайте сначала оценим, какие же трудозатраты потребуются на каждый этап разработки сайта.

Первый этап (проектирование сайта) во многом зависит от самого заказчика и от опыта менеджера проектов, который составляет техническое задание, и может потребовать от 10 до 40 часов работы проектировщика (включая контроль выполнения работ по проекту).

Второй этап у опытного дизайнера займёт от 4 до 24 часов, в зависимости от сложности графического оформления и наличия необходимого клип-арта.

Пожалуй, самым трудоёмким этапом является разработка системы управления, но почти у каждой зрелой web-студии уже есть готовая система собственного производства, доработка которой под нужды конкретного заказчика не требует больших трудозатрат. И в таком случае этот этап вряд ли займёт больше 80 человекочасов.

Следующий этап - верстка макетов дизайна у опытного html-верстальщика занимает максимум до 8 часов на макет, как правило, эта цифра колеблется где-то в районе 4 часов.

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

Этап установки и настройки системы управления в среднем может занять до 20 человекочасов, в зависимости от сложности структуры сайта и от удобства средств настройки самой системы управления.

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

В случае предоставления материалов заказчиком обработка (в том числе и расстановка всей необходимой разметки) контента сайта, скажем, страниц на 100 займёт порядка 40 часов редактора текстов и почти столько же времени редактора иллюстраций. Если наполнение необходимо создавать силами студии, то трудозатраты могут быть в два-три раза больше.

Этап заполнения подготовленной структуры сайта опять же зависит от удобства инструментов настройки системы управления и объёма контента. Если взять те же 100 страниц, то заполнение может занять до 8 часов.

Этап тестирования должен проводиться очень аккуратно, следует обращать внимание на корректную работу всех страниц и скриптов сайта. Тем не менее, работа эта не слишком длительная и в среднем может занять около одного рабочего дня, т.е. 8 часов. Здесь же следует учесть необходимость исправления выявленных ошибок - на эту процедуру положим ещё 8 часов.

Хочу отметить, что в этой статье я не пишу о том, сколько времени будет длиться разработка сайта от начала до конца, так как некоторые этапы разработки могут идти параллельно.

Теперь, когда мы определились с трудозатратами на этапах разработки сайта, необходимо распределить эти этапы между исполнителями. Давайте посмотрим, какие специалисты нам потребуются для выполнения всех работ по созданию веб-сайта: руководитель проекта (он же проектировщик), дизайнеры, программисты, верстальщики, технические редакторы, журналисты, художники, фотографы, тестировщики. Дальше надо определиться со ставками (окладами) всех этих специалистов. Тут надо учитывать географическое положение студии, так как в Москве и С.-Петербурге это будут одни цифры, а, например, в Туле или Пензе - совсем другие. Я буду ориентироваться по Москве (вряд ли где-то в России разработка будет стоить дороже). Цифры я взял из общедоступных интернет-бирж труда.

Итак, оклад руководителя проектов - в среднем около 70000 рублей в месяц, дизайнеров, художников, журналистов и программистов - примерно 40000 рублей, фотографов, верстальщиков, технических редакторов и тестировщиков - порядка 30000 рублей. Месяц работы сотрудника составляет в среднем 21 рабочий день, что эквивалентно 168 часам. Отсюда мы можем расчитать стоимость часа работы сотрудников: руководитель проектов - 417 рублей, дизайнеры, художники, журналисты и программисты - 238 рублей, фотографы, верстальщики, технические редакторы и тестировщики - 179 рублей.

Теперь посмотрим, какие трудозатраты на каких специалистов приходятся:

Руководитель проектов - от 10 до 40 часов, что соответствует 4170 - 16680 рублей

Дизайнер - от 4 до 24 часов (от 952 до 5712 рублей)

Программисты - от 24 до 100 часов (от 5712 до 23800 рублей)

Верстальщик - от 4 до 8 часов (от 716 до 1432 рублей)

Технический редактор - в нашем примере (100 страниц) до 48 часов (до 8592 рублей)

Художник - в нашем примере (без прорисовки нового контента) до 40 часов (до 9520 рублей)

Тестировщики - в среднем 8 часов (1432 рубля)

В этих подсчетах следует ещё не забывать о налогах, работе бухгалтерии и "интересе" всей студии как компании. Все эти "накрутки" в зависимости от организационной формы студии и схемы налогообложения могут достигать грубо 50% от получившейся суммы. В итоге несложных арифметических операций мы получили некий диапазон цен (округленно от 46000 до 100000 рублей), который, в свою очередь, может колебаться в зависимости от объемов контента и сложности системы управления, каких-то очень специфических требований заказчика и т.д. и т.п.

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

Отдельными пунктами стоит отметить услуги хостинга, регистрации и продления доменных имен, поддержки сайта и продвижения сайта.

Услуги хостинга, в зависимости от технических требований проекта, могут стоить в среднем от 1000 до 15000 рублей в год. Стоимость регистрации и продления доменного имени зависит от зоны - для зоны .ru это грубо 600 рублей и 450 рублей соответственно.

Стоимость поддержки сайта, как правило, зависит от условий контракта, сложности сайта, и может составлять от 10 до 50% стоимости разработки сайта в год.

А стоимость раскрутки сайта будет сильно зависеть от тематической конкуренции сайта в интернете, и разброс цен здесь может быть очень велик. Правда, сразу хочу заметить, что редкой студии будет интересен заказ на раскрутку сайта менее, чем на 15000 рублей в месяц.

Исходя из всего вышеперечисленного можно составить более-менее полную картину расходов на создание, поддержку и развитие полноценного интернет-представительства. Ещё раз подчеркну, что всё написанное в этой статье - лишь моё видение и не претендует на абсолютную истину. Кто-то может посчитать иначе - например, воспользоваться совсем другими методами определения стоимости разработки.

Как создать многоязычный сайт на Drupal

nospam@example.com (Сергей Шаховский) — Wed, 30 Jan 2008 14:18:23 +0300

В последние годы получила активное развитие система управления контентом сайта Drupal. Несмотря на то, что на первый взгляд система может показаться крайне сложной, после более близкого знакомства с ней становится понятно, что она имеет весьма грамотную внутреннюю организацию, что делает её очень гибкой и удобной. В частности, это относится и к созданию многоязычных сайтов. Как и в большинстве других систем, изначально в Drupal нет поддержки контента на нескольких языках (но, стоит отдать должное, в нём есть крайне продуманная система локализации). Решить эту проблему помогает модуль интернационализации i18n, который очень прост в настройке и предоставляет все необходимые для этого средства. При этом, что важно для занятых людей или людей, не обладающих навыками программирования, для интернационализации вашего сайта не нужно будет исправить не единой строчки кода! А это действительно прогресс. Я уверен, в этом меня поддержат люди, реализовывавшие подобную функцию на других CMS.
Сегодня я расскажу вам, как за четверть часа сделать ваш сайт многоязычным. Для этого вам потребуется установленная на web-сервере система Drupal и модуль i18n.
Шаг 1. Установка модуля
Для того, чтобы установить модуль, скопируйте содержимое архива (папку i18n) в папку \sites\all\modules\ вашего сайта.
Шаг 2. Включение модулей
Зайдите в меню Administer > Site building > Modules и включите модули Locale, Internationalization и Translation. Это базовые модули, необходимые для создания многоязычного сайта. Если вы хотите, чтобы на различных языках показывались блоки и меню, или содержимое модулей views и profile, включите соответствующие модули в разделе Multilingual – i18n.
Шаг 3. Настройка модулей
Настройка модуля интернационализации осуществляется в меню Administer > Site Configuration > Multilingual system. Здесь, по сути, настраивать ничего не нужно, потому что параметры, назначенные по умолчанию, прекрасно подойдут для работы. Возможно, вы захотите включить функцию автоматического определения языка браузера для главной страницы и страниц, в адресе которых нет префикса, указывающего язык. Здесь же вы можете указать путь к иконкам языков, если вас не устраивают стандартные, и их размер.
Шаг 4. Определение языков
После включения модуля интернационализации на странице настройки языков (Administer > Site Configuration > Localization) добавляется две колонки – текстовое поле Native name и флажок RTL. Первый параметр определяет название языка на самом языке, а второй – указывает, что написание в языке производится справа налево. Последний параметр не будет играть никакой роли, если он не обрабатывается темой.
Например, если вы желаете создать англо-русско-немецкий сайт, добавьте к установленному английскому языку русский и немецкий языки, нажав на ссылку Add language. В таблице языки должны иметь следующие имена (в полях English name и Native name соответственно): русский язык – «Russian» и «Русский», немецкий – «German» и «Deutsch». Не забудьте включить языки, установив галочки в полях «Enabled», и выбрать язык по умолчанию в поле «Default».
Шаг 5. Включение блока выбора языков
Зайдите в меню Administer > Site building > Blocks и установите положение блока Language.
Шаг 6. Включение многоязычности контента
После установки модуля интернационализации на каждой странице настройки типа контента появился блок Multilingual support, который позволяет включить или отключить поддержку многоязычности контента этого типа. Расширенный режим поддержки (Extended) обозначает, что вы можете создавать контент этого типа для всех языков, а не только для разрешенных. Так, например, сайт может быть англо-русско-немецким, но содержать отдельные статьи на французском или любом другом языке.
Всё! Теперь у вас есть сайт, способный работать на нескольких языках. Остаётся только добавить нужные материалы и перевести их на все языки сайта. Этот процесс в связке Drupal и модуля i18n происходит весьма логично, при этом поддерживается возможность управления переводом несколькими пользователями. Для того, чтобы добавить материалы на разных языках:
1. Создайте материал на основном языке сайта. Выберите язык в поле Language, если вы используете систему контроля процесса перевода, то выберите в поле Translation workflow значение Source content (to be translated).
2. Сохраните документ
3. Перейдите на закладку Translations, выберите язык перевода материала и нажмите Create translation. Если вы используете систему контроля процесса перевода, то выберите в поле Translation workflow значение Translated content.
4. Сохраните документ. Многоязычная страница готова!
Повторите перечисленные выше шаги для добавления остальных страниц.
В этой статье я перечислил лишь основные возможности пакета i18n. Информацию о расширенных возможностях этого пакета можно получить на странице проекта Internationalization. На портале drupal.org можно загрузить саму систему управления контентом Drupal, а также дополнительные модули к ней, узнать о последних новинках в сообществе Drupal и, возможно, найти решение для вашего сайта.

Время переходить на IP

nospam@example.com (Алексей Фёдоров) — Fri, 30 Nov 2007 15:29:00 +0300

Речь пойдёт о перспективном современном веянии в российских телекоммуникациях (или даже "инфокоммуникациях", как сейчас модно говорить) - переводе традиционной телефонной связи на базу IP. Сейчас многие телекоммуникационные вендоры приходят к необходимости создания переходных решений. Кто-то приходит со стороны IP, кто-то со стороны TDM. И многие традиционные операторы ощущают необходимость миграции в IP.
Но обо всём по порядку...

"Московскому телефону исполнилось 125 лет!" - гласят надписи на счетах самой крупной (до недавних пор единственной) в Москве телефонной компании. Задумайтесь, уже примерно полтора века развивается в России и во всём мире телефонная связь!
Если обратиться к началам этого развития, можно вспомнить и телефоны, связанные каждый с каждым, и ручные телефонные станции, и первые шаговые АТС. Дальше, с увеличением популярности и потребности в телефонной связи появились декадно-шаговые и координатные АТС с увеличенной ёмкостью и производительностью. С развитием техники и, в частности, электроники сравнительно недавно появились различные электронные и цифровые телефонные станции. Параллельно с процессом развития систем коммутации развивались и технологии связи между станциями и абонентами. Линии связи прошли путь развития от воздушных проводов и подвесных кабелей до волоконно-оптических соединительных линий. Декадная импульсная абонентская и межстанционная сигнализация сменилась аналоговой двухтональной многочастотной (DTMF) и цифровой (DSS, CCS) сигнализацией.
Примерно в то же время, когда появились первые цифровые коммутационные станции, начали своё развитие и сети передачи данных общего пользования (СПД ОП). И этот процесс оказался более стремительным и бурным, чем развитие телефонных сетей. Сети эти сейчас тесно связаны, переплетаются и накладываются одна на другую.
За свою сравнительно короткую историю СПД претерпевали многочисленные смены стандартов, протоколов сигнализации, физических носителей и т.д. Сейчас же лидирующую позицию практически повсеместно заняло семейство протоколов IP (Internet Protocol) вне зависимости от физической среды, а получившуюся универсальную всемирную СПД принято называть просто Internet.
А какая же нынче обстановка сложилась в российских телефонных сетях и СПД? Налицо два процесса: повсеместное распространение IP-сетей и постепенный выход из строя старой коммутационной базы в телефонных сетях. С одной стороны, стремительный рост спроса на доступ в Интернет заставляет операторов строить собственные СПД (IP-сети), а с другой стороны, выход из строя старого телефонного коммутационного оборудования заставляет операторов заменять выработавшие свой ресурс старые станции новыми цифровыми и, соответственно, обновлять телефонные сети. И в результате у многих операторов складывается ситуация, когда параллельно функционируют две сети: IP-сеть и телефонная сеть (TDM).
Современные технологии предлагают операторам несколько возможных путей развития. Как уже неоднократно говорил и писал И.О. Масленников (директор по развитию бизнеса компании МФИ Софт), можно покупать простенькие, сравнительно недорогие цифровые TDM-коммутаторы взамен выходящих из строя, но производителей таких станций осталось немного; можно заменить целиком всю сеть и построить IMS, что наверняка влетит оператору в копеечку; а можно покупать телефонные коммутаторы построенные на базе IP.
Кроме своей популярности, чем же так привлекательны могут быть IP-коммуникации для телефонных операторов? Есть несколько интересных особенностей. Например, дешевизна инсталляции и эксплуатации IP-сетей по сравнению с ТфОП, простота разработки и внедрения новых голосовых сервисов и услуг, интеграции с различными веб-сервисами. Как сказал Алексей Найдёнов (генеральный директор ITooLabs) на 12-й конференции по IP-телефонии и IP-коммуникациям: "С голосом в IP-пакете я могу сделать всё, что угодно!". Чем он, собственно, успешно и занимается, а также этим ещё более успешно занимаются такие гиганты как Google, Skype, Yahoo! и многие другие.
Сейчас операторы в большинстве своём предоставляют лишь услугу базового вызова и постепенно становятся поставщиками транспорта для IP-коммуникаций, а большую часть интересных потребителю услуг и сервисов предоставляют сторонние организации. Переводя же свои сети на базу IP и внедряя современные услуги и сервисы на своей собственной сети, оператор может сохранять свои позиции, оставаясь в мейнстриме, в то время как клиент не будет бродить по Интернету в поисках интересных ему сервисов у сторонних провайдеров, а будет лоялен к своему оператору, у которого есть все необходимые сервисы.
Таким образом, меняя устаревшие и вышедшие из строя TDM-коммутаторы на IP-телефонные коммутаторы, оператор может не только сохранять большую часть своей TDM-инфраструктуры, но и заинтересовывать своих клиентов новыми услугами и сервисами. А уж решений на нашем и зарубежном рынке для такого постепенного перехода на IP-коммуникации сейчас довольно много. В качестве примера могу привести "РТУ" от МФИ Софт, NGN решения от НТЦ Протей, "Сапфир" от ФГУП ЛОНИИС и т.д. "Ищущий да обрящет!"

Дополнительные услуги связи

nospam@example.com (Алексей Фёдоров) — Sat, 16 Jun 2007 22:01:07 +0400

Интересное наблюдение - очень небольшой процент абонентов городских телефонных станций подозревает о существовании дополнительных видов обслуживания (ДВО) в телефонных сетях общего пользования (ТфОП). Ещё меньше людей знает о возможностях АТС, к которой подключен их домашний телефон. Я сам, занимаясь тестированием и настройкой оборудования для узлов местной связи (по сути АТС) до сегодняшнего дня даже не задавался таким вопросом.
С другой стороны, многие наверняка знают, что в мобильной связи есть такие понятия, как "удержание вызова", "переадресация", "конференц-связь". А уж о том, что эти возможности есть у офисных АТС (традиционных УПАТС или построенных на базе IP-сетей IP-PBX) знает почти каждый современный офисный работник.
Эти два факта как-то не стыкуются, не находите? А почему? И что же такое ДВО и кому это надо в обычных городских телефонных сетях?
Ответ на первый вопрос довольно простой - мы просто привыкли к тому, что наши городские телефонные станции не умеют ничего кроме как соединить нас с другим абонентом. Однако технологии развиваются, появились цифровые АТС и станции, построенные на IP-сетях.

Какие именно услуги появились с внедрением новых технологий? Процитирую описание с сайта МГТС:

Горячая линия (соединение без набора номера с отсроченной маршрутизацией) позволяет устанавливать соединение с заранее заданным номером. Для соединения вызывающему абоненту не требуется набирать номер. Если абонент поднимет трубку и в течение 7-10 секунд не производит набора номера, начинается автоматический набор запрограммированного номера.

Переадресация входящих вызовов позволяет перенаправить входящие звонки, поступающие на телефон абонента, на любой указанный абонентом номер, назначенный для приема переадресованных вызовов: городской, междугородный, международный или мобильный. Существует три вида переадресации: безусловная (все поступающие звонки немедленно переадресовываются на другой номер); при занятости (звонок переадресовывается на другой номер, если телефон абонента занят); при неответе (осуществляется переадресация на другой номер, если в течение 15-20 секунд абонент не отвечает на звонок).

Конференц-связь (трехсторонняя конференция) позволяет абоненту участвовать в соединении с двумя абонентами одновременно.

Ожидание и Удержание вызова с уведомлением о поступлении нового вызова позволяет во время телефонного разговора с одним абонентом услышать сигнал о поступлении вызова от второго абонента. При этом можно переключиться на второго абонента, поговорить с ним и, не кладя трубку, снова переключиться на первого.

"Ну и кому всё это надо?" - спросите вы.
Навскидку могу предположить несколько ситуаций, в которых эти услуги могут быть полезными.
Например, у вас есть родственник с ограниченными возможностями (очень плохое зрение, вообще очень слабое здоровье или ещё какая другая неприятность), живущий где-то отдельно. Вы приезжаете к нему, подключаете услугу "горячая линия", и программируете станцию на автоматический набор вашего домашнего или мобильного номера. Теперь, не дай бог что случится, - вашему родственнику достаточно снять трубку, и станция сама наберёт ваш номер... И это, конечно, не единственный вариант использования данной услуги.

Или вот другая ситуация. Допустим, вы очень не любите пропускать звонки, но, понятное дело, не можете постоянно сидеть рядом со своим домашним телефоном, да и не всегда ваш телефон свободен. В таких случаях вам помогут услуги "переадресация вызова", "ожидание вызова" и "удержание вызова". Аккуратно настроив эти функции, вы наверняка не пропустите важный звонок.

Большинство дополнительных услуг будет весьма полезно, если у вас офис дома. Тут уж пожалуй никак не обойтись без удержания вызова или конференц-связи.

А ещё, например, домохозяйки, любящие посмотреть сериалы, а потом обсудить все подробности с подругами. Думаю, многие догадаются, какая услуга им будет очень кстати.

На мой взгляд, уже неплохой набор возможных применений. Думаю, пора нам заполнять пробел в своём собственном сознании и начинать продвигать услуги в массы.
И цена вопроса не столь уж велика по нынешним меркам - в пределах 100 рублей в месяц за все перечисленные услуги вместе. Правда, ваш телефонный аппарат должен поддерживать тональный режим набора, а такой пока есть далеко не в каждом доме.
Как говорится, "о возможности подключения дополнительных услуг спрашивайте в своём местном узле связи".

P.S. Я бы сам подключил себе услуги ожидания и удержания вызова и трехсторонней конференции, но, как я сегодня выяснил, наша районная АТС пока не предоставляет дополнительных услуг.

Повышение PR через социальные сети

nospam@example.com (Сергей Шаховский) — Sat, 26 May 2007 18:51:24 +0400

Сегодня я расскажу вам, как использовать одну из социальных сетей (stumbleupon.com) для повышения ценности вашего сайта в глазах поисковых систем. Итак, перед нами стоит задача - увеличить количество ссылок на наш сайт, дабы донести нашу информацию до как можно большего числа посетителей. Для этой благой цели мы воспользуемся двумя сервисами - собственно stumbleupon.com, и stumblexchange.com. Первый сервис позволяет вам находить в волнах интернета хорошие страницы и извещать об этом других пользователей сервиса. Поэтому зарегистрируемся на сервисе и получим примерно вот такую страничку. Скачайте предложенный плагин к вашему браузеру. Теперь проверим работу этого плагина - зайдем на сайт, который хотим донести до масс, и нажмем на кнопочку "Like it!".
Если такого сайта еще никто не нашел (а если это ваш новый сайт, то это, скорее всего, будет именно так), то система предложит вам ввести его описание, дабы позволить узреть ваше чадо собратьям по сервису. Стоит предостеречь вас от использования в описании русских символов. Увы, делать этого нельзя. Если вы не знаете английского языка, напишите транслитом. Итак, система готова к работе.
И что же в ней хорошего, спросите вы? Чем она лучше отечественных систем, того же доброго бобра? Да, в общем, ничем. За небольшим исключением. И это исключение - система stumblexchange.com. Эта система позволит вам очень быстро найти множество друзей в stubleupon и повысить значимость вашей страницы. Для того, чтобы сделать это, нужно, во-первых, зарегистрироваться в системе. Во время регистрации вас спросят ваше имя в системе stumbleupon (необходимо указывать с сохранением регистра), и какой сайт вы желаете раскрутить. На сегодняшний день поддерживается раскрутка только одного сайта, однако создатели думают над увеличением их числа.
Регистрация завершена, пора приступать к раскрутке. Для этого жмем ссылку Stumble в располагающемся слева меню. Появится таблица с четырьмя полями:
- SU Username (имя пользователя в системе stumbleupon),
- RP (количество очков репутации, т.е. сайтов, которые "отстамблил" пользователь. Предполагается, что, чем выше это число, тем больше шансов, что пользователь ответит вам взаимностью),
- Stumble Site (сайт, предлагаемый пользователем),
- Don't Show Again (ссылка, которую стоит нажать, если сайт пользователя вам не понравился и вы не хотите его больше видеть в списке).
Первая строка в таблице - спонсорская, переходить на нее не обязательно, но желательно для поддержания сервиса. Порядок работы таков:
1. Нажимаем на ссылку в первой колонке, соответствующую имени пользователя (все ссылки будут открываться в новом окне);
2. В правой части профиля пользователя нажимаем кнопку Add as friend и закрываем окно;
3. Нажимаем ссылку в третьей колонке, в открывшемся окне с сайтом пользователя нажимаем кнопку Like it (конечно же, если сайт вам понравился ), после чего картинка руки изменит свой цвет на зеленый. Закрываем окно (или наслаждаемся просмотром понравившегося сайта);
4. Повторяем действия 1-3 для всех сайтов на странице Stumble;
5. Нажимаем кнопку Check. Сервис проверит, действительно ли вы сделали всё правильно, и присвоит вам RP в соответствии с количеством отмеченных сайтов, а также разместит ваши ссылки в разделе Waiting для пользователей, которым вы помогли. Можно нажимать кнопку stumble more для появления следующего списка.
Теперь вам остается ждать, пока другие пользователи добавят вас в друзья и добавят ваш сайт в список понравившихся, передавая сайту и профилю в stumbleupon немножечко своего PR.
Не забывайте иногда заходить в раздел Waiting и отмечать пользователей, которые занесли вас в список друзей.

Память в Firefox

nospam@example.com (Сергей Шаховский) — Tue, 15 May 2007 17:01:40 +0400

Многим знаком и любим браузер Mozilla Firefox. Последним, наверное, знакома и ситуация, когда в фоксе открыто несколько десятков закладок и браузер начинает несколько подтормаживать. Запустите диспетчер задач и посмотрите, сколько памяти уже съел браузер. Впечатляет? Эту ситуацию можно исправить средствами самого браузера. Для этого достаточно открыть список параметров конфигурации (открыть новую закладку и ввести адрес about:config), добавить туда новый двоичный параметр (нажатие правой кнопки мыши на списке - New - Boolean). В открывшемся диалоговом окне указываем название параметра config.trim_on_minimize, нажимаем Ok, в следующем окне выбираем значение параметра - true. Настройка закончена, для того, чтобы она вступила в силу достаточно закрыть браузер и запустить его снова. Теперь, когда вам покажется, что браузер работает медленно, просто сверните его в панель задач и разверните обратно. Особенно впечатляют показания диспетчера задач при выполнении этого действия.
Удачного серфинга!

Расчёт объёма голосового трафика переговорного пункта

nospam@example.com (Алексей Фёдоров) — Fri, 16 Mar 2007 01:50:00 +0300

На форуме Ринотела как-то был задан вопрос про объём трафика для переговорного пункта на 10 кабинок. Хочу частично ответить здесь на этот вопрос. Если точнее, то приведу технику и примеры расчёта объёма среднего месячного голосового трафика при работе на разных кодеках. Сигнальный трафик я не учитываю, но следует помнить, что он тоже может составлять некоторую долю в общем трафике переговорного пункта...

Для начала небольшая табличка полос пропускания для разных кодеков:

Кодек	Полоса (битрейт), кбит/с
G.711 (A-law,u-law)	64
G.723.1	6,3
G.723.1	5,3
G.726	16
	24
	32
	40
G.729 (A,B)	8
GSM (full rate)	13
iLBC (30 мс/пакет)	13,33
iLBC (20 мс/пакет)	15,2

Исходя из этой таблички, можно вычислить полезный объём одного голосового пакета, т.е. тот объём, который несёт в себе собственно голосовую информацию.
Полезный объём пакета [байт] = длительность пакета [мс] × битрейт кодека [кбит/с] / 8 бит

Кодек	Типичная длительность пакета, мс	Объём пакета, байт
G.711 (A-law,u-law)	20	160
G.723.1 6,3 кбит/с	30	24
G.723.1 5,3 кбит/с	30	20
G.726 16 кбит/с	20	40
G.726 24 кбит/с		60
G.726 32 кбит/с		80
G.726 40 кбит/с		100
G.729 (A,B)	20	20
GSM (full rate)	22,5	37
iLBC 13,33 кбит/с	30	50
iLBC 15,2 кбит/с	20	38

Чтобы посчитать объём голосового трафика, надо ещё посчитать количество пакетов, необходимых для передачи одной секунды голоса и учесть заголовки пакетов, которые состоят из заголовка RTP, заголовка UDP, IP и Ethernet:

RTP - 12 байт,
UDP - 8 байт,
IP - 20 байт,
Ethernet - 18 байт.

Общий объём заголовков - 58 байт. Прибавив эту величину к полезному объёму пакета, получим фактический объём одного пакета голоса.
Фактический объём пакета [байт] = полезный объём пакета [байт] + объём заголовков [байт]
Количество пакетов в секунду рассчитывается исходя из битрейта кодека и полезного объёма пакета:
Количество пакетов в секунду = битрейт кодека [кбит/с] / (полезный объём пакета [байт] × 8 бит)

Кодек	Фактический объём пакета, байт	Количество пакетов в секунду
G.711 (A-law,u-law)	218	50
G.723.1 6,3 кбит/с	82	33
G.723.1 5,3 кбит/с	78	33
G.726 16 кбит/с	98	50
G.726 24 кбит/с	118	50
G.726 32 кбит/с	138	50
G.726 40 кбит/с	158	50
G.729 (A,B)	78	50
GSM (full rate)	95	44
iLBC 13,33 кбит/с	108	33
iLBC 15,2 кбит/с	96	50

Дальше уже несложно посчитать реальную полосу, необходимую под голос и объёмы трафика.
Полоса пропускания для одного звонка [кбит/с] = фактический объём пакета × 8 бит × количество пакетов в секунду / 1000

Кодек	Полоса для одного звонка, кбит/с
G.711 (A-law,u-law)	87,2
G.723.1	21,248
G.723.1	20,592
G.726	39,2
	47,2
	55,2
	63,2
G.729 (A,B)	31,2
GSM (full rate)	33,44
iLBC (30 мс/пакет)	28,512
iLBC (20 мс/пакет)	38,4

Таким образом, в самом худшем случае (работа по кодеку G.711), реальная полоса пропускания, требуемая для одного звонка - 87,2кбит/с = 10900 байт/сек.
Возьму в качестве примера случай с переговорным пунктом из темы на форуме (10 переговорных кабинок) и проведу расчёт месячного трафика для двух кодеков: G.711 и G.729. Перед расчётом сделаю следующие исходные допущения:

Пиковая нагрузка - 10 одновременных звонков,
Среднесуточная нагрузка на переговорный пункт - 4000 минут.

Тогда в пике нагрузки при работе на кодеке G.711 для одного только голоса потребуется полоса пропускания 872 кбит/с, а при работе на кодеке G.729 - 312 кбит/с. Средний суточный трафик составит (количество дней в месяце × среднесуточная нагрузка, минут × 60 секунд × фактический объём пакета, байт × количество пакетов в секунду):

На кодеке G.711 - 30 × 4000 × 60 × 218 × 50 = 78480000000 байт = 73,1 Гбайт,
На кодеке G.729 - 30 × 4000 × 60 × 78 × 50 = 28080000000 байт = 26,15 Гбайт.

В этих моих расчётах не учитывается возможное использование технологии VAD (Voice Activity Detection), которая может дать экономию от 50 до 70%.

P.S. Расчёты основаны преимущественно на материалах сайта Cisco Systems, Inc.

Студия Лебедева зажигает!

nospam@example.com (Алексей Фёдоров) — Thu, 08 Mar 2007 02:35:00 +0300

Почитывал сегодня блог Леонида Лукина (местами весьма полезный ресурс, должен сказать). Глубоко в архивах увидел запись про студию Лебедева. Про то, что html-код на сайте студии не валидный, я давно знал, но чисто по инерции ткнулся в ссылку на валидатор... Результат меня позабавил - валидатор увидел лишь следующий код:<N.B.>Лучший валидатор - это браузер</N.B.>Уже интересно. Дальше - больше...
Меня, естественно, понесло собственно на сайт студии, чтобы глянуть на код своими глазами. Открываю и вижу... На первой странице кода только одна строчка в самом верху:Опять думаю - забавно. Ну да ладно, бывает. Лебедев - мальчик не маленький и вполне может писать в чём угодно.
Листаю дальше, и где-то посерёдке страницы среди прочего кода вижу такой комментарий:

<!-- А как ты называешь то, на что сейчас смотришь? Сорс? Сорец? Исходник? Бнопня? Код? -->

Вот это меня уже повеселило, я даже задумался на секунду - а действительно, как?
Однако, веселее всего было, когда я долистал до конца страницы. Я б, наверное, заржал в голос, если б не полтретьего ночи. А комментарий там такой:

<!-- А ты знаешь, сколько идиотов пишут мне письма, что наверху написано про FrontPage? -->

Весёлые ребята там работают, чесслово.

ICQ vs XMPP (Jabber)

nospam@example.com (Алексей Фёдоров) — Wed, 03 Jan 2007 02:28:32 +0300

На тему преимуществ и недостатков различных протоколов мгновенных сообщений (IM) написано уже огромное количество статей. Я же хочу резюмировать все найденные мной материалы и объяснить, почему я собираюсь в ближайшее время отказаться от использования ICQ в пользу XMPP... Начну с того, что меня в последнее время стало сильно напрягать в ICQ:

засилие спама,
незащищенность протокола (штатными средствами),
учащение случаев воровста UIN'ов (вытекает из п.2),
обилие рекламных блоков в стандартных клиентах.

Казалось бы, не такие уж великие проблемы, ведь всё это можно обойти тем или иным способом. Например, использовать нестандартный клиент типа Miranda, QIP, Trillian и т.п., делать более стойкие пароли (пароль, кстати, ограничен по длине 8-ю символами, что тоже не добавляет безопасности протоколу). Нестандартным клиентом можно отсечь большую часть спама, защитить сообщения от перехвата (шифрование должно поддерживаться у обоих собеседников!) и избавиться от мельтешащей рекламы. Более стойким паролем можно защититься от воровства UIN'ов некоторыми методами подбора пароля. Но эти методы лишь временное ненадёжное решение проблем - регулярные косметические исправления в протоколе ICQ на некоторое время выбивают из строя какого-либо нестандартного клиента, а то и нескольких сразу. В общем, пока сам протокол не будет поддерживать столь важный функционал, все нестандартные клиенты будут как мёртвому припарки.
В пику ICQ, чем же так хорош XMPP (aka Jabber)?

XMPP - открытый промышленный стандарт,
легко расширяем, т.к. построен на базе XML,
поддерживает шифрование паролей и переговоров на уровне протокола, а не только клиентов,
поддерживает множество открытых расширений,
не зависит от какого-то одного провайдера сервиса, т.к. есть множество свободно распространяемых серверов, которые легко может установить и настроить любой более-менее грамотный администратор,
у какого бы провайдера вы не зарегистрировались, вы спокойно сможете общаться со своими знакомыми, зарегистрированными у других провайдеров,

ну и т.д.
Последние несколько месяцев меня останавливала лишь распространенность ICQ среди подавляющего большинства моих активных контактов. Но когда в конце декабря несколько моих знакомых лишились своего UIN'а, а некоторые сами решили перейти на XMPP, я понял, что такая распространенность - это уже вопрос времени.
Надеюсь, что мои рассуждения сподвигнут многих читателей сделать уверенный шаг в сторону безопасного общения, открытых технологий и промышленных стандартов.
Ещё в качестве помощи хочу приложить небольшой список наиболее популярных мировых и российских публичных сервисов Jabber, на которых можно свободно зарегистрироваться и начать общаться не боясь "прослушки" и потери своего аккаунта.

и др., более полный список можно найти на сервере Jabber.org.

Настройка IP-адреса на шлюзе Quintum Tenor CMS

nospam@example.com (Алексей Фёдоров) — Thu, 26 Oct 2006 15:27:09 +0400

Здесь я рассмотрю только случай настройки IP-адреса через консоль.
Для настройки IP-адреса подключаем шлюз к COM-порту компьютера прилагающимся консольным проводом... Для подключения к консоли устройства можно воспользоваться любой терминальной программой, например HyperTerminal. Устанавливаем следующие параметры подключения:

Параметры COM-порта

Жмём ОК. Включаем питание шлюза. Дожидаемся загрузки устройства.
По окончании загрузки шлюз выведет приглашение ввести логин:
<a8baf53> Login:

Вводим логин admin и пароль admin (значения по умолчанию).

Далее переключаемся в режим конфигурации:
Quintum# config
config#

и переходим к конфигурации сетевого интерфейса:
config# ei sl1dv1ei1
config-EthernetInterface-SL1DV1EI1#

Назначаем IP-адрес:
config-EthernetInterface-SL1DV1EI1# set ipa [ваш-ip-адрес]
и маску подсети:
config-EthernetInterface-SL1DV1EI1* set sm [ваша-маска-подсети]

после этого переходим в раздел маршрутизации:
config-EthernetInterface-SL1DV1EI1* siprd 1
config-StaticIPRouteDir-1*
Изменяем дефолтный гейт:
config-StaticIPRouteDir-1* change 1 d 0.0.0.0
config-StaticIPRouteDir-1* change 1 nm 0.0.0.0
config-StaticIPRouteDir-1* change 1 g [ваш-дефолт-гейт]
config-StaticIPRouteDir-1* change 1 eia EI-SL1DV1EI1

После чего (если все адреса и маски введены верно) можно сохранить настройки:
config-StaticIPRouteDir-1* submit
config-StaticIPRouteDir-1#

Последним действием необходимо перезагрузить шлюз либо выключением/включением питания, либо командами консоли:
config-StaticIPRouteDir-1# mc
config- MasterChassis-1# main
maintain-MasterChassis-1# reset
Are you sure that you want to reset the MasterChassis (Yes/No)? yes

После перезагрузки у устройства будет установленный вами IP-адрес.

Quintum Tenor ASG/AFG под MVTS GK

nospam@example.com (Алексей Фёдоров) — Sat, 05 Aug 2006 15:00:48 +0400

Речь пойдёт о настройке аналоговых шлюзов Quintum Tenor с FXS-портами серии AS/AF для работы под управлением Mera VoIP Transit Softswitch в режиме Gatekeeper (GK).
Для начала надо установить удобный для настройки IP-адрес... Для настройки IP-адреса подключим шлюз к COM-порту компьютера прилагающимся консольным проводом. Для подключения к консоли устройства можно воспользоваться любой терминальной программой, например HyperTerminal. Устанавливаем следующие параметры подключения:

Параметры COM-порта

Жмём ОК. Дальше включаем питание шлюза. На экране терминала появится информация о шлюзе и следующая строка:

##############################################################################

>> WITHIN 4 SECONDS, PRESS 'r' FOR FACTORY DEFAULTS OR 'i' TO SET STATIC IP <<

##############################################################################

В течение 4-х секунд надо нажать 'i', чтобы войти в режим установки IP-адреса. После этого устройство предложит авторизоваться (по умолчанию, логин - admin и пароль - admin), выведет информацию о текущих настройках IP-адреса:

###############################################################

Current settings:

        IP Address:      192.168.1.219

        Subnet Mask:     255.255.255.0

        Default Gateway: 192.168.1.1

и предложит изменить настройки:Would you like to change the above settings (y/n)?
Жмём 'y' и меняем настройки по своему усмотрению:

IP Address              : 172.31.1.16

Subnet Mask             : 255.255.255.0

Default Gateway         : 172.31.1.254

Дальше шлюз перезагрузится уже с новым IP-адресом:

Tenor AFG800  ethernet interface successfully configured.



Tenor AFG800 will now restart using these ethernet settings...

Всю дальнейшую настройку будем производить при помощи специальной программы - Tenor Configuration Manager.

Подключаемся конфигуратором к шлюзу по назначенному IP-адресу и сразу переходим в режим "Advanced Explorer":

Заходим в раздел H323 Signaling Group и задаём параметры Gateway Type, Primary Gatekeeper IP, H323 ID и Register DN. Gateway Type устанавливаем в значение "Н323", в Primary Gatekeeper IP пишем IP MVTS, на котором регистрируем наш шлюз, в H323 ID пишем имя нашего шлюза (пин-код, цифро-буквенный идентификатор), по которому будем авторизоваться на MVTS, в параметре Register DN ставим значение "As Gateway Prefixes", а все остальные параметры оставляем как есть.

...

Статья в работе.

Исследование влияния "валидности" кода страницы на рейтинг страницы в поисковых системах

nospam@example.com (Алексей Фёдоров) — Sun, 09 Jul 2006 00:43:10 +0400

Для этого исследования я воспользуюсь методом, который подглядел в какой-то иностранной рассылке. Метод заключается в проверке на соответствие спецификациям топ-10 сайтов по пяти самым частым запросам этого месяца. Такой способ, конечно, не выявляет истинную зависимость рейтинга страницы от валидности её кода, но всё же помогает сделать некоторые выводы на эту тему.
Определить пятёрку самых частых запросов на российских поисковиках мне не удалось (если кто подскажет, буду очень благодарен). Поэтому я воспользуюсь "Прямым эфиром" Яндекса и выберу запросы на свой вкус: лагеря, маргарин, Нашествие, конец света, почта.
Проверять я буду результаты поиска в Яндексе, Рамблере и Гугле. Всего 150 результатов. Из этих 150 результатов полностью удовлетворяющим спецификации оказался лишь один сайт! Это 0,67% всей выборки. 49 сайтов оказались с грубыми ошибками (32,67%). Оставшиеся 100 сайтов содержат некритические ошибки/предупреждения (66,67%). В выдаче Яндекса и Рамблера не оказалось ни одного "чистого" (без ошибок) сайта. Единственный "чистый" сайт пришёлся на долю Гугля. Больше всего сайтов с грубыми ошибками оказалось в выдаче Рамблера - 20 из 50 (40%). В выдаче Яндекса и Гугля таких сайтов 16 (32%) и 13 (26%) соответственно. На долю мелких ошибок/предупреждений в Яндексе приходится 34 сайта (68%), в Рамблере - 30 сайтов (60%), и в Гугле - 36 сайтов (72%).
Какие можно сделать из этого выводы? Я для себя сделал два не слишком радостных заключения: валидность кода страницы имеет очень малый вес (если вообще имеет) при подсчёте рейтинга сайта в выдаче поисковых систем, слишком мало у нас html-верстальщиков, уделяющих внимание соответствию своего кода спецификациям W3C.

IP-PBX Asterisk - Часть 2 - Установка

nospam@example.com (Алексей Фёдоров) — Fri, 07 Jul 2006 14:57:07 +0400

Для установки Asterisk'а я решил воспользоваться первым попавшимся на глаза руководством. Слепо следовать этой инструкции не имеет смысла, т.к. там рассмотрен довольно общий случай. Я внёс в этот алгоритм небольшую коррективу сообразно своей задаче.
Ещё раз уточню свою первую задачу - установить и настроить Asterisk для работы в качестве офисной АТС по протоколу SIP, настроить несколько рабочих мест, организовать выход в ТфОП через VoIP-сеть Rinotel и опытным путём определить максимальную нагрузку для полученной схемы.
Итак, следуя вышеупомянутому алгоритму, я проверил наличие, скачал и установил следующие пакеты: glibc-devel, kernel-devel, kernel-header, db-devel, openssl, openssl-devel, gcc, cpp, binutils, bison, expat-devel и ncurses.
Некоторые моменты, описаные в руководстве под заголовком "Зачистка системы", я отношу к начальной настройке системы, поэтому буду считать, что этот пункт у меня уже сделан. Подраздел, касающийся установки поддержки протокола H323, я тоже пропускаю, т.к. на данный момент у меня нет такой задачи.
Сразу забегу немного вперёд и скажу, что первая попавшаяся инструкция маловата для нормальной установки всех необходимых функций. Это я осознал после первой попытки установить сам пакет asterisk. Поэтому, поискав ещё немножко, я нашел пару описаний Asterisk, но на английском языке: Asterisk Handbook (draft) и Asterisk: The Future of Telephony. Оказалось, что для полноценной поддержки функции Music On Hold и конференций необходимо установить псевдоустройство ztdummy, входящее в состав пакета zaptel.
Ну вот, некоторые немаловажные моменты прояснились, и теперь можно приступить к установке.
Сначала скачиваем самые свежие версии необходимых пакетов (пока неясно, насколько необходимы пакеты libpi и asterisk-sounds, но по ходу разберёмся):

# cd /usr/src/

# wget -–passive-ftp ftp.digium.com/pub/asterisk/asterisk-1.*.tar.gz

# wget -–passive-ftp ftp.digium.com/pub/asterisk/asterisk-sounds-*.tar.gz

# wget -–passive-ftp ftp.digium.com/pub/zaptel/zaptel-*.tar.gz

# wget -–passive-ftp ftp.digium.com/pub/libpri/libpri-*.tar.gz

Дальше распаковываем их:

# tar zxvf zaptel-*.tar.gz

# tar zxvf libpri-*.tar.gz

# tar zxvf asterisk-*.tar.gz

# tar zxvf asterisk-sounds*.tar.gz

Первым устанавливаем zaptel. Перед началом установки надо отредактировать файл Makefile, чтобы включить модуль ztdummy. Для этого переходим в папку /usr/src/zaptel-VERSION/, открываем Makefile, находим строчку

MODULES:=zaptel tor2 torisa wcusb wcfxo wctdm wctdm24xxp \

         ztdynamic ztd-eth wct1xxp wct4xxp wcte11xp pciradio \

         ztd-loc # ztdummy

и убираем в ней решётку перед ztdummy.
Дальше идёт стандартная процедура компиляции и установки пакета:

# make clean

# make

# make install

После этого надо загрузить модуль ztdummy:# modprobe ztdummy
Дальше устанавливаем пакет libpri:

# cd /usr/src/libpri-VERSION

# make clean

# make

# make install

И последним устанавливаем сам asterisk:

# cd /usr/src/asterisk-VERSION

# make clean

# make

# make install

# make samples

Последняя команда нужна для установки демонстрационных настроек в папку /etc/asterisk. Кроме того, можно запустить команду make config для установки Asterisk в автозагрузку.
Для libpri и asterisk никаких специфических настроек перед установкой проводить не требуется.
В пакете asterisk-sounds содержатся дополнительные звуковые файлы для функций голосовой подсказки. Его можно установить при помощи следующих команд:

# cd /usr/src/asterisk-sounds-VERSION

make install

Вот и всё, на этом установка Asterisk завершена.

IP-PBX Asterisk - Часть 1 - Сборка сервера

nospam@example.com (Алексей Фёдоров) — Fri, 07 Jul 2006 11:36:00 +0400

Итак, для начала я расскажу о конфигурации системы, на которую мне предстоит установить Asterisk.

"Железная" часть:
CPU: Intel Pentium 4 2.8 GHz Socket 775 533MHz FSB
M/b: Gigabyte GA-8I945GMF (Intel 945G Express chipset)
RAM: 2x512Mb DDR2 PC2-4200
HDD: 80GB SATA 8MB cache Seagate ST380817AS
LAN: Intel PRO/100B PCI Adapter
Операционная система - Red Hat Linux 9 (Shrike).
Ядро оставил стандартное Linux 2.4.20-8. Тюнинговать пока лениво.
Диск разбил в автоматическом режиме.
При установке все "лишние" пакеты повыкидывал, чтоб не болтались мёртвым грузом. А всё необходимое буду устанавливать уже по мере надобности.

Про минимальную настройку системы особо рассказывать не имеет смысла. Упомяну лишь, что необходимо настроить сетевые интерфейсы.

IP-PBX Asterisk - Часть 0 - Задача

nospam@example.com (Алексей Фёдоров) — Thu, 06 Jul 2006 22:21:00 +0400

Сегодня у меня началась очередная эпопея. Моя задача - установить, настроить и испытать в нашем офисе IP-PBX Asterisk. Причём интересно изучить различные применения этого продукта:

простая офисная АТС,
расширение номерной ёмкости существующей офисной мини-АТС средствами VoIP,
объединение телефонных сетей удалённых офисов.

По ходу могут возникнуть и другие задачи, но об этом как-нибудь в другой раз.

В этой серии статей я постараюсь осветить весь процесс: от сборки сервера до настройки клиентских мест и самих испытаний. Очень надеюсь, что эти статьи неоднократно пригодятся моим коллегам.