vk_logo twitter_logo facebook_logo googleplus_logo youtube_logo telegram_logo telegram_logo

#181 Баш на Баш (VoIP)

Дата публикации: 17.06.2004
Количество просмотров: 8299

Небольшой вступление.

Вспомним про сисадмина. Того самого абстрактного любителя пива "Балтика #3", красного L&M и соленых сухариков со вкусом бекона (чипсы из моды вышли надолго, Lays с позором капитулировали перед сушеным хлебом).

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

Но они будут - кое-что уже маячит на горизонте - судя по всему, скоро на офисный "сервер" ворвется старая добрая телефония. Уверен, что не пройдет и пары лет, как Linux-PBX (мини-АТС на Linux) станет для небольшого офиса не менее привычной, чем сейчас отдельно висящий на стене Panasinic или какой другой LG. Просто в ядро добавится IP-телефонная софтина, и рядом с Ethernet-картой встанет что-нибудь похожее на AsteriskTM PBX (один порт FXO стоит целых $14.50).

Собственно, все к этому постепенно и идет. Осталось поставить на рабочие места IP-телефоны с розетками Ethernet, благо есть модели от $75 - т.е. их стоимость уже не сильно отличается от классических офисных телефонных аппаратов. Ну и сисадминам научиться конфигурировать это голосовое хозяйство...

Такой небольшой на первый взгляд этап. Соединение в одно целое двух "несерьезных" по меркам индустрии систем (VoIP и Lunux) вполне может дать качественный рывок в индустрии связи. А стык VoIP с ТФОП станет простым и демократичным, доступным любой небольшой фирме или даже домашнему пользователю.

К чему это приведет? Результат надо будет смотреть года через 3-4. Как раз после массового перехода офисных сетей на гигабит.

 


А пока - следы другой стороны прогресса. На фото 72-метровая Преподобенская колокольня Ризоположенского монастыря в Суздале (прислал Вадим).

Преподобенская колокольня Ризоположенского монастыря

Радиолинки то же незаметно входили в быт. Сперва экзотика, потом... Потом они становятся просто незаметными, взгляд скользит мимо.

 


Обновления в разделах на сегодня фактически отсутствуют. Только запущен в бета-тестирование каталог-магазин 4isp.ru.

Баш на Баш.

Данный текст предоставил MrBear, большой любитель хорошего коньяка. ;-)

Последнее время особый ажиотаж в отрасли вызывают попытки Связьинвестовских структур руками правительства спасти свой едва ли не единственный реальный источник дохода - монополию на трансрегиональные переговоры. Можно ломать копья на тему коррумпированности чиновников и засилья монополистов, но не проще ли подумать, как раз и навсегда обойти искусственные запреты? Особенно, учитывая, что решение лежит на поверхности - недаром технологии peer-to-peer так популярны последнее время.

Ничто не мешает применить их и в телекоммуникациях, исходя из того простого факта, что принципиального различия между перепиской по ICQ и голосовой связью "over IP" нет, а необходимость фиксированной полосы пропускания с лихвой компенсируется нынешней повальной широкополосностью. Действующие службы, типа модного Skype, к сожалению не обеспечивают главного - достаточно простого в юзабилити стыка с так называемой ТФОП, без которого подобные услуги смогут охватить только очень узкий круг пользователей. Дело за малым - обеспечить этот самый стык и - исключить из процесса переговоров оператора связи, буде теперь там могут действовать только монополисты, так пусть вменяемый клиент не достанется никому.

Итак, дарю know-how. Замечу, что сервис, для повышения как надёжности, так и независимости, в итоге должен состоять из нескольких, географически разнесённых серверов, составляющих эдакий распределённый кластер и содержащих единую базу участников. Для начала можно обойтись и одним PC'ком, конечно. Участники, они же клиенты, устанавливают на своих рабочих станциях PCI-платы (типа DigitNetworks X100P, например) с одним FXO и одним FXS портами (применение оборудования класса Cisco тоже не возбраняется) и программное обеспечение, позволяющее как совершать звонки наружу, так и принимать их с шлюзованием в телефонную сеть. Это может быть и адаптированный софт нынешних производителей, но лучше будет написать собственное приложение, разумеется, наиболее гибко реализующее идею.

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

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

