Вспомним про сисадмина. Того самого абстрактного любителя пива "Балтика #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.
На одном из участков первой беспроводной гигабитной сети, развернутой турецкой коммуникационной компанией 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 во время командировки на технические тренинги.
Небольшое письмо от 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. Условно говоря - это язык, на котором договариваются между собой участники соединения. Он включает в себя следующие протоколы:
H323 определяет четыре основных компонента для коммуникаций:
Терминал - конечное клиентское устройство. Представляет собой аппаратно-программный комплекс, например компьютер со звуковой картой подключенный к сети. Шлюз - согласующее устройство между h323 и терминалами других типов. Осуществляет преобразование между форматами передачи данных. Например, это может быть оборудование, соединяющее IP сеть (VoIP) с телефонной станцией. Любое из устройств вида gateway, terminal, mcu называют конечным узлом - Endpoint. Для обеспечения двухточечных соединений достаточно использования только Endpointов. Алгоритм взаимодействия следующий: сначала вызывающий узел (Endpoint) находит вызываемого и договаривается с ним о параметрах связи, используя средства сигнализации H323, а затем происходит передача кодированной речи:
Однако для гибкой маршрутизации соединений, авторизации, биллинга и прочего необходимо использовать Gatekeeper (в переводе с англ. привратник). Он выполняет только функции сигнализации, так называемые RAS - registration, admission and status. Непосредственно данные (речь) передаются между шлюзами и терминалами. Фактически Gatekeeper выполняет функции маршрутизатора звонков. Совокупность Endpointов, которые регистрируются на конкретном Gatekeepere, образуют так называемую зону. Gatekeeper в этом случае является контроллером зоны, он знает о всех Endpointах, которые на нем зарегистрировались. В зоне может быть только один Gatekeeper:
Gatekeeper - предоставляет обязательные сервисы:
И необязательные сервисы (может и не предоставлять):
Рассмотрим алгоритм взаимодействия 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 или номер). Или Согласование параметров связи. 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. Анонс
|
&description=Вспомним про сисадмина. Того самого абстрактного любителя пива "Балтика #3", красного L&M и соленых сухариков со вкусом бекона (чипсы из моды вышли надолго, Lays с позором капитулировали перед сушеным хлебом).&image=https://nag.ru/uploads/material/images/1479/social_cover.png)
&imageUrl=https://nag.ru/uploads/material/images/1479/social_cover.png)
