T.38 - это рекомендация ITU для разрешения передачи факсов по IP-сетям (FoIP) в реальном времени.
История
Стандарт ретрансляции факсов T.38 был разработан в 1998 году как способ разрешить передачу факсов по IP-сетям между существующими факс- терминалами Группы 3 (G3) . T.4 и связанные с ним стандарты факсимильной связи были опубликованы ITU в 1980 году, до появления Интернета. В конце 1990-х годов VoIP , или передача голоса по IP, начал набирать обороты в качестве альтернативы традиционной коммутируемой телефонной сети общего пользования (PSTN). Однако, поскольку большинство систем VoIP оптимизированы (за счет использования агрессивного сжатия с потерей полосы пропускания) для голосовых вызовов, а не для вызовов данных, обычные факсимильные аппараты работали с ними плохо или вообще не работали из-за сетевых нарушений, таких как задержка, джиттер, передача пакетов. потеря и так далее. Таким образом, требовался какой-то способ передачи факсов по IP .
Обзор
В практических сценариях в факсимильном вызове T.38, по крайней мере, часть вызова переносится через PSTN, хотя это не требуется определением T.38, и два устройства T.38 могут отправлять факсы друг другу. Этот конкретный тип устройства называется Интернет-факсом или IAF , и он способен инициировать или завершать факсимильный вызов в IP-сеть.
Типичный сценарий использования T.38 - ретрансляция факсов T.38 - где факсимильное устройство T.30 отправляет факс через PSTN на факс-шлюз T.38, который преобразует или инкапсулирует протокол T.30 в данные T.38. поток. Затем он отправляется либо на оконечную точку с поддержкой T.38, такую как факсимильный аппарат или факс-сервер, либо на другой шлюз T.38, который преобразует его обратно в PSTN PCM или аналоговый сигнал и завершает передачу факса на устройстве T.30.
Рекомендация T.38 определяет использование как TCP, так и UDP для транспортировки пакетов T.38. Реализации, как правило, используют UDP из-за требований TCP к пакетам подтверждения и последующей повторной передачи во время потери пакетов, что приводит к задержкам. При использовании UDP T.38 справляется с потерей пакетов за счет использования избыточных пакетов данных.
T.38 не является протоколом установки вызова , поэтому устройства T.38 должны использовать стандартные протоколы установки вызова для согласования вызова T.38, например H.323 , SIP и MGCP .
Операция
Существует два основных способа передачи факсимильных транзакций по пакетным сетям. Стандарт T.37 определяет, как изображение факса инкапсулируется в электронную почту и, в конечном итоге, передается получателю с использованием процесса промежуточного хранения через посредников. Однако T.38 определяет протокол, который поддерживает использование протокола T.30 как в терминалах отправителя, так и в терминалах получателя. (См. Диаграмму выше.) T.38 позволяет передавать факс по IP-сети в режиме реального времени, как и исходные стандарты факсимильной связи G3 для традиционной (TDM) сети, также называемой коммутируемым телефоном общего пользования. сеть или PSTN .
Для передачи факсов в реальном времени через IP (Интернет-протокол) необходим специальный протокол, поскольку существующие факсимильные терминалы поддерживают только соединения PSTN, где поток информации в целом был плавным и непрерывным, в отличие от прерывистого прибытия IP-пакетов. Уловка заключалась в том, чтобы придумать протокол, делающий IP-сеть «невидимой» для оконечных факс-терминалов, что означало бы, что пользователю устаревшего факс-терминала не нужно было знать, что факсимильный вызов проходил через IP-сеть.
Сетевые соединения, поддерживаемые T.38, показаны выше. Два факсимильных терминала по обе стороны рисунка обмениваются данными с использованием факс-протокола T.30, опубликованного ITU в 1980 году. Для соединения PSTN с сетью IP-пакетов требуется «шлюз» между PSTN и IP-сетями. Шлюзы PSTN-IP поддерживают голос TDM на стороне PSTN и VoIP и FoIP на стороне пакетов.
Для голосовых сеансов шлюз будет принимать голосовые пакеты на стороне IP, накапливать несколько пакетов для обеспечения плавного потока данных TDM после их выпуска, а затем измерять их по TDM, где они в конечном итоге будут услышаны человеком или сохранены в компьютер для последующего воспроизведения. Шлюз использует методы управления пакетами для повышения качества речи при наличии сетевых ошибок за счет использования естественной способности слушателя не слышать периодически пропущенный или повторяющийся пакет.
Но факсимильные данные передаются с помощью модемов , которые не так просты, как человеческое ухо для речи. Отсутствие пакетов часто приводит к сбою сеанса факсимильной связи в худшем случае или в лучшем случае к созданию одной или нескольких ошибочных строк изображения. Таким образом, задача T.38 состоит в том, чтобы «обмануть» терминал, заставив «думать», что он напрямую взаимодействует с другим терминалом T.30. Он также будет корректировать сетевые задержки с помощью так называемых методов спуфинга и пропущенных или задержанных пакетов с помощью методов управления буфером с учетом факсов.
Под спуфингом понимается логика, реализованная в механизме протокола реле T.38, который изменяет команды протокола и ответы на стороне TDM, чтобы сетевые задержки на стороне IP не приводили к сбою транзакции. Это делается, например, путем заполнения строк изображения или преднамеренной повторной передачи сообщения, чтобы сделать сетевые задержки прозрачными для отправляющих / принимающих факс-терминалов.
Сети, в которых отсутствуют потери пакетов или чрезмерная задержка, могут демонстрировать приемлемые характеристики факсимильной связи без T.38 при условии, что тактовые импульсы PCM на всех шлюзах имеют очень высокую точность (поясняется ниже). T.38 не только устраняет эффект несинхронизации тактовых импульсов PCM, но также снижает требуемую полосу пропускания сети в 10 раз, одновременно корректируя потерю пакетов и задержку.
Снижение пропускной способности
Как показано на схеме ниже, шлюз T.38 состоит из двух основных элементов: факс-модемов и подсистемы T.38. Факс-модемы модулируют и демодулируют выборки PCM аналоговых данных, превращая представление дискретных данных аналогового сигнала факсимильного терминала в его двоичное преобразование и наоборот. Сеть PSTN производит выборку аналогового сигнала голосового или модемного сигнала (не знает разницы) 8000 раз в секунду (SPS) и кодирует их как 8-битные байты данных. Это означает 8000 выборок в секунду, умноженных на 8 бит на выборку, или 64000 бит в секунду (бит / с) для представления данных модема (или голоса) в одном направлении. Для обоих направлений транзакция модема потребляет 128 000 бит полосы пропускания сети.
Однако типичный модем в факсимильном терминале передает данные изображения со скоростью 33 600 бит / с, поэтому, если аналоговые данные сначала преобразуются в цифровой контент, который они представляют, потребуется только 33 600 бит (плюс служебные данные сети в несколько байтов). А поскольку факс T.30 является полудуплексным протоколом, сеть одновременно необходима только для одного направления.
Обратитесь к RFC 3261
Синхронизация часов PCM
На приведенной выше схеме есть тактовый генератор с частотой дискретизации в факсимильном терминале и один в модемах шлюза, который используется для запуска выборки аналоговой линии 8000 раз в секунду. Эти часы обычно довольно точны, но в некоторых недорогих терминальных адаптерах (одно- или двухлинейный шлюз) часы PCM могут быть на удивление неточными. Если терминал отправляет данные на шлюз, а часы шлюза слишком медленные, буферы (буферы дрожания) в шлюзе в конечном итоге переполняются, что приводит к сбою транзакции. Поскольку разница часто довольно мала, эта проблема возникает на длинных подробных факсимильных изображениях, что дает часам больше времени, чтобы вызвать недостаточное или переполнение буфера дрожания в шлюзе, что аналогично отсутствию или дублированию пакетов.
Потеря пакетов
T.38 предоставляет средства для устранения последствий потери пакетов за счет избыточности данных. При отправке пакета повторяются ноль, один, два, три или даже больше ранее отправленных пакетов. (Спецификация не налагает ограничений.) Это увеличивает требуемую полосу пропускания сети (она все еще намного меньше, чем при отсутствии T.38), но позволяет принимающему шлюзу восстановить полную последовательность пакетов, даже при довольно высоком уровне потери пакетов. .
Связанные стандарты
- T.4 - это общая спецификация для факса. Он определяет стандартные размеры изображений, две формы сжатия (кодирования) данных изображения, формат данных изображения и ссылки, T.30 и различные стандарты модема.
- T.6 определяет схему сжатия, которая сокращает время, необходимое для передачи изображения, примерно на 50 процентов.
- T.30 определяет процедуры, которые передающий и принимающий терминалы используют для установления факсимильного вызова, определения размера изображения, кодирования и скорости передачи, разграничения между страницами и завершения вызова. T.30 также ссылается на различные стандарты модемов.
- V.21 , V.27ter , V.29 , V.17 , V.34 : стандарты модемов ITU, используемые в факсимильной связи. Первые три были ратифицированы до 1980 г. и были указаны в исходных стандартах T.4 и T.30. V.34 был опубликован для факса в 1994 году. [1]
- T.37 Стандарт ITU для отправки файла изображения факса по электронной почте предполагаемому получателю факса.
- G.711 pass through - это то место, где факсимильный вызов T.30 передается в вызове VoIP, закодированном как аудио. Это чувствительно к потере сетевых пакетов , дрожанию и синхронизации часов. При использовании методов кодирования речи с высокой степенью сжатия, таких как, помимо прочего, G.729 , некоторые тональные сигналы факсов могут некорректно передаваться по сети с коммутацией пакетов.
- RFC 3362 определяет медиа-тип image / t38 (ранее известный как MIME-тип) для использования с протоколом описания сеанса .
Связанное программное обеспечение
- АТС с открытым исходным кодом Asterisk (PBX) поддерживает отправку факсов T.38
- Freeswitch Softswitch / PBX также поддерживает T.38
- ICTFax Web-факс / шлюз из электронной почты в факс с поддержкой T.38
Смотрите также
Рекомендации
- ^ "V.34" . www.itwissen.info .
Внешние ссылки
- Страница ITU-T T.38
- научная статья автора spandsp о FoIP