факсы без t38

[mapt]

регион однозначно не определить
в зоне действия проксей 188.187.242.4, 188.187.242.5, 188.187.242.6, 188.187.242.7

если есть возможность, не могли бы привести пример своей конфигурации?

эртелекомовцы говорят "т38" есть, при попытках понять как его поддержку сконфигурировать присылают доку:

Код: Выделить всё

Рекомендации по настройке стороннего оборудования при использовании услуги телефонии
для настройки факса: 
 
1) Использование кодеков G711A-law, G.729. 
2) Использование протокола SIP v.2.0 (RFC 2543bis\3261)
3) Использование транспортного протокола UDP
4) Передача факсов по протоколу T.38
5) Трансляция DTMF по стандарту RFC2833

В общемто все рекомендации выполнены:
* стоит t38pt_udptl=yes transport=udp dtmfmode=rfc2833
* имеется register => 00278442526594:**********:002526594@188.187.253.3:5060
* есть запись

Код: Выделить всё

[ertelecom002526594]
qualify=yes
type=friend
host=188.187.253.3
username=00278442526594
fromuser=00278442526594
secret=************
call-limit=1
context=incoming
canreinvite=yes
insecure=invite
disallow=all
allow=alaw
nat=no

* звонки отлично работают, нареканий нет (вх/исх)
* отправку факсы пытаемся сделать через SendFAX с опциями dfzs

В общем то все пожелания соблюдены, но факс не ходит.
Сейчас ошибка приведенная в заголовке топика исчезла, факс успешно дозванивается, проигрывает сообщение, слышатся гудки, но при попытки стартовать - факс аппарат говорит что не услышал факс. характерных звуков в линии (кроме гудков) тоже не наблюдается.

[ded]

Соединение между вами и Эртелеком. С той и с другой стороны есть специалисты, способные продебажить это подключение, найти и устранить проблему. Также есть взаимовыгодные соглашения, которые создают доп. мотивации по этому вопросу. Форум по Астериск в этом процессе - лишнее звено, дебаг по логам только с одной стороны, и пр.

мочите саппорт

©

[Vlad1983]

в sip.conf
[general]
t38pt_udptl=yes
...
[ertelecom002526594]
t38pt_udptl=yes,redundancy,maxdatagram=400
...

в udptl.conf
[general]
udptlstart=4000
udptlend=4999
udptlfecentries = 3
udptlfecspan = 3
use_even_ports = no

в фаерволе открыть UDP 4000:4999

[mapt]

все так как написано, но безрезультатно...

лог:

Код: Выделить всё

    -- Executing [faxout@faxsend-t38:5] Set("SIP/ertelecom002526594-00000028", "FAXFILE=80a715ae-7165-4565-ad97-17a989d4af7a.tif") in new stack
    -- Executing [faxout@faxsend-t38:6] Set("SIP/ertelecom002526594-00000028", "FAXOPT(ecm)=yes") in new stack
    -- Executing [faxout@faxsend-t38:7] Set("SIP/ertelecom002526594-00000028", "FAXOPT(headerinfo)=IBS-Alfa") in new stack
    -- Executing [faxout@faxsend-t38:8] Set("SIP/ertelecom002526594-00000028", "FAXOPT(maxrate)=14400") in new stack
    -- Executing [faxout@faxsend-t38:9] Set("SIP/ertelecom002526594-00000028", "FAXOPT(minrate)=4800") in new stack
    -- Executing [faxout@faxsend-t38:10] Set("SIP/ertelecom002526594-00000028", "FAXOPT(localstationid)=+7(8442)600-200") in new stack
    -- Executing [faxout@faxsend-t38:12] SendFAX("SIP/ertelecom002526594-00000028", "/mnt/asterisk_call_records/faxes/80a715ae-7165-4565-ad97-17a989d4af7a.tif,dfzs") in new stack
    -- Channel 'SIP/ertelecom002526594-00000028' sending FAX:
    --    /mnt/asterisk_call_records/faxes/80a715ae-7165-4565-ad97-17a989d4af7a.tif
  == Using UDPTL CoS mark 5
  == Spawn extension (faxsend-t38, faxout, 12) exited non-zero on 'SIP/ertelecom002526594-00000028'
[Sep  3 13:56:05] NOTICE[30022]: pbx_spool.c:402 attempt_thread: Call completed to Local/send@fax_with_threads

что касается портов - все открыто:

Код: Выделить всё

astsrv ~ # iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain FORWARD (policy DROP)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

[Vlad1983]

снимать дамп трафика
анализировать

[tma]

что касается портов - все открыто:

А проброшено? С T38 не все так шоколадно, если есть NAT. Многое зависит от того, кто начинает сессию и прочее-прочее.
Для простоты в основном шлют в G711 и не парятся.

[mapt]

спасибо за наводку. действительно, много ифнормации что все "не так просто", но что именно откопать не удалось.
дополнительный проброс не делал, форвард всего и так открыт в обе стороны.

соединение устанавливает, насколько я понимаю, наш сервер, находящийся за натом.

вот что в дампе на этом сервере:

Код: Выделить всё

astsrv ~ # tcpdump -nn -v -s0 portrange 4000-4999
14:59:05.016861 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 34)
    192.168.0.65.4810 > 188.187.253.2.11344: UDP, length 6
14:59:05.216846 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 36)
    192.168.0.65.4810 > 188.187.253.2.11344: UDP, length 8

а вот дамп со шлюза

Код: Выделить всё

mgsrv ~ # tcpdump -nn -v -s0 portrange 4000-4999 and \(src 188.187.253.3 or dst 188.187.253.3 or src 188.187.253.1 or dst 188.187.253.1 or src 188.187.253.2 or dst 188.187.253.2\)
14:59:05.230741 IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto UDP (17), length 34) 88.87.76.35.4810 > 188.187.253.2.11344: UDP, length 6
14:59:05.430728 IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto UDP (17), length 36) 88.87.76.35.4810 > 188.187.253.2.11344: UDP, length 8

ничего "криминального" вроде нет. можно было грешить на проброс, но с эртелекома даже ничего на шлюз не приходит, чтобы это можно было "пробрасывать"...

[mapt]

что касается портов - все открыто:

А проброшено? С T38 не все так шоколадно, если есть NAT. Многое зависит от того, кто начинает сессию и прочее-прочее.
Для простоты в основном шлют в G711 и не парятся.

беда действительно оказалась с натом.
настроил с использованием http://asterisk-pbx.ru/wiki/doku.php/nat :
* прописал localnet и externip
* пробросил 5060, rtp, udptl

и собственно заработало более-менее...

[tma]

Сняв дамп и посмотрев в wireshark можно увидеть, что пакеты не доходят.
Дело в том, что NAT не знает что делать с входящими пакетами, поэтому нужен именно проброс портов
либо инициировать сессию нужно из-за NAT - в этом случае NAT будет знать, куда перенаправить
входящий запрос. Правда еще многое от NAT зависит...