Какой VoIP шлюз взять? 8xE1

[Drg]

Добрый день, уважаемые.

 

Просьба поделиться своим опытом.

Стою перед выбором железа для апгрейда стыка ТфОП и VoIP сети.

 

Требования:

- 8 потоков Е1 (ОКС7 не нужен);

- SIP/H.323;

- Корректное хождение факсов T.38 (очень желательно);

- Аппаратное эхоподавление.

 

Пока рассматриваю следующие варианты:

1. Cisco AS5300 (8xE1) - $25 000

2. AudioCodes Mediant 2000 (8xE1) - $20 000

3. Сервер (с *) + Sangoma 108D (8xE1) - $6 500

 

По пунку №1 - все понятно, Циска, все может, стабильно, привычно.

Но, цена... Я не жадина, но жаба душит. И если есть достойная альтернатива,

то почему бы не экономить?

 

По пункту №2 - стабильная железка, дешевле Циски. Но. Может

либо SIP, либо 323. 323 нужен сейчас, а вот SIP в ближайщем

будущем понадобиться. И при таком раскладе придется докупать

такую же железку но уже с SIP. Либо устанавливать в сети отдельный

конвертор сигнализацией, что не очень хочется.

 

По пункту №3 - дешево, сердито, гибко. Но факсы по 323 в Т.38 не ходят.

Я так и не нашел даже коммерческого варианта Астериска с полноценной поддержкой факсов.

Пытался написать в http://www.attractel.com/t38.html с просьбой прислать цены

и подробное описание, пока ноль внимания - фунт презрения (наверно празднуют).

 

Какие еще есть варианты, что можете посоветовать по своему опыту?

[ram_scan]

Есть еще AddPac AP3800 и на этом варианты кончаются.

 

По 3 варианту - на 8 потоках машина захлебнется в прерываниях от карточек, голоса не будет вовсе, не говоря уже о факсах и транскодировании.

 

По 2 варианту - железки вроде неплохие, но страшно однобокие, если свяжешься то это "игла", то такую приблуду ей надо, то сякую, более одного протокола сигнализации не держит, IVR соорудить на ней - медиасервер докупай ну и так далее.

 

Так что советую придушить жабу и брать все-таки пункт 1. Оно дешевле потом выйдет. Только вот меня гложут аццкие сомнения что в 5300 можно поставить нужное количество dsp. То есть там можно получить 8 потоков, но поскольку двухпоточный модуль имеет только 30 dsp на борту получить больше 120 dsp не удастся.

Edited December 27, 2007 by ram_scan

[Солнечный КОТ]

на такое колво проще взять 54хх вроде бы

[nwton]

Если не ошибаюсь, то 5300 умеет только 4 потока на голос, а 8 потоков - только если как диалапный пул использовать (платы dsp для голоса просто некуда пихать).

Может как вариант - использовать Cisco 28хх, правда в 2851 на 8 потоков не заработает, проца уже не хватит, но это вроде как самое дешевое решение получается (из новых, а не б/у).

 

По поводу астериска - какие-то англичане год назад предлагали быть их дилером, там железка на 2 потока стоила около 3К евро, обычный инудстриал-писюк в комплекте с Е1 платами и астером настроенным, типа все круто и все работает... Вот только на тест не дали пощупать, предложили купить сначала :)

 

Лично мое мнение - если так хочется экономить, то 8 железок mc3810 под полный поток по 500-600 баксов обойдутся еще и дешевле чем сервер с астериском, а надежность будет такая же, правда только h323 :)

[Drg]

Есть еще AddPac AP3800 и на этом варианты кончаются.

Спасибо, сейчас буду изучать описания и отзывы по этому шлюзику.

 

По 3 варианту - на 8 потоках машина захлебнется в прерываниях от карточек, голоса не будет вовсе, не говоря уже о факсах и транскодировании.

Немного не согласен. Не захлебнется. Вот данные по Сангоме от вендора -

 

-----------------------------------

Допустимые нагрузки.

 

Плата с 4 портами Е1 - (A104D).

Плата с 8 портами Е1 - (A108D).

 

Системные нагрузки/потребление, используя Xeon Processor.

 

1. Используется 15 Mhz для 1-го TDM канала (Zap).

2. Используется 30 Mhz когда идет обработка с ПО echo canceller.

3. Используется 0 Mhz когда идет обработка с Аппаратным echo canceller.

4. Используется 30 Mhz для TDM в SIP преобразование и наоборот.

 

Если используется аппаратный echo canceller, при звонке с SIP устройства в TDM, то этот процесс потребляет 45 Mhz (15 Mhz для Zap + 30 Mhz для конвертации TDM - SIP).

 

Для каждого E1 требуется 15 Mhz x 31 канал = 465 Mhz

Для 4xE1 (A104D) = 4 x 465 = 1.8 Ghz

