Еще бы железки где на эту штуку добыть...

http://www.digium.com/index.php?menu=hardware_products
Дороговатые, правда, железяки.

$1,495 за 4xE1 дорого?

А к компу никак нельзя?

В смысле через модем?

>организация очередей звонков

Это как делается? Разве можно по одному номеру несколько звонков принимать? Или тут несколько телефонных линий нужно подключать?

Написано, что даже через звуковуху можно B-)

Конечно несколько. Как иначе то? :)

Интересная штука. Обычно на серьезных Exchange ставят системы реального времени, типа QNX. Для офисной машинки пойдет и Linux.

> Обычно на серьезных Exchange ставят системы реального времени, типа QNX
Бесполезно, здесь вся фишка что по IP/Ethernet голос идет, а там время доставки никто не гарантирует.
По сравнению с доставкой, дельта вносимая самой OS ничтожна.

http://www.infratel.ru/ - а это не тоже самое?

infratel - это детский сад по сравнению с digium. Конечно и у последних есть low-end модели, но infratel - так, пара-четверка каналов, слабые компрессии, отсутствие необходимого софта.

На российском рынке low-end e1 infratel может быть и рулит, но вверх им никогда не пробраться.

Более или менее high-rnd в России - это Vocord Telecom, нл у них весьма специфичные платы...

> Интересная штука. Обычно на серьезных Exchange ставят системы реального времени, типа QNX. Для офисной машинки пойдет и Linux.

Подобная фраза говорит о том, что vlad_ts ничего не смыслит в IP телефонии.

Дабы показать, что ты не прав, попробуй посчитать, какова "толщина" одного E1 канала, а затме умножь ее на количество каналов в плате. Некоторые платы могут делать до 120 каналов E1.

А теперь подумай, сколько еще свободного времени останется у Linux после обработки такой платы? Да на нем еще видео смотреть в несколько потоков можно будет...

Это что ли типа Дефинити программная?

Существуют также embedded решения на базе Linux, но никак не QNX.

Есть примеры с RTEMS, eCos, но они настолько кривые, ненадежные и малопроизводительные, что за теже деньги можно сделать более грамотное embedded решение на базе Linux.

Что, собственно, все и делают. Но конечно в большинстве случаев это не встраиваемые решения, а большой гроб с десятком PCI плат в нем.

А fronend к ним уже asterisk, или что-нибудь под винду(собственно, под винду наверняка такие базы есть у всех производителей)...

да ладно вам уже давно linux работает и в алкателе и в авае. астериск не обязан работать только с карточками, он поддерживает кучу протоколов чисто сетевых, так что очень неплохая альтернатива в умелых руках, я использую как IVR и DID для шлюзов которые ее не умеют)

а вот другая более интересная новость:

Интел порадовал исходниками g.729 кодека под линукс. Причем купить лицензию частнику непосредственно у правообладателя будет очень затруднительно.

Народ соответсвенно прет не нарадуется, уже интегрировали в астериск. Прекрасная ДСП-ферма из писюка получается.

1 портовые FXO платы есть ничто иное как Винмодем.... :) на чипе MD3200 от Intel например:
http://www.compgeeks.com/details.asp?invtid=ENF656-GSW-INPR

забавно, я видел как их один чувак продает очень дешево, даже не подозревал. хм а какие еще модемы на этом интеловском чипсете?

По поводу Интела - ссылочку бы на посмотреть codec_g729_блабла.so

Смешанные чувства оставляет. Нет поддержки 711 кодека, понятна что по 729 лучше стыковать с VoIP операторами - но внутри сети есть смысл раздавать на 711 кодеке на IP телефоны, ежли уж заявлен H323 и SIP. Поддержка факсов и T38 отсутствует полностью (опять возвращаясь к теме VoIP). Хотелось бы узнать проблемы стыковки по PRI со станциями типа LG и Samsung (надо ьы в офисе проверить если время будет). Диалектов H323 тоже масса - что не производитель так по своему понимает трактование H323. В идеале все будет работать при стыковке двух Asterisk. Начинание хорошее - но до проработанного проекта еще далеко.

выпрачо?) есть поддержка, по дефолту в g711 и работает. поддержка этого кодека считается обязательной для voip вообще и h.323 любой версии в частности.

