Объединение Linux Phone Standards (http://www.lipsforum.org/) (LiPS) выпустило (http://www.lipsforum.org/index.php?option=com_content&task=v...) первую версию спецификации (http://www.lipsforum.org/index.php?option=com_banners&task=c...) стандарта на Linux телефонию, подтолкнув производителей мобильных устройств к обеспечению базовой совместимости между приложениями и сервисами, доступными на разных вариациях мобильных телефонов построенных на основе Linux.
Спецификация включает список требований к приложениям телефонии, обмена сообщениями, календарю и планировщику, адресной книге, сервисам пользовательского интерфейса, API голосового вызова и т.д.
В разработке стандарта участвовали такие компании, как France Telecom, Telecom Italia S.p.A, Freescale Semidconductors, Huawei Technology Co., Texas Instruments, ACCESS Co., Montavista Software.
Можно предположить, что организация LiPS выступает в роли оппозиции к платформе Google Android (http://www.opennet.me/opennews/art.shtml?num=12765) и альянсу Open Handset Alliance (http://www.opennet.me/opennews/art.shtml?num=12670),в который вошли Motorola, Samsung, LG Electronics, Intel, Marvell Semiconductor, NVIDIA, Texas Instruments, Qualcomm, HTC и T-Mobile. В начале года также было создано объединение (http://www.opennet.me/opennews/art.shtml?num=9638) LiMo Foundation, в которое вошли Motorola, NEC, NTT DoCoMo, Panasonic, Samsung и Vodafone. Учитывая различие в весовых категориях организаций разработавших LiPS и создателей де-факто стандартов, этот документ имеет все шансы остаться только на бумаге.URL: http://www.linuxelectrons.com/news/mobile/15463/linux-phone-...
Новость: http://www.opennet.me/opennews/art.shtml?num=13147
В любом случае стандартизация - это хорошо. Даже такая..
Пока они там всякой фигнёй занимаются первый действительно свободный телефон с линуксом - http://openmoko.org уже готовится к выпуску второй модели. А поскольку линукс там полноценный, то в качестве стандарта вполне подойдёт LSB.
http://openmoko.org - пардон.Кстати, заголовок новости довольно сомнительный: я уж было понадеялся, что zaptel и аналоги к приличному виду привести решили...
А у zaptel есть аналоги (mISDN все-таки далеко не аналог)?В порядок их привести нельзя. Оно brain damadged, его надо переписывать практически целиком. А Digium это не зачем, и они _против_ включения zaptel в vanilla kernel :(
а в чём они конкретно brain, а в чём они damaged?
> а в чём они конкретно brain, а в чём они damaged?Насчет того в чем там brain я не знаю -- сколько не силился, не нашел.
Если конкретнее:
- 8kHz. Только. G.722 идет нафиг
- 8bit. Только. Несмотря на возможность API верхнего уровня отдавать данные в 16-и битном виде, lowlevel API этого не позволяет принципиально
- API для транскодинга параллельное. Нет возможности сказать "я хочу от этого устройства G.729, и если оно его умеет -- пущай отдает именно его", данные от платки надо засасывать в G.711, потом запихивать назад, потом читать G.729. Это приемлимо только потому, что Digium не делает платки "все в одном", и делать такие платки другим совместимым с Asterisk образом не даютИ т.д.
А реализации SS7 штатной там, кстати, вообще нет. Будет на базе их же libss7 в 1.6, которое неизвестно в каком году выйдет (я бы ждал к осени... с учетом того что прошлый раз после заморозки понадобилось более полугода для выпуска, а пока ничего похожего на заморозку нет).
Для 1.4 есть кодек от Sifira http://www.seiros.ru/products/chan_ss7 который был мною слегка доработан напильником. А для работы с железкой тот же Yate использует тот же самый zaptel, который уже стал стандартном де факто.
Если кратко -- zaptel это ужас, летящий на крыльях ночи. Но для этой задачи больше никто не сделал решения лучше. Да, у Sangoma есть еще какое-то свое API, у Cronyx есть свое API. Но эти API никто кроме них не умеет :) А zaptel это все-таки стандарт де-факто. Хотя и без документации, который приходится изучать по кривому коду и через строчку ругаться.
Ну про то, что коллега уже находил баг в одном из дигиодиных драйверов с выводом в _чужие_ ioports (который остался незамеченым ранее, потому что этот вывод был вообще нафиг не нужен) я уже молчу.
Digium лучшие в своей сфере, если их сферу называть "телефония под Linux", но ни в коем случае не "системное программирование под Linux".
Как минимум Yate - там полностью независимая реализация SS7 насколько я знаю.
Что касается мнения дигиума, то мне, честно говоря, наплевать против чего они там выступают. С астериском уже довыступались - появился CallWeaver, который гораздо продвинутее за счёт большей открытости.
Хотя заптел и вправду было-бы здорово переделать по-уму: поэтому и хотелось бы видеть грамотный стандартизованный подход.
>Как минимум Yate - там полностью независимая реализация SS7 насколько я знаю.Что общего у SS7 и zaptel? Что общего у Asterisk и SS7 (в релизном Asterisk от Digium нет на SS7 никаких намеков)?
>Что касается мнения дигиума, то мне, честно говоря, наплевать против чего они
>там выступают. С астериском уже довыступались - появился CallWeaver, который гораздо
>продвинутее за счёт большей открытости.Список продвинутостей по пунктам плиз.
Мне известно только про совершенно другой уровень поддержки T.38, до которого астериску как до луны раком. Вижу что более охотно принимаются новые патчи со стороны, да. Но только команда по силе несоизмерима.
В астериске я вижу как сейчас его перепахивают на предмет производительности. И если 1.4 совершила огромный рывок по сравнению с 1.4, то с 1.6 рывок будет тоже очень заметен на высоконагруженых системах. Скоро речь уже пойдет о конкуренции в плане производительности с freeswitch.
CallWeaver это пока хроническая бетаверсия. А астериск я уже слегка напильником доработав не боюсь ставить на станции тех, кто с меня за несколько минут простоя может три шкуры содрать, и где минута простоя измеряется 3-4х значными суммами в баксах.
>Хотя заптел и вправду было-бы здорово переделать по-уму: поэтому и хотелось бы
>видеть грамотный стандартизованный подход."Шлите патчи". Продавливать патчи Digium'у это то еще удовольствие. Но вполне реальное.