Для 8xE1 (A108D или 2 x A104D) = 8 x 465 3.6 Ghz

 

Требование к оперативной памяти - 256 Mb на каждый E1, т.е. 1Gb на каждую плату A104D и 2Gb на 108D.

-----------------------------------

[nwton]

Ну тогда требуйте от вендора сразу комплект в виде платы и компа + минимально настроенный астер.

Если он действительно хочет продать эту плату, то пойдет Вам навстречу...

[MrCloud]

MC3810 работет макс с 24-мя таймслотами, с т38 возможны заморочки.

 

AS5350/5400 - выш выбор. Могу предложить AS5400-8E1-210-AC ~ $16500-17К; AS535-8E1-210-AC ~ $18500.

 

Если хочется дешево-сердито то можно взять тупые дешевые Е1 шлюзы (наши делают, могу поискать найти контакт, 2-3К за 1Е1 или платы к *) которые нормально работают с g.711, дополнительно купить altertex.ru alterPSS который вам будет делать все (IVR, transcoding, sip<->h.323, g711<->g729&t38, RADIUS и на рояле играть).

Edited December 27, 2007 by MrCloud

[UglyAdmin]

Если не ошибаюсь, то 5300 умеет только 4 потока на голос, а 8 потоков - только если как диалапный пул использовать (платы dsp для голоса просто некуда пихать).

Платы с DSP для 5300 есть двух типов... и на 8 потоков хватает.

[Andrei]

Если хочется дешево-сердито то можно взять тупые дешевые Е1 шлюзы (наши делают, могу поискать найти контакт, 2-3К за 1Е1

Имеется ввиду - http://www.prominform.ru/index.php?id=1103...g=100&lng=0

У меня такой стоит, правда только с 711 кодеком (уже есть версии с 729м, но дороже). Показал себя неплохо. Правда Е1 у него только EDSS1.

Правда сертификат у него странноватый - только в составе Call-центра и для оказания услуг местной телефонной связи не прокатит. Но производитель обещает получить другой сертификат.

Edited December 28, 2007 by Andrei

[edo]

По 3 варианту - на 8 потоках машина захлебнется в прерываниях от карточек, голоса не будет вовсе, не говоря уже о факсах и транскодировании.

ничего не задохнётся, от многопортовых карточек приходит столько же прерываний, как и от однопортовых.

 

я уже давал ссылку: http://quasar.sourceforge.net/bench.htm

там как раз 8 потоков в sip перегоняли.

 

ps: а вот с t.38 наверное и правда беда.

[ram_scan]

Without echo cancellation and transcoding, и под 100% utilization на достаточно некислом железе. Лагать - будет. Complexity level у 729 кодека - семерка. И даже будь в звезде поддержка t.38 - не потянет оно ее на такой конфигурации.

[edo]

"достаточно некислое железо" слабее наверное всего имеющегося сейчас в линейках intel/amd ;)

а за относительно небольшие деньги можно взять процессор в разы мощнее.

 

транскодинг да, проц жрёт по-страшному. но его можно на отдельное железо вытащить. тем более, что аппартный g.729 для asterisk присутствует.

эходав - можно и железный взять.

 

так что лагать не будет.

 

выпускаются и продаются платы и 16xE1 для asterisk - значит есть такие задачи, более того - asterisk с ними справляется.

[Mikler]

"достаточно некислое железо" слабее наверное всего имеющегося сейчас в линейках intel/amd ;)

а за относительно небольшие деньги можно взять процессор в разы мощнее.

 

транскодинг да, проц жрёт по-страшному. но его можно на отдельное железо вытащить. тем более, что аппартный g.729 для asterisk присутствует.

эходав - можно и железный взять.

 

так что лагать не будет.

 

выпускаются и продаются платы и 16xE1 для asterisk - значит есть такие задачи, более того - asterisk с ними справляется.

Вы сами сказали, что просто так купить плату вставить и заработает небудет. Надо вставлять различные железяки, а это ещё геморой с софтом и допиливание. Ну и грабли с H323, традиционные.

 

Могу предлажить нашу атску со шлюзом VoIP (Каркас, ЦП, БП, TM-IP, 8-ТМ)

Поддерживает, SIP,SIP-T, H323; Умеет T38

Соответственно С Двумя субмодулями TM_IP одновременно может 256 g711 или 128 любой другой кодек, ил 64 t38

[ram_scan]

выпускаются и продаются платы и 16xE1 для asterisk - значит есть такие задачи, более того - asterisk с ними справляется.

Они выпускаются не для asterisk, они для asterisk применяются, точно также как голосовой модем может работать fxo портом. А выпускаются они прежде всего для организации стыков по g703/g704 чтобы поверх ppp или hdlc гонять.

[edo]

с аппаратным эходавом? ;)

[ram_scan]

