facility

Только не в мире, а в обществе. Рынок закономерно порождает анархию производства. Оставаясь субъектом рыночных отношений, вы независимо от своей воли будете эту анархию порождать. Можно сколько угодно ругать идиотизм рыночных отношений, но пока существует частная собственность на средства производства он будет присутствовать. В общем, вы не с тем боретесь. Да и не боретесь вовсе, а просто ругаетесь...

Чего тут пояснять? Вы до сих пор не нашли приемлемого решения для организации взаимодействия между H.323- и SIP- устройствами? Если да, то \ Вы попробовали (Asterisk/Yate/FreeSWITCH/что-то еще) ? Если да, то \ Столкнулись с проблемами, которые не можете решить самостоятельно? Если да, то \ Вас интересует чужой опыт в решении аналогичных проблем? Если да, то \ Что именно у Вас не получается?

О проблемах известно :) Вас которые интересуют?

Фраза "нашел гуру" не гарантирует успеха мероприятия в целом. Опишите лучше подробно задачу и ход ее решения. Общественности будет полезно знать возможности/невозможности YATE.

Поскольку я один из "игравшихся" в указанной теме, могу добавить, что YATE больше напоминает конструктор, чем готовый для решения конкретных задач продукт. Что действительно омрачает опыт работы с ним, так это невнятная политика команды разработчиков. Они прячут документацию (раньше ее было больше), не отвечают на вопросы в списке рассылки, и даже не отвечают на предложения купить доработку/поддержку их продукта. Поэтому, реальность такова, что если вы хотите использовать YATE, вам мало знать только SS7. Нужно еще и владеть C++ на приемлемом уровне, чтобы разобраться что и как работает/не работает, и во многих случаях самостоятельно доработать то, чего в YATE нет. Хотите с этим связываться, могу поучаствовать. Только у меня нет опыта работы с подсистемой SCCP, и текущий уровень ее поддержки в YATE я не изучал. Работал только с ISUP.

Если не секрет, почему это тебе перестало быть интересно? ;-)

Еще более глупый вопрос: у вас серверы друг с другом общаются или абоненты? Как организовано подключение абонентов на IPO и CM?

Во-первых, надо использовать H323Plus, а не "7 лет назад брошенный OpenH323". Во-вторых, без записи трафика H.323 и без отладочной информации с YATE - не решить.

Смотрите абзац Parameters: http://yate.null.ro/pmwiki/index.php?n=Main.RegularExpressions#parameters Любой из них может быть использован для маршрутизации. Наример, если "номер звонящего" 12345, то так ${caller}^12345$=h323/98765@1.2.3.4

Это совсем не означает, что внутри речевого канала для вас имеются акустические сигналы, в т.ч. КПВ. Вот если бы было значение 1 (Call is not end-to-end ISDN; further call progress information may be available in-band) или 8 (In-band information or an appropriate pattern is now available), тогда другое дело :)

Разобраться с причной некорректно работы Cisco 2801, устранить ее, установить в нее доп.платы E1 и доп.модули DSP.

Definity CSI c поддержкой VoIP? Есть платы TN799, TN2302?

Не понял что такое "Mera" в данном случае... Например, в MVTS 3.1.4 есть параметр presentation_screening_allowed=1 для user.cfg и gateway.cfg.

Это вся конфигурация Cisco? Мне видится, что у вас нет подходящего dial-peer для маршрутизации вызова.

Тут H.323 непричем. Похоже, что TDA банально глючит. Это последняя версия программного обеспечения для TDA?

IP Office или Aura/Communication Manager?

Без записи трафика я не смогу прокомментировать произошедшие изменения. Лучше при каждой попытке делайте запись. Потом будем вместе разбираться что работает, а что нет. Вы же хотите знать возможности/невозможности эксплуатируемого АПК? :)

tcpdump -i <СЕТЕВОЙ ИНТЕРФЕЙС> -s 0 -w traffic.pcap host <IP-АДРЕС TDA>

