Самое главное есть картинка с tcpdump которая разжевывает что нужно искать в tcpdump
Вводная: Факсы не ходят.
С чего начинать ?
Проверяем модули факса asterisk:
CLI> module show like fax
[general]
;udptlchecksums=no
udptlfecentries = 3
И начинать надо со снятия дампа и просмотре в wireshark
Причем снимать надо сразу обе стороны:
Обмен сервера с конечным устройством и обмен сервера с провайдером:
Сервер: 192.168.1.2
Шлюз: 192.168.1.220
Провайдер: 195.69.158.38
Вот так не правильно:
tcpdump -i any host 192.168.1.2 -s0 -w fax5.pcap -v
А вот правильно:
tcpdump -i any host 195.69.158.38 or host 192.168.1.220 or host 192.168.1.2 -s0 -w fax3.pcap -v
Мы снимаем два плеча – устройство и астер и астер и провайдер
Загрузили снятый файл себе на компьютер открыли в wireshark – telephony – Voip Call
Теперь внимательно:
В табличке видим 4 колонки
Дамп снял 2 звонка, и 1 и 2 строка это первый звонок, а 3 и 4 второй звонок.
Это видно по параметрам Start time (1 колонка)
Выделяем 1 и 2 колонку и нажимаем – Flow
Нас собственно говоря интересует нижняя часть рисунка – именно кусок с начала INVITE SDP (t38)
Как видно – провайдер на прислал приглашение на переключение в t38 на которое мы не ответили нечего
раз мы нечего не ответили – значит у нас косяк с настройкой оборудования – не переключился он в t38
Дяденька, а покажите как должен выглядит с дампе нормальный прошедший факс:
Не забывайте что мы снимали дамп на два плеча:
То есть между устройством и астером (1) и астером и провайдером (2)
и пакеты INVITE SDP (t38) и 200 OK SDP (t38) у вас должно быть дважды
у астера будут один порт UDP на прием от устройства и другой порт на передачу до провайдера.
Запрос переключения в t38 – INVITE SDP (t38)
и подтверждение переключения – 200 OK SDP (t38)
Опа, как все просто, пойду факсы настраивать 🙂
А вот фиг, даже запрос на переключение и подтверждение переключения не означает что факс пошел.
Теперь то не так ? а теперь надо смотреть порты согласования – на каких портах договорись о передаче факса
Встаём на INVITE SDP (t38)
Раскрываем нижнюю часть, и смотрим что передали мы до сервера по поводу t38 и на каком порту мы хотим принимать
Нижняя картинка в оригинальном размере http://ic.pics.livejournal.com/awsswa/10807794/6634/6634_original.jpg
Отправитель (Src 10.59.0.1) Получатель (Dst 10.59.0.3)
Порт на котором будет работать 10.59.0.1 UDP 4118
Потом смотрим что пришло по 200 OK SDP (t38) – на чем они договорились (картинка одинакова )
только меняются порты и передающая и принимающая сторона.
Тут уже будет порт на котором будет работать 10.59.0.3
===========================================================================
Теперь необходимо посмотреть обмен пакетами в ходе работы:
в строке поиска wireshark сбиваем фильтр:
udp.port == номер порта UDP на котором договаривались о передаче, и уведите что прошло
если все хорошо будет обмен с обоих сторон.
Ну и теперь осталось совсем простое решение:
В asteriks в консоле
> udptl set debug on
И смотрим глазками обмен между устройствами (тут правда ип адреса другие и порты но нам важен принцип)
Если пакеты есть только от одной стороны – значит где косяк или с портами или с NAT или маршрутизацией
(В самом худшем случаи с провайдером, который может просто не пускать факс по t38 и придется гонять факс в голосе g711 – где уже нет никакой диагностики)
Продолжаем:
А бывают ли случаи когда нечего сделать нельзя и факсы вообще не ходят – не по t38 не по g711 ?
Такой провайдер как Энфорта доказал что это можно сделать
Вводная теория:
Когда мы общаемся с провайдером есть так сказать 2 вида связи:
1) Сигналка: это всякие служебные сообщения суть которых рассказана выше (INVITE, OPTIONS, REGISTRY)
2) Голосовой трафик: RTP где собственно идет уже сам голос каком нибудь кодаке
Провайдер ради снижения нагрузки может разбивать Сигналку и Голос на разные адреса:
Типа: регистрации и служебные общения на 109.109.109.199
А голосовой трафик уже на 109.109.109.200
Так вот, Энфорта сделала это, проблема только в том что голосовой трафик она пустила на свою внутреннюю сеть,
которую не видно снаружи 172.24.59.10
( мы ведь помним что 172.16.0.0 — 172.31.255.255 (Маска подсети 255.240.0.0 или для бесклассовой адресации /12))
Соответственно в заголовке приходит что трафик надо слать на 172.24.59.10 – и вообщем все … некуда его слать
Это их косяк – они в invite анонсируют внутреннею сеть
Update:
Передача факсов через VoIP-сети не работает. Иногда у вас получится достичь достаточно высокого процента успешных передач факсов. Может случиться, что вы создадите такую установку, которая будет работать на 100% всё время своего существования. Это редкие, неповторимые установки. Вам необходимо использовать правильный протокол FAX over IP, такой, как например Т.38, чтобы достичь постоянного, надёжного результата передачи факсов через IP-сети.
Для скептиков
Вы не верите, что передача факсов через VoIP-протоколы не работает? Вы слышали, что всё прекрасно работает если использовать кодеки рекомендации G.711? Читайте далее, если вы хотите понять, почему всё намного сложнее, и проблематичнее, чем этот подход.
Пытаясь ужиться с передачей факсов через VoIP-сети…
Передача факсов через VoIP-сети обычно заканчивается неудачей. В природе человека – искать простые объяснения этому, и простые решения. В реальности же, всегда есть много причин, и полное отсутствие простых универсальных решений. VoIP-сети были разработаны чтобы отлично работать с голосом. Передача любого другого звука, отличного от речи, не является главным требованием к системе VoIP-связи. Естественно, не надо удивляться, что такие передачи работают из рук вон плохо.
Не получится налить кварту в пинту
Наиболее распространённая проблема при передачи факсов через VoIP-сети – это самая простая из решаемых. Речевые кодеки с низкой скоростью передачи данных не могут передавать быстрые модемные сигналы без грубейшего их искажения. Неужели вы ожидаете, что G.729 8 кбит/с кодек сможет без искажений передать сигнал модема факса скорости 9.6 кбит/с? Если да, то, скорее всего, вы верите в вечный двигатель, и так далее. Я бы смог вам предложить неплохую сделку по этому поводу, если вы согласитесь купить Лондонский мост (London Bridge – прим. перевод.). Единственные широко поддерживаемые кодеки, которые могут адекватно сохранить сигналы модема факса до 14,4 бод (V.17) – это G.711 u-закон и A-закон. Полная версия G.726 кодека также будет работать с сигналом факса до 9,6 бод. Хотя не все устройства, которые рекламируются с поддержкой G.726, будет действительно поддерживать эту спецификацию. Несколько быстрых переходов в коде программы кодека могут значительно сократить вычислительные издержки, и всего лишь небольшому числу людей нужна полная поддержка G.726. Поэтому результаты на разных устройствах могут отличаться. Как бы то ни было, G.726 кодек был специально разработан для передачи среднескоростных сигналов модемов, таких как протокол V.29 на котором работает факс.
Совсем недавно стали популярными факс-аппараты с поддержкой скорости передачи до 33,6 кбит/с (V.34bis). Эта скорость передачи вряд ли будет надёжно работать через любое VoIP-соединение, даже если используются кодеки G.711 A-закон или u-закон. Кодеки смогут обеспечить требуемое качество сигнала, но задержки в VoIP-канале, даже если они будут стабильными, не дадут эхокомпенсаторам в любом факс-модеме возможности обучиться до нужного предела. Более медленные модемы факсов – V.27ter, V.29 и V.17 не используют эхокомпенсации, поэтому данной проблемы с ними не возникает.
Низкоскоростные кодеки имеют нулевой шанс нормально передать любое стандартное факс-сообщение. Некоторые кодеки без проблем передадут через канал контрольные сообщения факса в 300 бит/с (V.21). Но они не смогут передать быстрые сигналы модемов, непосредственно несущие информацию о передаваемом сообщении.
Модемам не нравится относительность
В мире ТфОП, коммутированная сеть имеет конечное значение задержки для каждого конкретного звонка. Скорость, с которой данные попадают в сеть, всегда равна скорости, с которой они её покидают. Задержка между концами канала не имеет дрожаний фаз (jitter – прим. перевод.), и не изменяется пошагово в любой из своих характеристик, за исключением вынужденных обстоятельств (например переход на обходные маршруты, если часть канала, до этого проходившая через оптоволокно, вдруг оборвалась). Эти характеристики каналов требуются модемам, они были разработаны для них. В IP-сетях дрожания это просто факт, от которого никуда не уйти. Дрожание можно свести до допустимого предела, используя приоритезацию (QoS) трафика, поддерживаемую большинством IP-оборудования, но только если вы можете контролировать сеть от начала и до конца. Если же звонок проходит через публичную часть сети Internet, там нет QoS-а. С трудом можно представить себе бизнес-модель оператора связи, который бы ввёл бы QoS на публичной части сети. Поэтому, при первом приближении, временные характеристики голоса, входящего в VoIP-сеть, такие же, как на выходе, но при детальном рассмотрении они могут быть очень и очень разными.
Если VoIP-сеть работает через локальную сеть или через WAN-соединение с включенным QoS-ом, вы можете достичь близкую к нулю вероятность потери пакетов, и очень, очень низкое значение дрожаний. Далее, многие полагают, что буфер на приёмном конце канала будет смягчать влияния средних по величине дрожаний, поэтому сигнал на выходе VoIP-канала будет прекрасно восстанавливаться в оригинальный. Чаще всего, эти люди будут правы. Но никаких гарантий. Есть много различных конструкций буфера дрожаний. Много современных вариантов динамически адаптируют длину буфера тем или иным способом, тем или иным алгоритмом. Если дрожание невелико, динамическая буферизация отключается, и вся система работает хорошо. Если динамическое управление буфером нельзя отключить, его поведение может, в общем-то, значительно ухудшить качество восстановления сигнала модема. Различные алгоритмы будут:
- Гарантированно терять пакеты, настраивая буферизацию до такого предела, когда некоторый постоянный процент пакетов не будут считаться поздними, и будут отбрасываться. Потеря пакетов обычно встраивается в такие алгоритмы, и результаты могут быть вполне приемлемыми для голоса. Это вполне резонный обмен: терять небольшое количество пакетов, и взамен иметь нечто менее подверженное задержкам.
- Регулировать периоды тишины во всех отсчётах пакетов (обычно по 20 мс). В спецификации факса, некоторые периоды тишины определены значениями 75+-20мс. Периоды в 20мс могут сбить их с толку.
- Постоянно регулировать временные характеристики вне периодов тишины, используя техники наложения краёв и смешения. Этот подход считается произведением искусства для речевых буферов, и при этом – полной катастрофой для модема факса…
По закону подлости, самое простое оборудование будет почти наверняка хорошо работать, а более новые и более сложные разработки почти наверняка доставят кучу хлопот.
Модемы не любят подавление тишины
В зависимости от реализации в том или ином оборудовании, подавление тишины может полностью уничтожить звонок с факсом. Если подавление тишины включено, детектор голоса постоянно проверяет звонок, пытаясь обнаружить наличие голоса – т.е. сигналов модема. Некоторые из них были разработаны таким образом, чтобы фокусироваться на речевом сигнале, и отбрасывать все посторонние шумы – в нашем случае тоны модема факса. Поэтому, эти детекторы могут недоброкачественно включать и выключать аудио-нагрузку когда модем факса начинает и заканчивает передачу. И если даже они качественно переключаются, алгоритмы подавления тишины обычно сильно искажают сигналы уровни которых находятся около пороговых отметок.
Во время периодов тишины, в аудио-нагрузку постоянно вносится “комфортный шум”, который симулирует нормальную обстановку, которую вы слышите во время привычного звонка через ТфОП. Это означает, что период, который обычно будет полон тишины (факсы передают сгенерированные сигналы, то есть нет внешних шумов), будут сильно зашумлены. Модем на приёмной стороне может не увидеть достаточно чёткой “тишины” чтобы корректно определять границы сигналов модема передающего факса.
Модемы любят полное общение
Модемам требуется полноценный канал аудио. Если внести в него потерю пакетов, последствия будут суровыми, но реальный эффект будет зависеть в основном от оборудования, которое вы используете. Предположим, пакет в 20мс теряется в середине страницы факса. Понятно, что эта потеря приведёт к утрате какой-то части передаваемого изображения, но будет ли это влиять на передачу небольшого отрезка, или всего остатка страницы? Если приёмная сторона VoIP-канала вставляет 20 мс тишины, приёмный модем факса почти наверняка воспримет эти 20 мс как конце страницы. Если приёмная сторона вставляет 20 мс какого-то шума или звука, приёмный модем факса наверняка сможет перейти через разрыв в приёме. Всё зависит от конкретного оборудования. Если приёмная сторожа вставляет больше или меньше чем 20 мс какого-то шума, понятно, что остаток страницы будет принят с искажениями.
Подводя итог сказанному
Факс, как и все прочие приложения с использованием модемных соединений, работают из рук вон плохо и ненадёжно при передаче через VoIP-каналы. Эта ситуация не изменится в лучшую сторону со временем. Она будет ухудшаться. Вообще говоря, чем сложнее становится оборудование в гонке за качественной передачей голоса, тем хуже это оборудование становится для использования с модемами. В ближайшей перспективе (например, до того момента, когда все приложения по работе с данными будут полностью работать на IP-протоколе), единственным выходом для достижения приемлемых результатов будут протоколы с промежуточным хранением store-and-forward, а также протоколы, “подогнанные” для передачи модемных данных поверх IP-каналов.
Спецификация FAX over IP (FoIP)
Большинству современных факсовых аппаратов не хватает порта RJ-45 и поддержки стека протоколов TCP/IP. Лишь несколько из самых самых последних моделей факсов могут напрямую подключаться к Интернет, даже несмотря на то, что протоколы для этого были стандартизованы ещё пять-семь лет назад. На сегодняшний день только несколько самых высококлассных факсовых аппаратов содержат такой функционал. Что это означает? Это означает, что в мире, стремительно движущемся в сторону VoIP для телефонии, срочно необходима поддержка работы традиционных факсовых аппаратов поверх IP-каналов, и эта поддержка будет нужна до тех пор, пока самый последний традиционный факс не будет утилизирован.
FoIP с промежуточным хранением (Store and forward FoIP) – T.37
Спецификация T.37 определяет стандартный метод передачи факсов через IP-сети методом промежуточного хранения. Это простой, элегантный и надёжный метод. Единственный реальный недостаток – что это не метод реального времени. На самом деле это даже преимущество, но чисто психологически это самый что ни на есть недостаток. Передача факсов в реальном времени даёт пользователю иллюзию того, что как только его аппарат сказал “Отправка завершена”, документ уже в руках получателя. Конечно, это полностью ложное представление. Документ может находиться в неком буфере (например, в буфере факсового аппарата, в котором кончилась бумага, или в сервере Fax-to-email), о котором пользователь ничего не знает. Документ может находиться в корзине для мусора, потому что его сочли спамом. Конечно, если начать это объяснять, все проникаются идеей и говорят что понимают. Но никто не собирается отказываться от неприязни к факсам, не работающим в реальном времени. Некоторые полагают, что отчёт, выданный факсовым аппаратом, можно привязать к документу, удостоверяющему некое официальное действие: “мы отправили вам факс и вы получили его в таком-то часу”. Возможно. Одно время суды принимали как улики отчёты телексов, отправляемые организациями, подделка которых занимала не так много времени.
Единственная реальная проблема, создаваемая промежуточным накоплением, это невозможность согласовать характеристики двух точек. Отправка факсов ограничивается возможностями самой системы промежуточного накопления. Если вы хотите послать цветной факс между двумя факсовыми аппаратами, которые поддерживают цветность, но система промежуточного накопления не поддерживает передачу цветных факсов, удивление и расстройство при получении на принимающем аппарате монохромного документа будет велико. Конечно, модернизация возможностей факсовых шлюзов, с целью соответствия текущим стандартам факсовых протоколов, может решить эту проблему.
Рекомендация T.37 определяет процедуру приёма факса на шлюзе, создания e-mail сообщения, содержащего факс как приложение, пересылку e-mail сообщения на удалённый шлюз, набор номера и доставку факса к принимающей стороне. Опционально, факс может быть доставлен в виде приложения непосредственно на e-mail принимающей стороне. Также, факсы могут быть отправлены непосредственно в систему промежуточного накопления по электронной почте от самого отправителя, чтобы затем набрать номер и передать сообщение на традиционный факс.
T.37 – это очень простая спецификация. Ей не надо многого объяснять. Она основана на проверенных временем, широко используемых протоколах – SMTP, MIME и так далее – и только лишь определяет некоторые детали, необходимые для связи всех составляющих воедино и использования с факсом. Это означает, что спецификацию T.37 можно очень просто развернуть в любой системе, содержащей составляющие компоненты. T.37 это хорошая спецификация. T.37 это зрелая, здоровая спецификация. T.37 – это единственно здравый способ работать с факсом на сегодняшнее время.
FoIP реального времени (Real time FoIP) – T.38
Всего лишь один стандарт был разработан для факса в реальном масштабе времени через IP – спецификация T.38. Прежде чем приступить к обсуждению, что есть T.38, необходимо отметить некоторые факты о текущем статусе стандарта в реальном мире, справедливые на сегодняшний день. Большое количество VoIP-шлюзов и прочего оборудования до сих пор не поддерживают T.38. Много шлюзов, на коробках которых написано «поддержка T.38», всего лишь имеют T.38 в очереди дополнений на разработке, как например обстоит дело с Linksys SPA2100. Очень немного из текущих разработок T.38 поддерживают факсы на скорости 33600 бит/с (протокол V.34bis) , хотя сейчас почти все малобюджетные факс-аппараты и многофункциональные устройства (принтер/сканер/копир/факс) поддерживают её. Множество шлюзов имеют очень недоработанные подпрограммы, связанные с T.38 – я лично использовал небольшой шлюз, который намертво зависал как только слышал сигнал факса. Если вы знаете, как работает T.38, вы должны представлять, как ведут себя его «ключные» версии.
Итак. Что такое T.38?
T.38 это протокол передачи факсов через IP-сети (FAX over IP) реального времени. Это означает, что он был создан чтобы работать точно так же как традиционная передача факсов. Вы звоните на другой факсовый аппарат, и, пока ждёте, факс передаётся. Приёмным факсом может быть традиционный факсовый аппарат, подключенный к городской телефонной сети, VoIP-шлюз или его подобие, это может быть факсовый аппарат с портом RJ-45, подключаемый непосредственно в IP-сеть, или это может быть компьютер с факс-модемом. Что угодно!
Есть несколько нюансов, без которых невозможно заставить FoIP отлично работать с традиционными факсовыми аппаратами. Наиболее поздние версии основного факсового протокола – T.30 – содержат пункты и специальные функции, позволяющие современным факсовым аппаратам стать «знающими Интернет» (Internet-aware, – прим. перев.) факсами. Такие факсы соединяются со спецификацией T.38. Некоторые производители факсов пишут на упаковке что их аппараты – «Internet-aware devices». Это не значит что они соединяются напрямую с IP-сетями. Это только лишь значит, что они знают о существовании и характеристиках T.38.
Как работает T.38?
Исходная версия спецификации T.38 определяла два метода передачи факсов через IP-сети – одну основанную на UDP, и другую – на TCP протоколе. В то время RTP был лишь зарождающимся протоколом для вещания музыки через IP-сети. Вместо того чтобы использовать RTP, T.38 определила свой собственный способ упаковки данных в пакеты UDP, который получил название UPDTL. Сейчас этот шаг признают ошибочным, и версия протокола T.38, основанная на RTP, уже определена. Это только добавило проблем инженерам, внедряющим T.38 на своих устройствах. На деле, наиболее широко распространённый метод – это не-RTP метод, поэтому надо будет сначала добавлять поддержку RTP, а потом плавно мигрировать… ААААААААААААА!!!
Спецификация T.38 говорит какие-то странные вещи о том, когда использование UDP метода предпочтительней TCP, и наоборот. Я бы сказал что метод TCP должен быть использован между двумя IP-устройствами. Когда один из узлов подключен к аналоговой линии, скорее всего, лучше использовать UDP-метод, у которого лучше характеристики приближающие его к протоколу реального времени. Хотя, как известно, UDP – очень ненадёжный протокол, и это серьёзно компрометирует T.38 как надёжную спецификацию для передачи факсов через IP-сети.
T.38 это очень обобщённая спецификация. Большинство современных спецификаций модемных протоколов пытаются действительно разъяснить что должно произойти в аппаратуре. T.38 оставляет гигантский простор для решений во время внедрения в устройствах.
В каких аспектах T.38 лучше чем FAX over VoIP?
Если T.38 используется поверх TCP, то это очень надёжно. Если использовать T.38 между «Internet-aware» факсами, то этот метод решает все проблемы передачи факсов через VoIP соединения.
Если T.38 используется в одной из UDP форм, можно использовать вариант когда каждый следующий пакет содержит копию основной информации из предыдущего пакета. Это необязательная опция, но большинство виденных мной вариантов T.38 поддерживают её. Такая схема принудительной коррекции ошибок делает T.38 более равнодушным к потерянным пакетам, нежели обычные протоколы VoIP. Необходимо потерять два пакета последовательно, чтобы реально что-то потерять. Заголовки в T.38 такие большие, что дополнительная информация, передаваемая в теле пакета, едва ли заметна. Конечно, если потерять два пакета подряд, у T.38 будут проблемы. Но, если такое случается часто, это также значит что сеть, через которую идёт передача, не пригодна для качественной связи по VoIP-каналам.
Потеря пакета в потоке T.38 не влечёт за собой сбой синхронизации модемов. Это означает что два потерянных пакета всего лишь повредят часть передаваемого изображения. Если на факсовых аппаратах используется опциональная коррекция ошибок (ECM), велика вероятность того что с одним-двумя повторами передаваемое изображение будет получено с великолепным качеством. Не идеальное решение конечно, но вполне функциональное.
Большая часть надёжности T.38 идёт не из того что говорит спецификация, а из того потенциала, который спецификация предлагает для разумного внедрения. Задача состоит в том чтобы разработать наиболее удачное внедрение, которое не будет иметь проблем с многочисленными недоделанными разработками на базе T.30, существующими в коммерческих продуктах для факсового программного обеспечения.
Спецификация T.30 позволяет приостановить передачу страницы непосредственно перед концом любой строки пикселей. Эта особенность используется как мера контроля потоковой передачи в факсовых аппаратах с медленной печатью например. Эта особенность также может быть использована в продуктах на базе T.38, – ожидать приёма большего количества информации когда пакет задерживается или оказывается утраченным. Это означает, что шлюз с поддержкой T.38 может начать передачу страницы как только у него будет хотя бы часть информации от отправителя со стороны IP-сети, без необходимости промежуточной буферизации. В случае, если эффект джиттера минимален, задержка передачи также минимальна. Когда джиттер велик, передача будет задерживаться на столько, насколько это необходимо. Если пакет теряется и исправление ошибок включено, передающий шлюз может просто подождать некоторое время, пытаясь восстановить утраченную информацию из потока следующих пакетов. Если необходимая информация безвозвратно потеряна, передача будет продолжена с минимальным количеством утраченных частей страницы.
Передача HDLC (High-Level Data Link Control), , используемая в управляющих сообщениях факсового протокола, не позволяет точно контролировать поток сообщений. Как бы то ни было, существует возможность достичь достаточно хороших результатов. Протокол HDLC поддерживает контроль потока только между HDLC-фреймами. Полный HDLC протокол поддерживает возможность отменять фреймы на полпути, или возобновлять их передачу. Однако, протокол HDLC как он определяется в спецификации T.30 не поддерживает функции отмены передачи фреймов. Если нам приходится ждать конца большого фрейма для того чтобы отменить его и начать повторную передачу, мы сталкиваемся с большими задержками. Как бы то ни было, это не большая проблема для передачи факсов в рамках T.30. Большая часть HDLC фреймов, использующихся в спецификации T.30, достаточно коротки, особенно те которые встречаются между страницами. Задерживая передачу до того, как мы полностью получим данные для одного из этих сообщений не будет слишком затягивать звонок. Чтобы избежать длинных задержек для очень длинных фреймов мы можем использовать правила типа «если длина фрейма не более 30 байт (1 секунда), мы ждём получения всего фрейма чтобы продолжить; если длина фрейма больше, мы передаём его с задержкой в 1 секунду».
Какие недостатки у T.38?
Спецификация T.38 не может избежать простой проблемы, состоящей в том что ей необходимо работать со старыми факсовыми аппаратами, созданными даже до того как идея FoIP пришла кому-то в голову. Этим аппаратам требуется соблюдение жёстких временных критериев задержек в каналах связи. Для этих аппаратов T.38 частично устраняет, частично уменьшает масштаб проблемы передачи факсов по VoIP-сетям. Однако, это ничто по сравнению с передачей изображения по FTP или HTTP и возможностями данных протоколов справляться с плохими условиями сетевых соединений.
happyman1974 