facility

пришлите в личку ваш емайл - я вышлю мануал на R32 Я не хочу читать всю документацию (у меня и так есть что почитать :)). По-моему, я вполне конкретно задал простейшие вопросы, и мне совершенно непонятно почему из ответов на них нужно делать секрет. К тому же, если Вы тут взялись проводить "агрессивный маркетинг", то уж будьте добры отвечать на вопросы потенциальных покупателей.

На сайте http://www.gohigh.ru очень много интересного о Китае, но, к сожалению, мало полезного про оборудование. Каким образом через H.323 осуществляются "трансфер, call waiting" ? H.450.* ? Если H.450, то "до какого места" он у вас реализован?

Мне тоже очень интересно, т.к. по моим данным никакого SIP'а даже в планах нет.

Вникать никто не будет. В результате разлетится молва, что у вас в момент разговора в трубке "кваканье и хрюканье" и клиенты не будут покупать у вас телефоны.

Avaya Definity или Avaya Communication Manager ? Если второе, то li node-n disp sig <номер signaling-group с CCM> disp tru <номер trunk-group с CCM>

Отквосить трафик в направлении от шлюза до магистрали.Конкретно вышеописанным действием - раскрасить иcходящий от аддпака с DSCP=46. А что? Если речь идет только про VoIP-трафик, то... для APOS существуют команды: ip-tos sig value b8 ip-tos rtp value b8 то же самое для APOS G2: ip tos signaling 0xb8 ip tos rtp 0xb8 b8 или 0xb8 - значение поля DS целиком. при этом DSCP=46, что инструктирует маршрутизаторы использовать PHB=Expedited Forwarding (срочная пересылка). Если про весь трафик, то, увы, стандартных средств не знаю...

show inventory

А H.450 оно поддерживает?

как сделать занятие каналов нечетным при входе и чентым при исходящих, (как требует телеком) тоже непонятно..техподдержка никакая... Это как раз понятно - присвоить направление исходящей связи только четным каналам. Весьма базовая поддержка ISUP. Хотя у кого она полная :) Очень мало команд управления (есть расхождения синтаксиса с документацией). CGB/CGU/GRS и т.д. сделать нельзя. Не понятно как его мониторить. Свой инструмент, мягко говоря, слабоват. Есть непонятные моменты с исходящей обработкой - работает не так, как написано в документации. Радует, что можно легко записать отладку протоколов. Огорчает, что нет возможности группировать сообщения протоколов сигнализации в рамках одного вызова (или я не понял как это делать). При большой нагрузке на коммутатор поиск сообщений утомляет... Вцелом, для преобразования DSS1 - ISUP годится. С тех.поддержкой не общался, но видимо пора...

Как правило, большинство дополнительного функционала предоставляется с использованием закрытых протоколов, которые, скорее всего, Softswitch не поддерживает. Вам бы лучше либо всех пересадить на Avaya, либо всех пересадить на Cisco. Что лучше - решайте сами, исходя из требуемого функционала, масштабируемости, цены и т.д.

+ геморроя на 5000 руб за порт.

Попробуй: voice rtp send-recv dial-peer voice N pots voice cut-through alert dial-peer voice M voip voice cut-through alert Только справочная, скорее всего, PROGRESS'ом разговаривает. Для этого должно быть достаточно voice rtp send-recv.

Нда... Вообще, черт ногу сломит в этой отладке :) Не увидел 180 Ringing от 1750 в сторону 3640 и соответственно - сообщения ALERTING от 3640 в сторону PSTN. В PROGRESS конечно тоже можно запихнуть КПВ, но это как-то, на мой взгляд, неправильно :) P.S. А вы что, простите, транзит ISUP через SIP пытаетесь сделать?

Соединительная линия, она же МСС, организованная на одном порту Е1 способна пропустить трафик, создаваемый абонентами не более, чем с 300 абонентских номеров, с допустимой величиной отказов. Так понятнее? Почти понятно. Только номера к СЛ имеют слабое отношение :) В разделе "Телефонные сигнализации": ISDN PRI ETSI/EURO ISDN, ANSI NI2, QSIG, SIGTRAN (IUA) http://www.audiocodes.ru/audiocodes_mediant1000.html В брошюре то же самое: http://www.audiocodes.com/Objects/LTRT-003...iant%201000.pdf

