Приветствую. Возникла вот такая ситуация. Имеется циска as5400xm, и энное число конечных пользователей, подключенных в AudiCodes'ы (далее АК). Кодесы, соответственно, включены в циску. Основные схемы телефонии выглядят так:
1. АК - Циска - POTS телефония
2. POTS телефония - Циска - АК
2. АК - Циска - АК
Это упрощенно, но для описания проблемы достаточно. Факсы ходили по сети без особых проблем: на кодесах и циске настроен pass-through codec g711alaw. Сеть ОЧЕНЬ толстая (гигабитные соединения на оптическом транспорте), так что задержек и прочего, что могло бы помешать 711-ому кодеку тащить факсы нет вообше.
Однако нарисовался у нас клиент с очень зловредным факсом, который никак не хотел работать при такой конфигурации. Точнее он работал, но спорадично. Решено было поднять t38, чтобы факс общался с кодесом напрямую. На inbound диалпире нарисовали fax protocol t38 ls-redundancy 2 hs-redundancy 2 fallback passthrough g711alaw, настроили кодес и все заработало отлично. Но только в рамках схемы №1 или №2. Схема №3 не работает ВООБЩЕ.
Вот inbound dial-peer:
dial-peer voice 777861202 voip
description Incoming_202
answer-address 861202....
modem passthrough nse codec g711alaw
voice-class codec 3
fax-relay ecm disable
fax rate 9600
fax protocol t38 ls-redundancy 2 hs-redundancy 2 fallback pass-through g711alaw
Вот исходящий диалпир на проблемного клиента:
dial-peer voice 2020300 voip
destination-pattern 7861202....
session protocol sipv2
session target ipv4:192.168.103.11
dtmf-relay rtp-nte
codec g711alaw
fax-relay ecm disable
fax rate 9600
fax protocol t38 ls-redundancy 2 hs-redundancy 2 fallback pass-through g711alaw
no vad
Проблема состоит в том, что t38 поднимается после реинвайта терминирующего кодеса, который слышит, как на его стороне факс стартует в режиме приема. Этот реинвайт получает циска и поднимает t38 на стороне исходящего диалпира - то есть нормально поднимает т38 в сторону терминирующего кодеса. А вот оригинатор (откуда я пытаюсь факс послать), так и продолжает висеть на g711alaw: потому что циска не пытается поднять т38 на этой стороне. Таким образом, нет ни бриджа t38, ни конференсинга. Факсы при таком раскладе не передаются вообще. Кодес фиксирует массу ошибок в РТП, принимая пакеты non-t38 на терминирующей стороне и пакеты с неизвестным payload type на оригинирующей.
Внимание вопрос:
Реально ли организовать прозрачный бридж (voip)t38 - as5400 - t38(voip) в моих условиях, или нужен сторонний софт/оборудование?
Заранее спасибо за советы и помощь.