Вот и всё. Откуда владелец сети будет получать свой профит, как наиболее широко разрекламировать этот сервис, алгоритм взаимоотношений с клиентами и прочую рутину пусть подскажет фантазия предпринимателей, желающих взяться за дело. С преуспевших, за идею - коньяк не хуже XO и не менее 0,7 литра. Вот такой альтруизм... :)

Разное.

Новость о беспроводной гигабитной сети в Стамбуле получила очень интересное продолжение. Вот фотография стамбульской крыши, на котором станция fSONA стоит рядом с российским радиомостом Fast Ethernet.

радиомост Fast Ethernet

На одном из участков первой беспроводной гигабитной сети, развернутой турецкой коммуникационной компанией Omnitek в Стамбуле (Турция), в качестве резервной линии стоит 100Мбит (Fast Ethernet) радиолиния петербургской компании ДОК. Данная линия работает в диапазоне 94 ГГц - наиболее высокочастотном из всех доступных для коммерческой связи согласно требованиям FCC, ETSI, а также локального турецкого законодательства.

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

Туман и смог имеют размер частиц порядка 1-20 микрон, а потому являются преградой для атмосферной оптики (FSO), работающей на волнах длиной 0.785-0.85 и 1.55 микрон. Так что, к примеру, сильный туман характеризуется ослаблением в 350dB (для оптики это как бетонная стена), поэтому атмосферная оптика сразу "ложится". Дождь имеет размер частиц 0.1-10 мм, и потому, в свою очередь, влияет на работу радиолиний (частота 94ГГц = длине волны 3 мм).

Но радиолинии не столь сильно подвержены атмосферным влияниям, как оптика. Для радиолиний максимальное ослабление согласно бюллетеню FCC находится на отметке 50dB для дождя интенсивностью 150 мм/час. К слову, такой дождь относится к разряду стихийных бедствий, т.к. даже сильный дождь в Европе имеет интенсивность порядка 15-20 мм/час. Идеально, когда оптическая линия и радиолиния дублируют друг друга, поскольку на нашей планете в одном и том же месте сильный туман и сильный дождь никогда не бывают одновременно, гарантируя "пять девяток" надежности для такой гибридной линий.

Кстати, в настоящее время "ДОК" ведет активные работы по созданию следующего поколения систем радиосвязи - в стандарте Gigabit Ethernet (1.25 Гбит/c). Эти системы также предназначены для работы на миллиметровых волнах, в том числе в наиболее перспективных диапазонах 70/80 ГГц и 94 ГГц. Уже создан лабораторный прототип, способный передавать поток данных Gigabit Ethernet с одного приемопередатчика на другой в пределах лаборатории.

 


Несколько фотографий из серии "как делаются коммутаторы" - на этот раз от Павла Козика, D-Link.

Тестовый полигон D-Link в центральном офисе на Тайване:

D-Link в центральном офисе на Тайване

Следующая фотография - одна из лабораторий по проверке на совместимость оборудования D-Link с железом других вендоров:

Лаборатория D-Link

Фотографии сделаны инженерами D-Link во время командировки на технические тренинги.

 


Небольшое письмо от Romana Y. Bogdanova:

... Сегодня обнаружил интересную штуку для FreeBSD начиная с 4.10 (стабильная ветка). В ней появилась замечательная возможность настройки интерфейсов для homenet провайдеров. Режим, когда интерфейс отвечает только на те адреса, которые статически записаны в ARP таблицу машины.

Вот кусок из ifconfig:

staticarp    If the Address Resolution Protocol is enabled, the host will only    reply to requests for its addresses, and will never send any requests.

-staticarp    If the Address Resolution Protocol is enabled, the host will per-    form normally, sending out requests and listening for replies.

VoIP для начинающих. Часть первая: H323

Автор данного текста Эдуард Афонцев, Екатеринбург.

 


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

