facility

interface Serial 3/1:15 isdn sending-complete

Насколько я понял, AudioCodes больше не пишет нового ПО для H.323. 5.00A.046.007 - это последняя версия для H.323. Поэтому, для тех, кто для своей сети выбрал H.323, AudioCodes - тупиковый вариант.

Они почти ровесники. SIP на полгода младше. Скажите пожалуйста каков был ваш запрос и какова цена предложенного решения (хотя бы примерная)/

Ну зачем же так безапелляционно? Сама технология - вполне ничего :)

А кроме "этого" ?

Тогда может быть ответите на мой предыдущий вопрос?

Перекодирование речи в текст и отправка факсом? Да, конечно! Этакий "автосекретарь"... Вы говорите, а он за вами записывает. Когда не успевает, просит говорить помедленнее... :) Под G.711(IP) я подразумевал "сообщения T.30, кодируемые по G.711 и передаваемые в RTP". Мне так надо было написать? :)

Кто-нибудь знает продукт "а ля" SBC с функцией преобразования G.711(IP) <-> T.38 ?

IOS то хоть какой используете? На сайте Cisco читали предупреждения (caveates) для своего IOS?

AudioCodes ?

УГОЛОВНЫЙ КОДЕКС РОССИЙСКОЙ ФЕДЕРАЦИИ... Статья 200. Обман потребителей 1. Обмеривание, обвешивание, обсчет, введение в заблуждение относительно потребительских свойств или качества товара (услуги) или иной обман потребителей в организациях, осуществляющих реализацию товаров или оказывающих услуги населению, а равно гражданами, зарегистрированными в качестве индивидуальных предпринимателей в сфере торговли (услуг), если эти деяния совершены в значительном размере, — наказываются штрафом в размере от ста до двухсот минимальных размеров оплаты труда или в размере заработной платы или иного дохода осужденного за период от одного до двух месяцев, либо обязательными работами на срок от ста восьмидесяти до двухсот сорока часов, либо исправительными работами на срок от одного года до двух лет.

G.711 подходит не всем. Особенно он НЕ подходит тем, кто использует радиоканалы 802.11, 802.16*. У Вас их, наверное, совсем нет?

Я бы лучше сказал, что разработчики Yate уделяют слишком мало внимания поддержке H.323 в своем продукте. Во-первых, неразумно - упорно продолжать использовать OpenH323, которую уже три года никто не поддерживает. Во-вторых, то, как ведет себя Yate при установке вызова по H.323, часто не поддается разумному объяснению. Например - обмен возможностями по H.245 практически неуправляем.

Не вижу противоречия с написанным мной :)

Нет на этот вопрос однозначного ответа. По отошению к G.711 протокол T.38 дает возможность: 1) передачи факсов на каналах передачи данных с худшими характеристиками, чем требуемые для G.711; 2) оптимально использовать канал передачи данных; 3) увеличить надежность передачи факсов за счет избыточных пакетов; 4) диагностировать процесс передачи факса при помощи sniffer'а а-ля Wireshark. Минусы (по отношению к G.711): 1) повышенная нагрузка на DSP; 2) усложнение логики работы VoIP-устройства и увеличение вероятности появление дополнительных ошибок передачи факса; 3) отсутствие поддержки T.38 в некоторых устройствах/ПО. В общем, если у вас мало полосы пропускания в сети, на вашем оборудовании заявлена поддержка T.38, у вас есть тесный контакт с производителем и желание (и квалификация) с ним (производителем) "бодаться" по поводу стабильности работы T.38, то вам стОит попробовать T.38 :)

С этим трудно не согласиться. Можно добавить, что проблемы передачи факсов с использованием G.711 не поддаются диагностике, т.к. из информационного потока без применения спец. средств (анализаторов) невозможно выделять отдельные сообщения T.30.

эээээм.... а чуть попроще объяснить?) Попроще... Вы представляете что и с чем пытаетесь соединить?

Нет схемы организации связи с указанием протоколов сигнализации. Это корень всех бед.

Это все, что Вы "намучали" ? Не огорчайте общественность! :)

Мне тоже верится с трудом, но я бы не отказался попробовать. Например, вот это - http://www.commetrex.com/products/ctmiddle...rboprodbul.html. Может кто-то уже пользовался и знает. Хотя, пробовать нужно, только до конца осознавая кол-во цифр в ценнике, расположенных до десятичной запятой. Игрушка может оказаться слишком дорогой. Кстати, функции преобразования протоколов сигнализации и функции перекодирования информационных потоков можно разнести на разные элементы сети. H.323 в SIP - это скорее функция SBC, которому не обязательно быть оснащенным DSP. А G.711 в T.38 (и наоборот) - это уже нужно возлагать на media-шлюзы с DSP. Держать все в одном флаконе, наверное, не нужно из разных соображений.

Вопрос риторический. В теории - T.38 является специализированным протоколом для передачи факсов в режиме реального времени. Соответственно, призван повысить надежность их передачи. На практике - существует масса кривых реализаций протокла и куча проблем взаимодействия оборудования, которые иной раз сводят на нет все преимущества T.38. В общем, не так плохи протоколы, как их реализации :)

Приветствую! Кто-нибудь решал проблему преобразования методов передачи сигналов DTMF: RTP NTE <-> H.245 UII ? Можно ли это реализовать при помощи какого-либо свободного ПО под Linux или при помощи Cisco IP-to-IP Gateway (2821) ? Другие варианты решения тоже интересно услышать.

Кто-нибудь пользовался? Какие впечатления? Поставщики на территории РФ имеются?

Почему именно в Ulaw ? :)

1. Глупый вопрос: Asterisk поддерживает/настроен на SIP/TCP ?2. Можно "вот такое" записать при помощи wireshark? tshark -Vf "tcp and port 5060"