c факсами хреново, да. Так вон в цискином калменджере до сих пор нету) и не жужжат. зато есть эскпериментальная реализация fax -> email шлюза. факс вообще умрет, переходите на электропочту.

А так очень неплохо работает, вы пробуйте, прежде чем хаять, телефонисты доморощенные.

> Диалектов H323 тоже масса - что не производитель так по своему понимает трактование H323. В идеале все будет работать при стыковке двух Asterisk.

Не совсем, там H323 реализован через OpenH323, а он не такой привередливый как всякие циски, да вокалтеки.

>Подобная фраза говорит о том, что vlad_ts ничего не смыслит в IP телефонии.

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

>попробуй посчитать, какова "толщина" одного E1 канала

Нет желания считать, мне часто приходится иметь дело с потоками Е1 с разной "начинкой" от сельских ЦСП до BTS GSM.

>Некоторые платы могут делать до 120 каналов E1.

Видел такие изделия, даже отечественного производства их не мало, но они не удовлетворяют нормам ITU. На выставке "СвязьЭкспоком", что проводится ежегодно, производители устройств открыто говорят изделия не обеспечивает контроль качества согласно 90-го приказа Минсвязи. Значит место таким устройствам только внутри предприятий.

>подумай, сколько еще свободного времени останется у Linux после обработки такой платы?

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

Существуют системы реального времени на базе Linux, не давно такую разработку купил Alcatel.

>c факсами хреново, да.

Дело в кодеках, кодеки IP-телефонии сжимают речевой канал до 8 кбит/с и ниже, а факс желает иметь полноценный канал 64 кбит/с. Один человек рассказывал как с одного завода отправляли факсы через системы с AДИКМ, там канал сжимался с 64 до 32 кбит/с, факс приходил примерно такого вида: вверху шапка большими буквами "Трудового красного знамени завод хххххх" далее нечитаемый текст из следов мелких значков, и внизу опять большими буквами "Генеральный директор ХХХХХХ". Приходилось секретарю перезванивать и просить продиктовать текст письма.

>Дело в кодеках, кодеки IP-телефонии >сжимают речевой канал до 8 кбит/с и ниже, >а факс желает иметь полноценный канал 64 >кбит/с

ой америку открыл) именно для этого существует t.38 и fax redundancy. Именно с ними астериск не работает. Операторы телефонии обычно заботятся о поддержке факсов(если это не очередной криворучко повелся на tario.net).

В общем, с позиции телефонного оператора астериск конечно полное г. Никакой масштабируемости, но он и позиционируется как небольшая (абонентов эдак на 200-300 ;) многофунциональая ip-pbx. Забесплатно, да еще и исходниками,вы получаете то, что продает,например, авая за весьма немаленькие деньги(ipoffice).

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

Codec Support GSM G.729 (available through purchase of commercial license(s)) G.723.1 (pass through) Linear Mu-Law A-Law ADPCM G.726 ILBC LPC-10 MP3 (decode only)

и где здесь Дефолт ?

По поводу Cisco не надо грязи - T38 замечательно работает и факсы ходят даже с аппаратов поддерживающие режимы команд на V.21 не в Т-рекомендации.

>Linear Mu-Law A-Law ты в курсе что это и есть g.711 ?

А по поводу циско - надо. Видишь ли, циска разделяет voip и ip-телефонию. Первая операторский бизнес, вторая это корпоративные системы, это другой софт, другие требования и порядки.

Так вот,вторая(callmanager) t.38 не поддерживает нихрена!

>А по поводу циско - надо. Видишь ли, циска разделяет voip и ip->телефонию. Первая операторский бизнес, вторая это корпоративные >системы, это другой софт, другие требования и порядки.

Безусловно - как разделяет два понятия Voice Gateway и Call Manager.

>>Подобная фраза говорит о том, что vlad_ts ничего не смыслит в IP телефонии.

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

Sigh. Я понял, здесь все мыслят масштабами корпораций, при этом ни разу не увидев call центра больше чем на 5-10 потоков(5*31 таймслот ~ 150 абонентов).

>>попробуй посчитать, какова "толщина" одного E1 канала

