Задача - переход в голос после передачи факса по T.38.

Аб. А (факс передает по T.38 ) D-Link DVG2102 - MVTS II (SoftSwitch) - Quintum CMS960 (Trunking Gateway) - TDM - Аб. Б (факс принимает)

- Аб. А снимает трубу и набирает номер аб. Б.
- устонавливается голосовое содединение (т.е. прм/прд факса будет осуществляться в ручном режимена обоих сторонах);
- Аб. Б жмет START и кладет трубку на рычаг, его факс начинает пищать сигнал DIS;
- CMS960 обнаруживает сигнал факса и шлет в сторону DVG2102 SIP INVITE T.38, а тот его принимает и происходит переход на факсовый кодек T.38;
- Аб. А слышит писк и жмет START, но трубку не лкадет на рычаг (или кладет, но снова снимает. когда передача факса подходит к концу);
- факс аб. А обнаруживает сигнал DIS и отвечает DCS (типа, что он будет передавать);
- факс аб. Б обнаруживает сигнал DCS и встает в режим приема;
- факс аб. А передает настройки и тренинг (короткое сообщение с заранее определенным содержанием на выбранной скорости);
- факс аб. Б, если его все устраивает (он нормально принимает тренировочное сообщение на заданной факсом аб. А скорости), отвечает сиганалом CFR (Confirm - подтверждение);
- факс аб. А обнаружив CFR начинает передачу полезного сообщения;
- Когда факс аб. А видит конец документа, то он передает факсу аб. Б сообщение EOP (End of Procedure); Причем, если трубка аб. А не на рычаге (как в нашем случае, т.к. именно аб. А заинтерисован в дальнейшем проконтролировать прохождение сообщение в голосовом тракте и не кладя трубку на рычаг он тем самым сообщает о своем желании еще поговорить своему факсу), то сообщение идет вида Procedure Interrupt-End Of Procedure (124), иначе, если бы трубки обоих абонентов лежали на рычагах, то был просто End Of Procedure (116);
- В ответ на EOP (Procedure Interrupt-End Of Procedure) факс аб. Б генерирует сообщение PIP (Позитивное прерывание процедуры, - "Чтобы указать, что сообщение было получено, но дальнейшая передача невозможна без вмешательства оператора.", - и бла-бла-бла, цитата из рекомендации ITU-T T.30-200509);
- DVG2102 получает PIP, но ничего не предпринимает; В этот момент в трубках факсов тишина; С момента прохождения документа (генерации EOP) уже прошло 5-10 сек - это нормально - оно так и описано, что процедура пост-сообщения занимает до 10 сек;
- Спустя ровно 40 сек тишины (не все могут это вытерпеть, особенно если бизнесс зависит на 70% от факсов) CMS 960 генерит в сторону DVG2102 сообщение SIP INVITE Voice (G.711A), которое резко воспринимается и осуществляется переход в голосовой режим.

Внимание вопрос: с точки зрения стандартов: DVG2102 должен отреагировать на PIP и сгенерить свой INVITE Voice или CMS960 должен сгенерить INVITE Voice сразуже после PIP?

P.S.: Все сообщения типа DIS, DCS, CFR, EOP, PIP нашли свое отражение в реализации T.38 и видны в wireshark. При передаче факса по T.30/bypass этих сообщений не видно (видно только два потока G.711 в обе стороны) и переход в голос после передачи факса идет через 3-5 сек, но переход на T.30/bypass не представляется возможным - не предлагать

_________________
С уважением,
Инженер связи
Давыдов Андрей Андреевич

Была точно такая же проблема. Региональная ТП длинка ответила, что это брак и попросили сдать в ремонт. Поскольку шлюз покупали не мы сами, то его дальнейшая судьба мне неизвестна.

Вот я тоже склоняюсь к тому, что D-Link DVG2102 должен отреагировать на PIP и сгенерить INVITE на Voice-кодек, а то, что INVITE Voice через 40 сек генериться со стороны CMS960, то это скорее всего просто его терпение лопается и он берет ситуацию в свои руки
Ответа от ТП D-Link пока не получил, жду.

_________________
С уважением,
Инженер связи
Давыдов Андрей Андреевич

Наши шлюзы не поддерживают возврат с Т38, только с 711.

_________________
С уважением,
Виктор Колосов

Печально
Благодарю за ответ. Будем думать/искать.

_________________
С уважением,
Инженер связи
Давыдов Андрей Андреевич

И тем не менее есть вопрос!
Если D-Link DVG не поддерживает возможность возврата в голос после передачи факсимильного сообщения по T.38, то какого рожна он при снятой с аппарата трубки формирует не просто End Of Procedure (116), а Procedure Interrupt-End Of Procedure (124), на который потом с ответной стороны генериться вместо MCF (Message Confirm) сообщение PIP, призывающее к переходу на голос?!
Значит поддерживается, но просто недоделана? Может задать вопрос разработчикам и они поваяют прошивочку. чтобы все работало, или скажут как должно работать, указав на ошибки в работе протокола со стороны другого оборудования!

_________________
С уважением,
Инженер связи
Давыдов Андрей Андреевич

Проблема решена переходом полностью с T.38 на G.711 для факсов.
Тем не менее вопрос по переходу в голос после передачи факса по T.38 остается открытым. Ребят из ТП D-Link - попробуйте порешать вопрос там выше. Понимаю, что фича не сильно востребована, но те кто ее хотят выносят моск основательно.