Ну кто бы говорил! Наверное помощью можно назвать предложение "засветить в дыню за слово факс"? Или туманные рассуждения о том как "астериск детектирует факс t38 - tcp", в то время как Asterisk поддерживает только T.38 UDP TL? Или ворчание о светлом будущем без факсов, которое так и наступило в 21-м веке? Вы выплеснули тут вагон своих эмоций, а по делу не сказали ничего. Это называется "я нарыл что-то". Теперь думайте сами как это "к делу пришить". Поддержка T.38 поверх TCP является скорее исключением, чем правилом. Обычно производители оборудования реализуют T.38 с использованием только UDP Transport Layer. Это можно считать правилом. Вы случайно не знаете почему?

Я прочитал Ваше сообщение, в котором есть фраза . Поверхностный лексический анализ говорит о том, что Вы считаете поддержку T.38 поверх TCP в VoIP-устройствах само собой разумеющейся. Вот мне и стало интересно в каких устройствах она имеется. Отправлять "ту гугл" конечно можно (хотя это звучит почти как "учите матчасть"). Но дело в том, что если Вы навскидку не можете привести хотя бы один пример, Ваши знания в этом вопросе сразу ставятся под сомнение.

Вы хотите сказать, что используете оборудование, в котором реализован T.38 поверх TCP? Если не секрет, что за производитель/модель?

Не умеет.

Думаю тут надо определиться либо "с VoIP на VoIP", либо "в пределах одного устройства" :) Если первое, то нельзя.

Не знаю как там в FreeSentral... При сборке из исходников нужно 1) собрать PTLib - http://downloads.sourceforge.net/project/opalvoip/v3.10%20Luyten/Stable%207/ptlib-2.10.7.tar.bz2 2) собрать H323Plus - http://www.h323plus.org/source/download/h323plus-v1_24_0.tar.gz 3) собрать YATE, указав в параметрах запуска configure путь к директориям с PTLib и H323Plus

Покопался в коде OpenH323 1.19.0 и H323Plus CVS. Принципиальная разница в том, что в OpenH323 1.19.0, при получении SETUP, обработка h245Address происходит раньше, чем обработка fastStart, а в H323Plus наоборот. Соответствующий фрагмент кода из OpenH323 1.19.0: // Check that it has the H.245 channel connection info if (setup.HasOptionalField(H225_Setup_UUIE::e_h245Address)) if (!StartControlChannel(setup.m_h245Address)) return FALSE; // See if remote endpoint wants to start fast if ((fastStartState != FastStartDisabled) && setup.HasOptionalField(H225_Setup_UUIE::e_fastStart) && localCapabilities.GetSize() > 0) { DecodeFastStartCaps(setup.m_fastStart); } Соответствующий фрагмент кода из H323Plus CVS: // See if remote endpoint wants to start fast if (fastStartState != FastStartDisabled && setup.HasOptionalField(H225_Setup_UUIE::e_fastStart) && localCapabilities.GetSize() > 0) { DecodeFastStartCaps(setup.m_fastStart); } // Check that if we are not doing Fast Connect that we have H.245 channel info if (fastStartState != FastStartResponse && setup.HasOptionalField(H225_Setup_UUIE::e_h245Address)) { if (!StartControlChannel(setup.m_h245Address)) return FALSE; } Ситуация (я теперь сомневаюсь ошибка это или нет) с включением h245Address в сообщение CONNECT при уже установленном канале H.245 в обеих библиотеках одинаковая. Но тут я не ручаюсь, что правильно интерпретировал программный код. Соответствующий фрагмент кода из OpenH323 1.19.0: else { // Start separate H.245 channel if not tunneling. if (!StartControlChannel()) break; connect.IncludeOptionalField(H225_Connect_UUIE::e_h245Address); controlChannel->SetUpTransportPDU(connect.m_h245Address, TRUE); } Перед включеним h245Address в CONNECT идет проверка результата, возвращаемого функцией StartControlChannel(). Если возвращается TRUE, то h245Address включается в CONNECT. Если FALSE, то не включается. Но если канал H.245 уже установлен, StartControlChannel возвращает TRUE. Это видно из следующего фрагмента кода: BOOL H323Connection::StartControlChannel() { // Already have the H245 channel up. if (controlChannel != NULL) return TRUE; ... В H323Plus эти фрагменты не изменились. В общем, могу предположить, что при переходе на H323Plus и использовании Быстрого соединения, вызовы TDA->YATE будут устанавливаться.