Да. Я тоже очень восторгался.
Это такие тюменские товарищи.
На наге
http://www.nag.ru/2006/0329/0329.shtml
можно почитать подробнее, как это реализовалось.
Опыт реализации VoIP приложений: вид изнутри.
Новость о том, что Google опубликовал Libjingle - исходный код библиотеки для использования voip функций своего IM клиента Google Talk первоначально была мной если не игнорирована, то встречена несколько скептически. Кому в сейчас интересны проприетарные протоколы? Однако, как появилась минутка свободного времени, решил посмотреть на libjingle.
Оказалось, все гораздо интересней. Google не стал изобретать велосипеды, а взял за основу уже работающие стандарты. Известный стандарт XMPP для рассылки мгновенных сообщений был слегка расширен разработчиками из Google Labs для поддержки коммутации голосовых потоков. Результат был опубликован как JingleAudio (JEP-0167) и одобрен разработчиками протоколов Jabber. Для передачи непосредственно голосового трафика в libjingle использован все тот же RTP, на котором строится вся современная IP-телефония.
Разработчиками libjingle были также реализованы протоколы STUN и ICE (
http://www.jdrosen.net/papers/draft-iet ... ice-07.txt) для поддержки "повышенной" проходимости через разнообразные конфигурации NAT-ов и Firewall-ов, что очень важно. На данный момент очень редкое VoIP устройство или приложение может прозрачно работать находясь за двумя NAT-ами (каждый пользователь находится за NAT-ом своего провайдера), а надо сказать, что такая схема расположения конечных пользователей на данный момент является повсеместной.
После некоторых манипуляций с установкой требуемых дополнительных библиотек мне удалось собрать и запустить проект Libjingle под ОС Linux. Попытка сборки под FreeBSD не дала положительного результата, сборка осуществляется, но результат сборки, утилиты call и login, в момент запуска выпадают с core dump при попытке создать PThread.
Под Linux-ом же все заработало и я с первой попытки смог соединиться из под своего coLinux окружения с Google Talk-ом установленным у коллеги на его рабочем ПК. Качество звука оказалось отличным, но и послужило настораживающим фактом. Анализ трафика через tcpdump показал, что для передачи голоса используется кодек PCMU (AKA G.711u) со скоростью потока 64Кбит/сек. Понятное дело, такой поток данных пригоден для локальной сети, но совсем не уместен для модемного соединения.
Память Sun X7603A для Sun Blade 1000 Память Sun X7603A для Sun Blade 1000
Sun X7603A - 1GB RAM Option, SPD 1.0 (2X512MB) OBP req
всего за $500.00!
Вскоре выяснилось, что помимо PCMU в libjingle (и в самом Google Talk-е) реализованы еще ряд кодеков для работы на пониженных скоростях. Как происходит выбор кодека под конкретное соединения выяснить мне не удалось, но не составило труда заставить libjingle использовать кодек отличный от PCMU (например iLBC). Поддержки общепринятых G.729 и G.723.1 в библиотеке не оказалось, и понятно по каким причинам.
Дело в том, что данные кодеки являются проприетарными и Google не стал связываться с лицензионными проблемами, что есть правильно. По сообщениям из Google Lab, в последние версии библиотеки было добавлено огромное количество открытых Speex кодеков, которые по качеству звука превосходят проприетарный G.729.
Немного побаловавшись с libjingle, мне пришла в голову простая, как мне тогда показалось, идея - сделать голосовой шлюз между Google Talk-ом и обычным VoIP. Т.е. требовалось осуществлять прием соединений по протоколу JingleAudio и отправлять в H.323 или SIP.
Хочу заметить, что за долгие годы администрирования ряда интернет и VoIP провайдеров в г. Тюмени мне довелось иметь опыт разработки собственных VoIP приложений с использованием широко известной библиотечки OpenH323. Таким образом, задача сводилась к минимуму: скрестить две библиотеки: Libjingle и OpenH323. Скажу сразу, что сделать это не представляется возможным по ряду причин, начиная от собственно кривого и недокументированного кода libjingle, до проблем с синхронизацией PThreads которые используются в обеих библиотеках очень по-разному.
По ходу исследований так же выяснились и обнаружились ряд ограничений заложенных в архитектуре самой Libjingle. Например, отсутствие возможности создавать одновременно несколько голосовых потоков, так как разработчики использовали статическое назначение UDP портов для взаимосвязи с библиотекой oRTP. Возможно в последних релизах libjingle что-то изменилось, но в тот момент эта библиотека показалась мне абсолютно не пригодной для создания чего-нибудь более серьезного, чем создания конечного клиентского приложения. Кстати сказать, на данный момент уже выпущены в свет ряд IM клиентов (Psi, Tapioca) с поддержкой JingleAudio на основе libjingle.
Негодование вызванное такими открытиями не остановило меня от реализации задуманной идей. Размышления мои были следующие: если Google Talk использует открытые кодеки и открытый протокол RTP, и все это уже давно присутствует в OpenH323, то почему бы не дописать недостающий набор классов реализующих простой и понятный JingleAudio для сигнализации? Что собственно и было сделано в течение одной недели.
Сам протокол JingleAudio оказался не сложным, более сложным было реализовать поддержку STUN и ICE (чувствуется влияние индийской кухни Cisco Systems). Помимо просто поддержки транспорта, для полного гейтования двух протоколов (H.323 и JingleAudio) требовалось еще создание голосового миксера для смешения двух и более голосовых потоков. Данная фича была закодирована достаточно быстро.
Полевые испытания библиотеки проводились как в локальных сетях (FastEthernet), так и модемных соединениях. Тройное преобразование звука типа Linear->iLBC->G.729->G.711->Linear, например при звонке в ТфОП через местного VoIP провайдера, дает небольшие искажения, но качество вполне пригодное для нормального общения (пользователи старых совдеповских АТС могут только мечтать о таком). Терминация на другие города через иных VoIP провайдеров не привела к какому либо ухудшению качества звука. Хотя, более подробные исследования этого вопроса еще предстоит сделать.
По окончанию тестирования к получившемуся гибриду (который был назван мной libJungle) был приделан верхний уровень: Finite State Machine (машина конечных состояний) для обработки большого потока звонков одновременно и создания ряда дополнительных голосовых функций, как то: голосовая почта и многопользовательские голосовые конференции.
Прочитать о разработанных сервисах можно на
http://www.gtalk2voip.com/ и протестировать их, в том числе и междугороднюю связь прямо их Google Talk-а, можно путем добавления сервисного пользователя
service@gtalk2voip.com в список контактов. Подробности по использованию даны на сайте, или доступны по команде HELP в окне чата с сервисным пользователем.
Если кто-то из читателей заинтересуется разработкой, в том числе внедрения её как в коммерческие проекты, так и в Open Source, пишите, будет общаться. Интересуют так же ваши мысли по улучшению сервисов и по внедрению новых. Сервисы на базе FSM реализуются очень быстро.
Автор Руслан Залата, г. Тюмень Март 2006.
Вход
FAQ
Поиск
. Пользуйтесь