Узнайте лучше про поддержку VoIP на этих "АТС Меридиан". Вам тогда Cisco 2650XM вообще не нужно будет. Обойдетесь только, как вы говорите, "совтсвичом" :)

Не более 300 номеров на 1 Е1. Если бизнес-абоненты, то меньше. "Поток E1" абонентов "не поддерживает" :)Если его использовать как ISDN PRI, то он дает возможность установить 30 одновременных вызовов.

В условиях так же не сказано про наличие собственной PDH/SDH сети, по которой можно организовать доставку потоков E1 от AS5350 до каждой АТС из "корпоративной сети". Еще в конце сообщения написано: Вот я и подсказываю более разумный (с моей точки зрения) способ :)

Никогда не стало :)Мне просто стало не понятно зачем связываться с TDM, т.к. "через себя подключить корпоративную сеть АТС" можно и не по E1, а по IP.

Зачем для "voip-voip" какое-то дополнительное железо, кроме абонентского ТА и ПО, которое будет управлять обслуживанием вызовов? Если все по VoIP, зачем связываться с конвертацией IP-TDM ?

Разрешите высказать свое мнение: не стоит "толкать телефонию" ради самой телефонии. Тут надо мыслить как В.И.Ленин, т.е. "видеть далеко на много лет вперед" :) Это сейчас вам кажется, что вы понаберете дешевого "VoIP-металлолома", запустите услугу в режиме "базовый вызов" и всем станет хорошо. Подумайте сначала чем вы собираетесь конкурировать с другими участниками рынка и с "разрушителями рынка" (я имею в виду злополучный Skype). Отсюда должны сформулироваться требования к функционалу оборудования. Из требований к функционалу сформулируются "протоколы и торговые марки производителей" :)

Судя по написанному, из России ;)

Не знаю как это звучит по-правильному - телефонию. =) Соединиться по ОКСу с СТК всякими и вести "правильную" жысь. Клиентов можно и обычной парой, и там с помощью voip-технологий. Конкретно с решением пока не определились. Да и решать не я буду. Но мне потом это хозяйство эксплуатировать. =) Протей позиционирует свой одноименный АПК как NGN-решение, что подразумевает в первую очередь ориентацию на сервис для абонента. Вот и возник вопрос - из каких потребностей выбор пал на Протей. Подключиться по ОКС7 можно и без Протея, хотя конечно эксплуатировать единый АПК, в котором реализована поддержка всех необходимых протоколов и функций, вместо нескольких разных, значительно удобней.

Можно провокационный вопрос: какие услуги на нем оказывать собираетесь? :)

Честно говоря, я не сильно разбираюсь в технологиях, но на уровне моего понимания все выглядит так. Если речь идет о ШЛЮЗЕ, то в идеале должен использоваться протокол управления ШЛЮЗОМ. Почему? Потому, что только тогда станет возможным контроль специфических для шлюза процедур и событий. Например, контроль процедуры сбора адресной информации (набора абонентом цифр номера) до установления соединения или контроль реакции на поднятие абонентом трубки. В H.225.0, H.245 всего этого нет, т.к. и шлюз и IP-телефон там присутствуют под единым понятием "Endpoint", и для этого понятия описаны только общие процедуры: установка вызова, согласование параметров вызова и т.д. Если я не прав, то ram_scan меня поправит :)

Подскажите мне тоже пожалуйста... По моему скромному мнению H.323 v6 чуть ли не всем лучше, чем SIP, но поизучав оборудование (Avaya, Cisco, AddPac), делаю вывод, что производители оборудования не потрудились реализовать полностью хотя бы H.323 v2 (я имею в виду версию, в которой появились дополнительные виды обслуживания согласно рекоммендациям H.450.*). А причина тому, скорее всего, банальная - чем продуманней протокол, тем труднее его реализация и тем дольше срок вывода продукта на рынок. В итоге на рынке куча "SIPо-маталлолома", который весьма дешев, но едва совместим между собой. Это примерно как McDonnald's: с одной стороны - быстро и дешево, с другой - совсем не полезно для здоровья. Я прав или нет?