>Нет желания считать, мне часто приходится иметь дело с потоками Е1 с разной "начинкой" от сельских ЦСП до BTS GSM.

Ну допустим 2мбит, умножаем на 120 - 240мбит в пике. Когда-то я писал про производительность pci-x здесь... В общем, Linux это проглотит и даже не заметит. Впрочем, _любая_ современная ОС это проглотит и не заметит, будь то винда или упинавшийся qnx. (Кстати, в винде с компрессиями, у которых продолжительность фрейма меньше 30мсек, работать невозможно - слабенькая она, не может задачи так быстро переключать).

>>Некоторые платы могут делать до 120 каналов E1.

>Видел такие изделия, даже отечественного производства их не мало, но они не удовлетворяют нормам ITU. На выставке "СвязьЭкспоком", что проводится ежегодно, производители устройств открыто говорят изделия не обеспечивает контроль качества согласно 90-го приказа Минсвязи. Значит место таким устройствам только внутри предприятий.

Ну вот снова... Слышал звон... Товарищ, _никто_, я повторяю, _никто_, не станет покупать такое оборудование. А на выставках показывают только то, что собираются продавать. Так вот, по крайней мере на той выставке, что была в 2004 году, качество оборудования было очень даже на высоте. Я не могу сказать, что пинал каждого производителя на предмет этого приказа, но все уважающие себя игроки поддерживают планку на нужном уровне.

>>подумай, сколько еще свободного времени останется у Linux после обработки такой платы?

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

Хе-хе, очевидно, что выше максимальной нагрузки эта плата не прыгнет. А максимальная нагрузка на одну плату приведена выше. Итого имеем, что при мксимальной аппаратной нагрузке у ОС остается еще вагон времени. Например можно софтверно OpenH323 пгонять или факсы декодировать... одним словом остается еще куча времени на обработку самого потока.

Что-нибудь говорит возможность мониторить stm-1/stm-4 поток? Тк вот существуют решения как раз на базе Linux.

>Существуют системы реального времени на базе Linux, не давно такую разработку купил Alcatel.

Дело в том, что QNX не подойдет для таких задач. Более того, QNX - это всего лишь рекламный ход, дескать мы риалтайм. А на деле - пшик, я не собираюсь рассказывать о недостатках последнего, просто скажу, что их настолько много, что ни один серьезный производитель _это_ использовать не станет. Но на лоре можно ввернуть такое модное словечко, как реалтайм и qnx.

Vlad_Ts (*) (26.09.2004 9:32:26)

Anonymous.

Alcatel Omni PCX office уже под пингвином

Вот тут про QNX поподробнее... открой глаза "слепым".

--

scamp

> типа Дефинити программная?
гыыы! братело - а ты знаешь что у дефы унутри UNIX?;)

> сколько еще свободного времени останется у Linux после обработки такой
> платы? Да на нем еще видео смотреть в несколько потоков можно будет...
не говори гоп:
http://lists.digium.com/pipermail/asterisk-users/2004-March/039799.html
http://lists.digium.com/pipermail/asterisk-users/2004-March/039811.html
тут есть некоторые нюансы.
например, всего 1 Digium E100P создаёт горзадо большую нагрузку чем оба Eth на рутере где всё это стоит хотя суммарно трафик через eth больше.

Буга-га, 1000 прерываний в секунду - в 2.6 таймер генерит столько же :)

На той плате, с которой я неосредственно работаю, прерывания генерятся 8000 раз в секунду и выкачивается бОльший поток данных. А там установлен ppc405 200mhz - без проблем справляется.

Кстати, у eth прерывания могут генериться существенно чаще, чем 10000 раз в секунду, другое дело, что там данные выкачиваются с помощью DMA, а из DSP они так не всегда забираются(imho, чаще с помощью iDMA).

Кстати, касательно Digium - выкачивать 8 байт неэффективно как с помощью DMA, так и простым копированием из замапленной памяти DSP, но возможно, что в их железки просто очень маленькие циркулярные DSP буфера(хотя на 84 ad уже можо сделать до нескольких десятков байт). Но не мне судить разработчиков Asterisk.

И как ты определил, что один Digium создает бОльшую нагрузку?