Коммутация вызовов осуществляется передачей сигнальных сообщений, а данный процесс упрощенно называется сигнализацией. Сигнализация решается средствами специальных протоколов h323, SIP, MGCP, h248 и других. Передача данных (голоса) осуществляется средствами протоколов rtp, rtcp. Предварительно происходит обработка (сжатие) потока данных с использованием какого-либо алгоритма кодирования (кодека).

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

 

  • RAS (h.225) signaling,
  • Call control/call setup (h.225),
  • Media control and transport (h.245) signaling.

H323 определяет четыре основных компонента для коммуникаций:

  • Gateway шлюз,
  • Gatekeeper контроллер (привратник),
  • Terminal терминал,
  • MCU (multipoint control unit) устройство для конференций.

Терминал - конечное клиентское устройство. Представляет собой аппаратно-программный комплекс, например компьютер со звуковой картой подключенный к сети. Шлюз - согласующее устройство между h323 и терминалами других типов. Осуществляет преобразование между форматами передачи данных. Например, это может быть оборудование, соединяющее IP сеть (VoIP) с телефонной станцией.

Любое из устройств вида gateway, terminal, mcu называют конечным узлом - Endpoint. Для обеспечения двухточечных соединений достаточно использования только Endpointов.

Алгоритм взаимодействия следующий: сначала вызывающий узел (Endpoint) находит вызываемого и договаривается с ним о параметрах связи, используя средства сигнализации H323, а затем происходит передача кодированной речи:

Однако для гибкой маршрутизации соединений, авторизации, биллинга и прочего необходимо использовать Gatekeeper (в переводе с англ. привратник). Он выполняет только функции сигнализации, так называемые RAS - registration, admission and status. Непосредственно данные (речь) передаются между шлюзами и терминалами. Фактически Gatekeeper выполняет функции маршрутизатора звонков.

Совокупность Endpointов, которые регистрируются на конкретном Gatekeepere, образуют так называемую зону. Gatekeeper в этом случае является контроллером зоны, он знает о всех Endpointах, которые на нем зарегистрировались. В зоне может быть только один Gatekeeper:

Gatekeeper - предоставляет обязательные сервисы:

  1. трансляция (преобразование) адресов (address translation) - преобразование h323 идентификаторов (вида voice1) и E.164 номеров (стандартные телефонные номера) в ip адреса данных Endpoints, зарегистрированных на данном Gatekeepere;
  2. контроль (управление) доступа (admission control, admission - входная плата) - контролирование прохождения звонков от и к Endpoint;
  3. регулирование (управление) полосы пропускания (bandwidth control) - согласование требуемых Endpointом параметров связи;
  4. администрирование (управление) зоны (zone management) - например контроль за регистрацией Endpointов в данной зоне.

И необязательные сервисы (может и не предоставлять):

  1. авторизация вызовов (call authorization) - разрешение звонков в соответствии с определенными правилами;
  2. маршрутизация h323 соединений - проброс управляющих сообщений между участниками (очень редкая функция).

Рассмотрим алгоритм взаимодействия endpoint и gatekeeper.

Поиск Gatekeepera.

Endpoint при активации (включении) должен найти gatekeeper. Данное действие выполняется путем посылки специального запроса gatekeeper request - GRQ. В случае успешного поиска Gatekeeper возвращает gatekeeper confirm (GRQ), а в случае неудачи - gatekeeper reject (GRJ).

Данный пункт алгоритма обычно выполняется даже если gatekeeper вписывается в конфигурацию endpoint статически (для того, чтобы убедиться в наличии и работоспособности gatekeepera). Если же endpoint вообще ничего не знает о gatekeepere, то используется multicast запрос GRQ.

Регистрация на Gatekeepere.

Далее Endpoint должен зарегистрироваться на Gatekeepere. При этом Endpoint сообщает свои параметры (H323 ID - идентификатор, E164 - телефонный номер), а Gatekeeper ассоциирует эту информацию с сетевыми параметрами (например ip адресом).

Регистрация (имени, номера) происходит путем посылки запроса registration request - RRQ.

В случае успеха Gatekeeper посылает registration confirm (RCF) и запоминает параметры зарегистрированного Endpointa, а при неудаче - registration reject (RRJ).

