ip to ip fax t38

[eva]

вот мне стало самому интересно
раньше в старых версиях это параметр был таким
теперь они приписали 711
а истинный смысл не понятен
мы не выключаем его
факсы ходят
и насколько я помнимаю не по 711 иначе бы мы заваливали бы каналы которые 64к

попробуй включить и погляди ширину канала которую занимают при передаче факсов
и все станет понятно
факсы то все равно нужны ))
есть подозрения что они включением этого параметра коворят что использовать T38 и как бы в том числе и в 711 кодеке
а так он типа работает в том который установлен по умолчанию - в 729

[*OK]

да канечно я пробовал. неужели ж не пробовал. канечно пробовал
тот кто делает звонок, тот может отправить факс. Но НЕ МОЖЕТ ПРИНЯТЬ. то есть, если тебе звонят, то ты можеш ТОЛЬКО принять факс. а если тебе нужно отправить, придёцо перезванивать. что ENABLE что DISABLE фиолетово. вот о чём йа. и это при чистом IP to IP. без цисок и мер. есть канешно подозрюха, что это изза псевдо оптики на удалённой системе...))) ну это когда от системы до узла лежит оптика, а от узла до точки включения в магистраль радио канал. )) на этих выходных должны ЭТО исправить (сварят оптику) вот после праздников и буду делать трейсы, тогда и поговорим. канал кста до туда 4 Мбита. загрузка в течении дня ~50%

[eva]

да канечно я пробовал. неужели ж не пробовал. канечно пробовал
тот кто делает звонок, тот может отправить факс. Но НЕ МОЖЕТ ПРИНЯТЬ. то есть, если тебе звонят, то ты можеш ТОЛЬКО принять факс. а если тебе нужно отправить, придёцо перезванивать. вот о чём йа. и это при чистом IP to IP. без цисок и мер. есть канешно подозрюха, что это изза псевдо оптики на удалённой системе...))) ну это когда от системы до узла лежит оптика, а от узла до точки включения в магистраль радио канал. )) на этих выходных должны ЭТО исправить (сварят оптику) вот после праздников и буду делать трейсы, тогда и поговорим. канал кста до туда 4 Мбита. загрузка в течении дня ~50%

есть подозрения что это косяк MGI3
((
в 16 такого нету - мне клиенты говорят что все работает
4.21С MGI16 на обоих концах
может врут конечно ))
надо проверить самолично

[*OK]

пачему на MGI3 можно выставить параметр redundancy = 4, а на MGI16 только = 3

[LionB]

Так, как на этих картах используюся разные камни DSP и соответственно возможности факсового модема разные. А одиноковый, совпадающий Redundancy ставить не пробовали?

[*OK]

пробовали 2. чуда не произошло. Анализируя последние две недели ситуацию, трассу, схему организации ветки, подитожу: факсы ходят между Самсунгами в обе стороны при IP to IP. Мы выяснили,что проблема в прохождения факса в Cisco с поднятым на ней "номером доступа" и получается "двойное" перекодирование t38. то есть на плече "факс исходящий" = > "номер доступа" одно перекодирование, а на плече "номер доступа" = > "факс принимающий" уже двойное. делали на Cisco заворот IP to IP. стало слышно удалённый факс, но проблема осталась. канал как источник проблемы исключили, ибо трасса вся оптическая и мониторинг этой ветки показал 40% загрузки в течении недели. сменили IOS на Cisco на промежуточный. факсы пошли, но стабильности нет. то пройдёт один раз, то 3 раза не пройдёт. поставить последний IOS не удалось из за недостатка памяти на этой модели.
факсы на АддПаке работают как с номером доступа, так и без него. Слишком "нежный" получился Самсунг как конечный абонентский узел. даже Хуавей и тот справляется с факсами по SIP без каких то видимых проблем. Есть вариант E1 прокинуть до узла, но тут экономический казус: MGI 16 уже купили....а мультиплексор стоит как MGI. вот и видимо примет руководство решение о замене этого оборудования на 3 Хуавея по 32 аббонента... имхо

[LionB]

А вот с этим, как раз сейчас RRR борется! А ну взгляни http://bbs.radiolink.ru/forum/showthrea ... adid=40362

[RRR]

если я правильно понял то схема VOIP-TDM-VOIP
если так то видимо дело всетаки в цисках... третий день бьюсь над настройками (только на адпаках, а не на самсунгах, но думаю что на самсунгах было бы то же самое)

[*OK]

согласен. TDM туп как баобаб. и в моей схеме присутсвует Cisco 5350 <=> TDM SI 2000 <=> OS SAMSUNG v4.21c TEPRI V4.20. значит погрешность в непогрешимости кошек

[conf]

часто заглядываю в доки в атс других производителей, суть таже


исходящий вызов

1. Алгоритм кодирования домена
2. Тип сжатия системы
3. Тип IP сжатия магистральной группы или VPN перетекания
4. Мульти|алгоритмы для сжатия
5. Отправляемый список
1. | 2. | 3. | 4. | 5.
Со сжатием | G723 | G711 | Неверно/False | G723 G711
Со сжатием | G723 | G711 | Верно/True | G723 G711 G729
Со сжатием | G723 | По умолчанию | Неверно/False | G723
Со сжатием | G723 | По умолчанию | Верно/True | G723 G729
Со сжатием | G729 | G711 | Неверно/False | G729 G711
Со сжатием | G729 | G711 | Верно/True | G729 G711 G723
Со сжатием | G729 | По умолчанию | Неверно/False | G729
Со сжатием | G729 | По умолчанию | Верно/True | G729 G723
Без сжатия (G711) | G723 | G711 | Неверно/False | G711 G723
Без сжатия (G711) | G723 | G711 | Верно/True | G711 G723 G729
Без сжатия (G711) | G723 | По умолчанию | Неверно/False | G723
Без сжатия (G711) | G723 | По умолчанию | Верно/True | G723 G729
Без сжатия (G711) | G729 | G711 | Неверно/False | G711 G729
Без сжатия (G711) G729 | G711 | Верно/True | G711 G729 G723
Без сжатия (G711) G729 | По умолчанию | Неверно/False | G729
Без сжатия (G711) G729 | По умолчанию | Верно/True | G729 G723

------------------------------------
входящий вызов

1. Полученный список
2. Список предприятия
3. Выбранный алгоритм
1. | 2. | 3.
G729 G723 | G711 G723 G729 | G729
G729 G723 | G711 G723 | G723
G723 G729 | G729 G723 | G723
G711 G723 | G723 | G723
G711 G723 | G711 G723 | G711
G711 G723 | G723 G711 | G723
G723 G711 | G711 G723 | G723
G711 G723 | G729 | Сброс
G711 | G723 G729 | Сброс
G723 | G729 | Сброс
G729 | G711 G723 | Сброс

примечание:
"|" резделитель столбцов
1. 2. 3. названием столбцов

попробуйте на циске зарубить парамерт Round Trip Delay Request