Разговор после отправки факса по T.38

Обсуждение железа, технических аспектов работы сетей связи
dogmeat1982
Форумчанин
 
Сообщения:
374
Зарегистрирован:
24 апр 2008
Откуда:
г. Екатеринбург

Благодарил (а): 27 раз.
Поблагодарили: 13 раз.

Разговор после отправки факса по T.38

Сообщение:#1  Сообщение dogmeat1982 » Чт 15 апр, 2010 10:50 »

Не совсем про железо (да простят меня модераторы :shuffle: ), но вопрос, думаю, интересный.
Некоторые люди пользуются такой "фичей", как возврат в голос после отправки факса в ручном режиме для того, чтобы получить голосовое подтверждение о том, как прошел факс.
Данная функция отлично отрабатывает, если факс передается в режиме bypass по T.30, но косячит при передаче факса по T.38.
Практически все железки после работы по T.38 встают в глухую оборону и либо совсем в голос не возвращаются, либо возвращаются, но с задержкой в 40-50 сек, что неприемлимо.
При детальном анализе проблемы удалось выяснить следующее:
после отправки факса передающая сторона генерит пакет EOP или I-EOP (если трубка снята, то I-EOP - конец документа с запросом вмешательства оператора, а если трубка лежит на рычаге, то просто EOP). Простой EOP подтверждается принимающей стороной пакетом MCF и далее следует DCN и разъединение, а вот на I-EOP принимающая сторона генерит PIP. Далее пауза в 40-50 сек, пока одна из сторон не сгенерит INVITE (для SIP)/SETUP (для H.323) на голосовые кодеки.

Внимание! Вопрос: кто и после чего должен первым сгенерить INVITE (для SIP)/SETUP (для H.323) на голосовые кодеки? :-k:

В описании рекомендаций ITU-T T.30 и T.38 не смог этого найти. Описание T.30 к VoIP вообще не имеет отношения, а рекомендация T.38 в основном описывает как сообщения T.30 преобразуются в T.38, а схем и даиаграмм уже нет. Может плохо искал ...

dogmeat1982
Форумчанин
 
Сообщения:
374
Зарегистрирован:
24 апр 2008
Откуда:
г. Екатеринбург

Благодарил (а): 27 раз.
Поблагодарили: 13 раз.

Вроде разобрался

Сообщение:#2  Сообщение dogmeat1982 » Чт 15 апр, 2010 14:09 »

В рекомендации ITU-T на T.30 отрыл вот такую вот картинку:
Изображение
Судя по ней принимающая сторона приняв не просто EOP, а PRI-EOP должна перейти в голос с момента получения PRI-EOP и в этот же момент должна ответить передающей сообщением PIP. Передающая, в свою очередь, должна перейти в голос с момента получения PIP. Полагаю, что PRI-EOP и PIP и есть основания для генерации INVITE (для SIP)/SETUP (для H.323) на голосовые кодеки!
Поправьте меня, если я не прав! Беда в том, что этого не происходит :doh: Буду сношать моск техническим поддержкам железяк. :cool:

facility

 

Сообщение:#3  Сообщение facility » Пт 14 май, 2010 16:06 »

Цитата из T.30 (09/2005):

"Конец процедуры (ЕОР) – Указывает на конец полной страницы факсимильной информации и на то, что в дальнейшем документов не ожидается, а также на переход к фазе Е после приема подтверждения.

Прерывание процедуры – конец процедуры (PRI-EOP) – Указывает на то же, что и команда ЕОР с дополнительной факультативной возможностью запроса о вмешательстве оператора. После вмешательства оператора начало дальнейших факсимильных процедур должно совпадать с началом фазы В."


Переход к разговору возможен только после завершения сеанса факсимильной связи - прохождения фазы E. Завершение сеанса факсимильной связи не означает завершение всего вызова. Поговорив, вы можете снова инициировать факсимильную связь, опять начав с фазы A. Вмешательство оператора - это не возврат к разговору.

Если говорить об H.323, то там следующее написано:

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

Приложение D – Факсимильная передача в реальном времени через системы H.323
D.5 Замена существующего аудиопотока факсимильным потоком T.38


Если устройство не переходит к режиму разговора после передачи факса, значит оно просто некорректно работает. Таких, увы, много, и причины такого их поведения разные. Например, AddPac до недавнего времени (до версии APOS 8.30V) воспринимал DCN именно как команду завершения всего вызова. Другой пример - Cisco - путает аудиокодеки, и после завершения сеанса T.38 запрашивает не тот кодек, который использовался до перехода в T.38. Если удаленная сторона его не поддерживает, происходит завершение вызова. Avaya Communication Manager тоже отказывается переключиться к режиму разговора. На RM отвечает RMReject.

Для устранения данных проблем взаимодействуйте с производителем. Бывает, что это помогает. Правда очень редко... :)

Вернуться в Железо или hardware


Поделиться

Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 2