Только это плата не E1, а embedded монитор цифровых линий на 8-16 каналов. Многоканальные Е1 делаются в хостовом варианте.

гыыы! братело - а ты знаешь что у дефы унутри UNIX?;)

И что дальше? У Циско ИОС внутри стоит. Аппаратная реализация и программная не этим отличается. Тебе дали железо. Которое подогнано, где не надо с дискетками бегать для установки. Где не надо с бубном плясать почему ядро не поддерживает того или иного производителя. Это аппаратное решение. Любое аппаратное решение управляется софтом, гыыыы-ты не знал об этом?

QNX поподробнее

> Вот тут про QNX поподробнее... открой глаза "слепым".

Где именно? Хотелось бы почитать про недостатки?

Здесь о QNX и о Cisco:

http://www.swd.ru/qnx/press/news/200408_23.html

Факсы в Asterisk тоже есть:

ftp://ftp.opencall.org/pub/spandsp/

> как ты определил, что один Digium создает бОльшую нагрузку?
ьтак очень просто - у него в 10 раз больше interrupts :)
и это намеренно - иначе не будет возможности многие необходимые вещи на лету делать типа обработки E1
> у eth прерывания могут генериться существенно чаще
могут. но не генерятся. потмоу что 8 байт существенно короче чем 40 октетов :-)

> Аппаратная реализация и программная не этим отличается.
гыыы.;)
можете не продолжать - я знаю чем отличаются аппаратные и программыне реализации. типичная аппаратная реализация - switch на asic. например catalyst 2950.
касательно Cisco routers - они НЕ АППАРАТНЫЕ РУТЕРЫ!
именно потому что логика принятия решений там выполняется программой.
GSR - особый случай. экклетеизм и компромисс.:)
я уже пару лет прошу показать мне апппартынй рутер - чегой-то не показывают.:-)

>> как ты определил, что один Digium создает бОльшую нагрузку? >ьтак очень просто - у него в 10 раз больше interrupts :) и это намеренно - иначе не будет возможности многие необходимые вещи на лету делать типа обработки E1

У сетевушки 100 прерываний в секунду? :) Маловато-то что-то... Хотя там наверное трафик от пары машин, смотрящих web...

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

>> у eth прерывания могут генериться существенно чаще > могут. но не генерятся. потмоу что 8 байт существенно короче чем 40 октетов :-)

Буга-га, а вот и не угадал. В сетевой карте данные забираются с помощью DMA, так что размер пакета всем абсолютно фиолетово(конечно в определенных рамках). Контроллер DMA всегда висит на очень быстрой шине, в то время как DSP - на весьма узкой в плате, и забираются оттуда данные по 8 байт за прерывание(в Digium) без DMA.

Ладно, завершаем раззговор. mumpster, ты что сказать-то хотел, что 1000 прерываний в секунду - это много? Нет, это очень мало. Что digium создает бОльшую нагрузку чем ethernet? Спорный вопрос, но возможно, и дело здесь не в количестве прерываний в секунду, а в той работе, которая в это время проводится - в этих драйверах работа идет неоптимально, но, видимо, это всех вполне устраивает.

Seagate

> У сетевушки 100 прерываний в секунду? :)
я нигде не сказал что в секунду. я сказал что суммарно.
вообще , eth0=eth1+hdlc0+внутренний трафик если Вам формула нужна
> В сетевой карте данные забираются с помощью DMA
понятно, вогороде бузина это называется.
как бы не забиралось - в конце цикла DMA будет IRQ.
так что если Вы только не опросом исключительно этой платы заниаетесь - IRQ у Вас всёравно будут.
соответственно это выгодно при больших размерах пакетов.
меньше 40 быть не может на эзере. как правило даже больше.
уже одно это даёт эконмию как минмиум в 5 раз. что мы и видим.
> что 1000 прерываний в секунду - это много?
на канал E1 - да. приедствьте что у ва их 24.:-)
> Что digium создает бОльшую нагрузку чем ethernet?
совершенно верно.
> работа идет неоптимально
нет. там это сделано намеренно и этостоит учитывать когда думаешь чего взять под asterisk pbx.

>> У сетевушки 100 прерываний в секунду? :)