После данного этапа Gatekeeper в состоянии выступать в качестве справочной телефонной (адресной) книги при маршрутизации звонков - ведь он знает всех своих зарегистрированных Endpointов.

Контроль прохождения вызовов (звонков).

Контроль разрешения вызовов (admission control) происходит в момент инициализации звонка или получения вызова.

Диалог при этом примерно следующий:

Endpoint посылает ARQ (admission request) : Я, endpoint такой-то (h323 id или номер) хочу позвонить на endpoint такой-то (h323 id или номер).
Gatekeeper отвечает ACF (admission confirm) : Да, вы можете позвонить, ip адрес endpoint назначения звонка такой-то.

Или
Gatekeeper отвечает ARJ (admission reject) : Нет, вы не можете позвонить. Причина такая-то (например нет такого назначения или у вас недостаточно средств на счете).

Согласование параметров связи.

Endpoint может согласовать параметры необходимой полосы пропускания, посылая запрос BRQ (bandwidth request), а Gatekeeper отвечает удовлетворительно BCF (bandwidth confirm) если требуемая полоса может быть выделена, или отрицательно BRJ (bandwidth reject) если требования невыполнимы (например вся полоса уже исчерпана).

Поиск абонента.

В случае, если звонок направлен в другую зону (то есть предназначен для endpoint, который не регистрируется на данном gatekeeper и следовательно ему не известен), то gatekeeper может послать другим gatekeeperам специальный запрос для выяснения, где регистрируется нужный endpoint.

При этом Gatekeeper посылает location request (LRQ), а ему отвечает другой Gatekeeper, который знает о запрашиваемом абоненте - location confirm (LCF) или ничего не знает - location reject (LRJ).
По сути это поиск абонента в другой зоне.

Отключение.

И, наконец, при прекращении работы endpoint должен отключиться от gatekeepera, посылая unregistration request (URQ). В ответ Gatekeeper обычно отвечает согласием unregistration confirm (URF) и удаляет данные о Endpointe из своей базы. И крайне редко unregistration reject (URJ).

В итоге, упрощенная схема взаимодействия между Endpointами в одной зоне выглядит так:

Endpointы регистрируются и координируют направления звонков через Gatekeeper, а голосовой трафик проходит непосредственно между ними. Некоторые gatekeeperы (особенно программные) могут дополнительно проксировать и голосовой поток, в этом случае endpointы не взаимодействуют между собой вообще. Это может потребоваться например в случае подключения к сети IP (интернет) клиентской подсети с приватными адресами через шлюз, выполняющий функции трансляции адресов. Gatekeeper будет выступать в качестве голосового прокси сервера.

Заключение.

Данное описание парадигмы H323 является поверхностным и предназначено для предварительного ознакомления с основными понятиями IP телефонии. Далее рекомендуется ознакомиться с более фундаментальными руководствами (например на сайте cisco) и провести лабораторные практические занятия по построению VoIP сети, о чем мы попытаемся рассказать вам в следующих выпусках.

И опять мусоропровод.

Кабельное телевидение протянуто через мусоропровод.

Мусоропровод в роли

Только на этот раз действующий.

Прислал Alexander.

Анонс

 

  • Правосвязие. Ведение. Первая статья из цикла "о легализации" домашних сетей Антона Богатова.

 

  • Полезные ссылки;
  • Как снимают телевизионный сигнал с П-296;
  • Зарисовки узлов разных провайдеров (в основном стойки).
  • Переход через железную дорогу (несколько фотографий);
  • Сети учебных заведений в Германии (долгострой);
  • Традиционный пункт - ссылки на интересные места Сети. Присылайте письма - они очень нужны для обзоров. Обязательно сообщайте, нужна ли Ваша подпись, ссылка, или лучше обойтись без нее;
  • В "ужастиках" - "найден узел конкурента!". ;-)

От редакции: если у вас есть чем поделиться с коллегами по отрасли, приглашаем к сотрудничеству
Ссылка на материал, для размещения на сторонних ресурсах
/articles/reviews/16681/bash-na-bash-voip-.html

Обсудить на форуме

Оставлять комментарии могут только зарегистрированные пользователи

Зарегистрироваться