Про ОХЕ спрашивайте в разделе ОХЕ, а не ОХО, как сейчас. Будьте внимательнее.
07.02.2014 20:41:19, etc.]]>
====quote====
etc пишет:
На ОХО для H323 T38 - не отключается. Всегда используется.
=============
А если у нас OXE тоже не отключить?
07.02.2014 18:56:23, Сергей Челышев.]]>
====quote====
error пишет:
есть какая-то проблема ОХО перевести на sip-транк?
=============
угу. нет лицензий на sip-транк.
07.02.2014 18:49:52, Сергей Челышев.]]>
====quote====
Сергей Челышев пишет:
Судя по всему реализация h323 для астериска не знает про t38.
=============
выкидывайте астерикс в фтопку, ставьте что-то более серьезнее
есть какая-то проблема ОХО перевести на sip-транк?
07.02.2014 17:27:53, error.]]>
На ОХО для H323 T38 - не отключается. Всегда используется.
07.02.2014 17:12:26, etc.]]>
Аналогичная проблема. алкатель(h323) - астериск (h323). Факсы не ходят. После старта идет тон и тишина. Как отключить t38 на алкатель для h323 транка?? Судя по всему реализация h323 для астериска не знает про t38.
07.02.2014 16:48:54, Сергей Челышев.]]>
Статейка познавательная "Механизм организации факсимильной сессии FAX-VoIP-FAX (FoIP) T.38 и pass-through" (не знаю как относится администрация форума к такого рода ссылкам)
20.01.2014 16:46:21, t_dimas.]]>
====quote====
t_dimas пишет:
Буду копать дальше
=============
вам говорил что семейство астериск с факсами работает либо pass-through либо t38
вот поэтому и недолюбливают семейство астериск и используют другие вариации софтовых решений
18.01.2014 19:25:09, error.]]>
Зацепил сейчас по sip e1-cisco-oxo, факсы летают в обе стороны! В cisco в dial-peer voip fax protocol t38. Видимо freePBX лажает. А без нее ни как - вся маршрутизация и тарификация там. Буду копать дальше...
17.01.2014 14:55:48, t_dimas.]]>
====quote====
t_dimas пишет:
астер понимает oxo
=============
т.е. факс на астериск бегает?
крутите хвосты "fax protocol" на циске
15.01.2014 11:54:06, error.]]>
====quote====
error пишет:
у вас есть 4 варианта:
1. апгрейд ОХО
2. в ОХО поставить pri
3. перейти на h323 транк, для астериска h323-транк тяжелая реализация в плане выделения ресурсов (реальный пример - 10 активных разговоров на проце xeon-3120 сжирает 60%)
4. на астериск поднять виртуал-факс (hylafax/digium) и добиться нормальной работы факса ОХО -> астериск, а потом уж копать на циске
=============
Апгрейд вообще не вариант - слишком тугая бюрократическая машина выделения финансов, поток тоже поставить не вариант - станция удалённая, к тому же корпус урезанный на 2 модуля (сейчас установлены CPU-3m и AMIX 4/4/8-1) , если и физически возможно установить pri то только вместо платы с аналоговыми абонентами - но тогда сразу теряется смысл...
А зачем h323 ? t38 используется только в sip ? Что должно быть прописано в транке asterisk для h323 ?
По поводу 4. пункта - ИМХО астер понимает oxo (в консоли не ругается...),возможно не пропускает cisco хотя нужно разбираться что происходит и пробовать ещё.
15.01.2014 11:41:11, t_dimas.]]>
====quote====
t_dimas пишет:
идимо потому что в dlink-е fax codec disable а в cisco - fax protocol pass-through g711ulaw) ну как то так короче.
=============
тут факс в голосовом потоке
еще вдогонку - астериск работает с факсами либо pass-through либо t38 в одном из двух вариантов fec/ecc
для более менее шикарной реализации h323-транка лучше использовать yate, в этом плане даже freeswitch уступает yate
15.01.2014 10:11:00, error.]]>
можно вас обрадовать - у вас t38
t38 есть двух видов fec и ecc, по какому работает ОХО честно говоря не задумывался (узнавал у прова по душу факса и в том направлении копал, к счастью c факсами t38 не повезло мне
)у вас есть 4 варианта:
1. апгрейд ОХО
2. в ОХО поставить pri
3. перейти на h323 транк, для астериска h323-транк тяжелая реализация в плане выделения ресурсов (реальный пример - 10 активных разговоров на проце xeon-3120 сжирает 60%)
4. на астериск поднять виртуал-факс (hylafax/digium) и добиться нормальной работы факса ОХО -> астериск, а потом уж копать на циске
15.01.2014 10:09:27, error.]]>
Не знаю с чего и начать
))у меня связка e1-cisco-freepbx(asterisk)-oxo, голос ходит по g711ulaw и g711alaw
в cisco в voip dial-peer выставлен fax protocol none, в freepbx выставлено Прозрачное пропускание T38.
при звонке из e1 в сторону oxo на факс (он в автоответе) слышен сначала писк, потом тишина и привет... В консоли asterisk видно что во время тишины медиапоток изменяется с RTP на какой-то другой (сейчас под рукой нет посмотреть). Обратно возможности попробовать не было.
Для начала ИМХО cisco сдружить бы с oxo... может есть у кого опыт? что там в dial-peer должно быть по поводу факса прописано?? А то там вариантов уйма... Может pots dial-peer ещё что то нужно про факс написать ...
Сейчас проблему решил по временной схеме - зацепил:
e1-cisco-voip шлюз dlink - маршрутизация при входящем звонке на dlink с аналоговым факсом
dlink-freepbx-cisco-e1 при исходящем (астер в консоли при таком звонке ругается -unknown rtp codec 96 received from XXX.XXX.XXX.XXX:16926 (xxx ip cisco) - видимо потому что в dlink-е fax codec disable а в cisco - fax protocol pass-through g711ulaw) ну как то так короче.
Приоритетные задачи: или отключить t38 в oxo, или сдружить их сначала с cisco, затем с asterisk...
cisco 2821 software c28nm-spservicesk9-m , ver 12.4(3g)
Спасибо за внимание к вопросу!
15.01.2014 02:27:57, t_dimas.]]>
в моем случае факс от прова шел в голосовом потоке g711
в вашем случае надо выяснять факс как идет g711/t38, да и факс в g711 появился с версии 8
t38 можно проверить на ухо т.е. звоните на внешний телефон с факсом через voip и пусть там нажмут "старт" если писк идет без провала т.е. тишины то факсуют вам в g711, если после первого писка факса появился "провал" то в ход пошел t38
в теории t38 обойти можно т.е. чтобы вам отправить/принять факс нужно чтобы с удаленной стороны нажимали "старт" первым и после того того как пройдет "провал" (на сколько помню t38 дважды посылает сессию факс, а далее по барабану) с вашей стороны жмете "старт"
14.01.2014 14:34:13, error.]]>
====quote====
error пишет:
есть OXO версии 800.041.002
в "Gateway Parametrs" установил fax -> g711
=============
Здравствуйте! Прошу помощи.
есть OXO версии 7
В "Gateway Parametrs" нет упоминаний о fax. По умолчанию при звонке по VOIP транку станция пытается отправить факс по какому-то хитрому протоколу(предполагаю Т38). Как заставить ходить факс в голосовом режиме ????
14.01.2014 13:58:44, t_dimas.]]>
еще одна фишка в OXO версии 800.041.002
через sip-транк не доходит входящий звонок на внутренний номер 700 (индекс на base 700), при входящем звонке на 700 звонок падает в G.B.
т.е. везде в планах прописана одна и та же строка type:subsc. start:700 end:799 base:700
номеру 700 под base:700 просто не повезло, ладно хоть что 700 это секретарь
апгрейд софта даже страшно делать, вдруг новые "прелести" вылезут
03.03.2013 12:57:15, error.]]>
====quote====
etc пишет:
Что означает фраза: на asterisk включили джиттер ?
=============
по дефолту параметры закомментированы "Implementation" "Jitter Buffer Size" "Force Jitter Buffer"
раскоментировал и в рукопашную установил значения
для факса поставили балалайку "spa", секретарша довольная до безобразия
28.02.2013 17:39:20, error.]]>
Обычно, стараются уменьшить джиттер. У ОХО глубина буфера для подавления джиттера вполне определенная.
Что означает фраза: на asterisk включили джиттер ?
28.02.2013 12:28:36, etc.]]>
изначально факс в схеме OXO (sip) -> asterisk (sip)-> провайдер вообще не бегал ни в одну сторону
как только на asterisk включили джиттер входящий факс пошел
к asterisk подключали spa3102, факсы через asterisk с джиттером летают на ура как вход так и выход, без джиттера не проверили
да и пров ненароком проболтался что есть такие клиенты у него где факс бегает только в одну сторону
28.02.2013 10:31:31, error.]]>
А, может быть, маршрут проверить ОХО - провайдер на наличие джиттера? Если алкатель ругается - скорее всего, он есть. Для эксперимента можете перевести ком порт ОХО в режим вывода сообщений и увидите как она ругается в реальном времени.
28.02.2013 09:40:05, etc.]]>
путем долгих танцов с бубном в OXO версии 800.041.002 факс на прием заработал, аж со свистом идет входящий факс. с исходящим факсом так и не получилось
снятие дампа исходящего факса в цепи asterisk (sip)-> провайдер показал что со стороны прова идет приличное количество "Out of Seg" и "Wrong Timestamp". прова естественно напрегли
пришла безобразная идея снять дамп исходящего факса на цепи OXO (sip) -> asterisk и увидели что со стороны ОХО идут не только "Out of Seg" и "Wrong Timestamp" но и "Drop by jitter buff" и тем самым аукалось на входящие пакеты от прова.
получается что аплликашион fax_tx не совсем работоспособный
как всегда наш любимый alcatel хромает как старая лошадь
28.02.2013 09:09:52, error.]]>
etc, огромное Спасибо!
в борьбе с факсом ощущал себя в роли "Дон Кихота"
в итоге с беспощадной борьбе с факсом он так и не заработал, но зато стало ясно из-за чего
19.02.2013 20:33:41, error.]]>
Выдержка из доки:
Note:
some known inconveniences of the fax over G711 (pass-through method) are listed below:
• It is not standard based and hence implementation can be different depending on the vendor
• Bandwidth usage with G711 codec is high
• As with many vendors, the PCX implementation does not offer packet redundancy. Fax
transmission is then very dependent on end-to-end performance of the IP network and reliability
is very sensible to packet loss
• End-to-end G711 transparency must be guaranteed, that means no transcoding of the media
channel is allowed through the IP network
• Voice Activity Detection (VAD) must be disabled on both sides of the fax call
Обратите внимание на первый пункт, что это нестандартизованная функция и может быть разной у разных производителей. Далее ещё из доки, может поможет.
FoIP Service
No matter the OMC setting (T.38 or G711), a SIP fax call on PCX is always established first as
a normal voice call transmitting an RTP flow. After some seconds, upon detection of the fax
tone, the FoIP service is then triggered to operate the selected T.38 or G711 choice (see Fax
T.38 Annex D or Fax over G711 ).
Fax over G711
When Fax over G711 is selected, RTP voice channels are maintained but if current codec is
G729A or G723, it is renegotiated to G711.
Fax over G711 is not compatible with Voice Activity Detection (VAD) which is a mechanism
used to save bandwidth during VoIP calls. Therefore, the PCX supports the "silenceSupp"
attribute in the SDP part of the SIP message in order to dynamically disable VAD during the
Fax over G711 media session.
This attribute is used to request the other side to disable VAD. It works as follows:
- Case of an incoming fax call: the PCX detects the fax tone in the RTP stream and sends
Re-Invite to renegotiate the media session characteristics with "silenceSupp" attribute set
to "off" in order to ask the remote side to disable VAD
• If the PCX receives a response containing "silenceSupp" attribute set to "off", it means
that remote side has disabled VAD and then the PCX disables VAD also. This is the
normal mode of operation
• If the PCX receives a response which does not contain "silenceSupp" attribute set to
"off, then VAD remains active on the PCX side. In that case fax over G.711 is not
guaranteed when VAD on both ends is not disabled
- Case of an outgoing fax call: remote side (called side) should detect fax tone. The PCX
expects to receive a Re-Invite from the remote side with "silenceSupp" attribute set to "off"
• If the PCX receives a Re-Invite request containing "silenceSupp" attribute set to "off", it
means that remote side requests to disable VAD, then the PCX disables VAD and
sends a response containing "silenceSupp" attribute set to "off" to acknowledge the
request. This is the normal mode of operation
• If the PCX receives a request which does not contain "silenceSupp" attribute set to "off,
then VAD remains active on the PCX side. In that case, fax over G.711 is not
guaranteed when VAD on both ends is not disabled
Recommendation for deployment of Fax over G711:
- If remote side supports "silenceSupp" attribute => this is the expected mode of operation
- If remote side does not support "silenceSupp" attribute => disable VAD on both the remote
side and the PCX => Fax over G711 works but VoIP calls will not benefit from bandwidth
optimization
- If remote side does not support "silenceSupp" attribute and it is not possible to disable
VAD on remote side => fax over G.711 is not guaranteed as VAD on both ends is not
disabled
18.02.2013 11:28:12, etc.]]>
есть OXO версии 800.041.002
схема подключения к прову OXO (sip) -> asterisk (sip)-> провайдер
провайдер хочет принимать факс исключительно в g711
в "Gateway Parametrs" установил fax -> g711
факс не хочет бегать ни входящий ни исходящий, сделал запись дамп и там видно когда идут тоны факса то одна сторона шлет пакеты а с другой стороны тишина, потом с точностью наоборот
т.е. от ОХО идут пакеты со стороны прова тишина, пров шлет пакеты со стороны ОХО тишина и так тоны факса идут то с одной стороны то с другой и договориться не могут
кто-нибудь смог факс побороть?
18.02.2013 09:26:06, error.]]>