>я нигде не сказал что в секунду. я сказал что суммарно. вообще , eth0=eth1+hdlc0+внутренний трафик если Вам формула нужна

Сумарно за какой промежуток времени?

Процитировать? E1 - 1000 прерывайни в секунду, "это много, в eth в 10 раз меньше".

>> В сетевой карте данные забираются с помощью DMA

> понятно, вогороде бузина это называется. как бы не забиралось - в конце цикла DMA будет IRQ. так что если Вы только не опросом исключительно этой платы заниаетесь - IRQ у Вас всёравно будут. соответственно это выгодно при больших размерах пакетов. меньше 40 быть не может на эзере. как правило даже больше. уже одно это даёт эконмию как минмиум в 5 раз. что мы и видим.

Ну ты же не разбираешься в вопросе, ну что же ты говоришь? Наличие прерывания никак не влияет на работу системы, при таких irq rate переключение контекста для системы не заметно. 1000 прерываний с забором 9 килобайт данных по DMA(jumbo frame в ethernet) будет использовать процесор меньше чем 1000 прерываний, в которых выкачивается существенно меньший объем данных, использую iDMA(aka копирование из замапленной памяти с автоинкрементом адреса).

Ну с чем ты споришь?

>> что 1000 прерываний в секунду - это много? >на канал E1 - да. приедствьте что у ва их 24.:-)

У меня их 120 в одной только плате - 8000 раз в секунду влегкую справляется на 2.6 (на 2.4 давно не пробовал). Еще что спросишь?

>> Что digium создает бОльшую нагрузку чем ethernet?

>совершенно верно.

>> работа идет неоптимально

> нет. там это сделано намеренно и этостоит учитывать когда думаешь чего взять под asterisk pbx.

Намерено? Ну-ка расскажите мне, зачем это сделали? А я подскажу - я _думаю_, что каждый байт потока там обрабатывается в прерывании, а следовательно 1000 прерываний в секунду будут(читай могут) создавать большую нагрузку. Это не "намеренно", а по незнанию, лени или еще чего-то...

Ладно, ты, mumpster, как я погляжу тоже товарищ из тех, кто любит просто спорить вне зависимости от

а) своих знаний б) чужих знаний

В вопросе ты не разбираешься, диагноз поставлен.

>>> что 1000 прерываний в секунду - это много? >на канал E1 - да. приедствьте что у ва их 24.:-)

> У меня их 120 в одной только плате - 8000 раз в секунду влегкую справляется на 2.6 (на 2.4 давно не пробовал). Еще что спросишь?

На тот случай, если не понятно - 8000 прерываний в секунду, при этом обработываются все 120 каналов E1. Конечно, они должны при этом обрабатываться не в самом прерывании, чтобы обеспечить системе ненапряжное функционирование. Вот именно про BH(bottom-hlf, tasklet, softirq, worq_queue) я говорил, когда рассказывал про нагрузки.

Впрочем, все, дискуссия завершена.

Уже года два использую все это дело, очень доволен. Особенно IVR на perl-е. Касаемо производительности - то для G.711 (а я именно так использую его) вполне достаточно P4 2+ GHz. Само-собой что на машине кроме как asterisk-а ничего и не крутится.

Я не первый год занимаюсь телефонией и точно _знаю_ что 4xE1 за 1.5K$ это очень дешево.

E1 у них правильные, нормально стыкуются как с офисными станциями так и с операторами связи (проверенно на двух)

Если есть вопросы - могу ответить.

>E1 у них правильные, нормально стыкуются как с офисными станциями так и >с операторами связи (проверенно на двух)

гы, сына, а как же SS7 ? )

Ну SS7 это несколько другой проект, OpenSS7 называется. Таботает на том-же железе.

E1

> а по незнанию, лени или еще чего-то...
нет. это чтобы была большая гибкость при обработке плюс удешевление платы.
а серьзёной нагрузкой при сегодняшних PIV и PCI-X оно не является.
просто про это надо помнить. а в сравнении с eth оно просто грузит больше. это всё что я имел в виду.
> диагноз поставлен.
я уже давно на такую шнягу не ведусь, терапевт Вы наш.:-)

Подскажите, пожалуйста, как добывали карты?