P.S.: Немного о том как же все таки удалось решить проблему:
Схема такая:
Факс А - VoIP GW - SoftSwitch (Mera MVTS II) - TG (Quintum CMS960) - TDM - Факс Б.
На мере для VoIP GW настроен набор кодеков, где отсутствует T.38;
На CMS960 FaxRelay = T.38 with G.711-aLaw;
На VoIP GW (D-Link DVG2102) FaxRelay=T.30.
В этом случае (даже если вызов не проксируется через MVTS II), когда CMS960 предлагает T.38, то MVTS II сама отказывает ему в переходе на T.38 (по SIP - сообщение 508, по H.323 - Reject в ответ на RequestMode (T.38 )) и факс передается по 711 и следовательно переход в голос после передачи факса идет в течении 2-3 сек.
Если в наборе кодеков на MVTS II для VoIP GW присутствует T.38, то она ретранслуриует предложение перейти на T.38 в сторону VoIP GW, а те балбесы (вне зависимости от того D-Link это или люой другой) ведуться и отвечают ACK и пытаются работать в T.38. В итоге факс то проходит нормально, но переход в голос или отсутствует или происходит, но с задержкой в 40-50 сек.

_________________
С уважением,
Инженер связи
Давыдов Андрей Андреевич

У кого как, а я обеими руками за нормальное функционирование T.38

_________________
Я хочу изменить мир к лучшему, но Бог не дает мне исходники (придумал не я)
Asterisk + DVG-4032S + 8xDVG-2032S + ATA Panasonic

Дак и я тоже! Поэтому и пишу, что: "Тем не менее вопрос по переходу в голос после передачи факса по T.38 остается открытым.".
Но клиента заставлять ждать, когда это решиться нельзя - так можно всех растерять

_________________
С уважением,
Инженер связи
Давыдов Андрей Андреевич

В рекомендации ITU-T на T.30 отрыл вот такую вот картинку:



Судя по ней принимающая сторона приняв не просто EOP, а PRI-EOP должна перейти в голос с момента получения PRI-EOP и в этот же момент должна ответить передающей сообщением PIP. Передающая, в свою очередь, должна перейти в голос с момента получения PIP. Полагаю, что PRI-EOP и PIP и есть основания для генерации INVITE (для SIP)/SETUP (для H.323) на голосовые кодеки!

Почему этого не происходит?

_________________
С уважением,
Инженер связи
Давыдов Андрей Андреевич

Андрей, Вы привели аналоговою сигналицацию, в Т38 после передачи факса, отправляющая сторона шлет BYE, после чего сессия рвется.
На данный момент я не знаю ни одного работающего решения, с возврата после передачи по Т38 (про 711 речь не идет).
У нас на данный момент, она тоже не поддерживается.

_________________
С уважением,
Виктор Колосов

Вы правы, данная диаграмма взята из рекомендации Т.30, где описаны алгоритмы взаимодействия между факсимильными аппаратами группы III.
Тем не менее ниже привожу screenshot обмена сообщениями между двумя VoIP-шлюзами и SoftSwitch по SIP с передачей факса по T.38.
Атракцион называется "Найди отличия" - это первое. Второе касается того, что рекомендация T.38 просто ссылается на все алгоритмы T.30 и описывает только методы инкапсуляции/преобразования сообщений T.30 в пакеты SIP (T.38 )!

[img]http://lh6.ggpht.com/_Py_U6W5wCDw/S80dvqfSs7I/AAAAAAAAARI/1unKtsps7Sk/fax%20-%20копия.jpg[/img]

Так что не надо людям говорить, что это невозможно! Это должно быть возможно и оно возможно - на 2102 (на приведенном screenshot 10.227.9.9 - это D-Link DVG2102) оно работает, но с небольшими недоработками (INVITE для голосовых кодеков генериться поздно - на 149-й секунде, а не после получения PIP - на 116-й секунде)!

_________________
С уважением,
Инженер связи
Давыдов Андрей Андреевич

Если цитируете мои слова, цитируйте правильно. Я не говорил, что это невозможно, не нужно переиначивать мои слова.

1. Я сказал, что на данный момент не знаю ни одного рабочего решения
2. На данный момент, мы его так же, не поддерживаем.

Возможно в будущем, что то изменится.

_________________
С уважением,
Виктор Колосов

Не цитировал, честно Просто я их так понял, как написал выше.
Рабочего решения тоже не встречал
Может попробуем его сделать на D-Link?! - думаю будет хорошее конкурентное приемущество

P.S.: Со своей стороны помогу оттестировать и в дальнейшем всем советовать D-Link как оборудование, соответствующее всем требованиям и доступное практически каждому

P.S. 2: По сути всего-то надо, если я не ошибаюсь, отреагировать пакетом INVITE на голосовой кодек в сторону опонента после получения PIP.

_________________
С уважением,
Инженер связи
Давыдов Андрей Андреевич

К сожалению, задач типа "всего-то" уже несколько, только каждой надо заниматься, а мотивации к этому у тех, кто может этим заняться, нет.

_________________
Я хочу изменить мир к лучшему, но Бог не дает мне исходники (придумал не я)
Asterisk + DVG-4032S + 8xDVG-2032S + ATA Panasonic