Аппаратный эходав (как и эходав вообще) на цифровом стыке - оксюморон.

Edited December 30, 2007 by ram_scan

[edo]

ой ли?

всё работало хорошо. пришли мы со своим цифровым стыком. внесли задержку. абонент жалуется на эхо.

[ram_scan]

Это т.н. эффект "дальнего эха". Алгоритмическая задержка возникает при этом не в цифровом стыке, а в кодеке, который работает на данном цифровом стыке и эхо провоцирует. И эхокомпенсатор должен по уму быть именно в кодеке. То что он технически реализован со стороны цифрового порта экономически более обосновано, но технически более криво, так как 1) не позволяет менять параметры эхокомпенсации в зависимости от входящено направления и 2) заставляет выдумывать разнообразные алгоритмы тренировки и адаптации, усложняя компенсатор, в результате чего от эха избавиться один хрен толком не удается. И не дай бог еще усиление со стороны аналогового порта покрутить...

Edited January 4, 2008 by ram_scan

[edo]

стоп-стоп. какой ещё кодек на цифровом стыке? чаще всего приходит alaw, уходит alaw. ибо это стандарт у телефонистов использовать на ip что-то более качественное или экономичное смысла нет - качество ограничивается телефонной частью, а ip-каналы обычно жирные.

 

или я с прямым углом перепутал? ;)

[ram_scan]

Речь идет о VoIP. Процедура инкапсуляции таймслота в RTP пакет и его компрессии имеет алгоритмическую задержку. Сильнее всего эхо проявляется на кодеках с высоким уровнем компрессии (и как следствие с высокой алгоритмической задержкой),

[edo]

алгоритмическая задержка у инкапсуляции нулевая. у компрессии в случае g711 тоже ;)

[ram_scan]

Edo, все-таки советовал бы изучить матчасть. Алгоритмическая задержка не может быть нулевой. У большинства кодеков алгоритмическая задержка сводится не только к затратам времени на компрессию, но и к тому, что один компрессированый RTP пакет уже по стандарту содержит более одного сэмпла (например для g729 два, это уже 30 мс задержки), а у некоторых кодеков содержит нецелое количество некомпрессированых пакетов (например в g723.1 в один RTP пакет кодируется 240 сэмплов вместо 180) . Плюс антиджиттер буфер. Плюс время на полный прием пакета, реордеринг и отправку, плюс значение пэйлоада даже для 711 кодека может отличаться от единицы (что практически всегда делается на кодеках с высоким коэффициентом компрессии чтобы уменьшить оверхед, группировка по 2 пакета позволяет сбить его почти на 40%). Плюс кодеки с высоким коэффициентом компрессии всегда практически работают на основе CELP алгоритма, а ему для работы необходимо знать предыдущий фрейм чтобы раскодировать текущий, то есть такой кодек всегда работает "на фрейм позже". Вот оттуда оно и берется. Даже если затраты на математику вообще нулевые.

 

На практике 711 кодек дает действительно минимальную алгоритмическую задержку, это правда. Порядка 5-6 мс в реальных, но тепличных условиях. Но только в том случае если пэйлоад равен единице, RTT стремящемся к нулю, отсутствии антиджиттер буфера, потерь в канале, выключена inband обработка dtmf и выключен PLC,

Edited January 6, 2008 by ram_scan

[edo]

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

есть ещё вычислительная задержка - связанная именно с вычислениями.

например у подсчёта синуса алгоритмическая задержка нулевая, у получения случайного числа с аппаратного генератора - ненулевая.

 

так вот сама по себе пакетизация порождает алгоритмическую задержку. а добавление хидеров к пакету - нет. с кодеками - g.711 не имеет алгоритмической задержки ни на кодирование, ни на раскодирование. а g.729 имеет. кроме того у g.729 и вычислительная задержка выше, чем таковая у g.711.

[ram_scan]

Все в целом правильно. Но в реальной жизни кодек g711 не ограничивается сферическим конем в вакууме, и для того чтобы пакет прошел через транзит его надо как минимум 1) полностью принять, 2) переклеить айпишные заголовки и 3) отправить. на все про все в условиях близких к идеальным тратится порядка 5 мс.

 

В реальной жизни в самой тривиальной реализации 711 кодека есть механизм антиджиттера и PLC, бывает необходима обработка inband dtmf по результатам которой надо решать что делать с пакетом, дропать или форвардить (и даже out of band dtmf может вызвать задержку из за своей некоторой специфики) и прочие вещи, которые и вызывают алгоритмическую задержку. На проблему надо смотреть в комплексе.

 

То есть в теории разницы между практикой и теорией вроде как никакой. А вот на практике картина получается совершенно обратная. Хотя с 711 кодеками ситуация обстоит в этом плане лучше всего, никто не спорит :-)

 

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

Edited January 7, 2008 by ram_scan