Пожалуйста, войдите здесь. Часто задаваемые вопросы О нас
Задайте Ваш вопрос

Не ходят факсы t38

0

Добрый день!

Схема такая Провайдер - FreePBX - шлюз TAU-32M.IP

192.168.0.10 - FreePBX

192.168.0.11 - шлюз Eltex TAU-32M.IP

FreePBX подключен к провайдеру в приватной сети (nat=no) На шлюзе первичный кодек t.38

Думаю какие версии ПО, пока не важно, вот, что заметил в логах:

[2014-01-15 14:55:36] DEBUG[13218] chan_sip.c: **** Received INVITE (5) - Command in SIP INVITE
[2014-01-15 14:55:36] DEBUG[13218] netsock2.c: Splitting '192.168.0.11' into...
[2014-01-15 14:55:36] DEBUG[13218] netsock2.c: ...host '192.168.0.11' and port ''.
[2014-01-15 14:55:36] DEBUG[13218] chan_sip.c: Initializing initreq for method INVITE - callid 13a3d6a92a54a0a03ed3fa153da60422@192.168.0.10:5060
[2014-01-15 14:55:36] DEBUG[13218] chan_sip.c: Processing session-level SDP v=0... UNSUPPORTED OR FAILED.
[2014-01-15 14:55:36] DEBUG[13218] chan_sip.c: Processing session-level SDP o=- 4389814247491607704 6221776344004297953 IN IP4 192.168.0.11... OK.
[2014-01-15 14:55:36] DEBUG[13218] chan_sip.c: Processing session-level SDP s=Session SDP... UNSUPPORTED OR FAILED.
[2014-01-15 14:55:36] DEBUG[13218] netsock2.c: Splitting '192.168.0.11' into...
[2014-01-15 14:55:36] DEBUG[13218] netsock2.c: ...host '192.168.0.11' and port ''.
[2014-01-15 14:55:36] DEBUG[13218] chan_sip.c: Processing session-level SDP c=IN IP4 192.168.0.11... OK.
[2014-01-15 14:55:36] DEBUG[13218] chan_sip.c: Processing session-level SDP t=0 0... UNSUPPORTED OR FAILED.
[2014-01-15 14:55:36] DEBUG[13218] rtp_engine.c: Setting payload 8 based on m type on 0x7f5b90089ee0
[2014-01-15 14:55:36] DEBUG[13218] chan_sip.c: Processing media-level (audio) SDP a=rtpmap:8 PCMA/8000... OK.
[2014-01-15 14:55:36] DEBUG[13218] chan_sip.c: Processing media-level (audio) SDP a=rtpmap:96 telephone-event/8000... OK.
[2014-01-15 14:55:36] DEBUG[13218] chan_sip.c: Processing media-level (audio) SDP a=fmtp:96 0-16... UNSUPPORTED OR FAILED.
[2014-01-15 14:55:36] DEBUG[13218] chan_sip.c: T38 state changed to 0 on channel SIP/101-00000020
[2014-01-15 14:55:36] DEBUG[13218] rtp_engine.c: Incorporating payload 8 on 0x7f5b90089ee0
[2014-01-15 14:55:36] DEBUG[13218] rtp_engine.c: Incorporating payload 96 on 0x7f5b90089ee0
[2014-01-15 14:55:36] DEBUG[13218] rtp_engine.c: Copying payload 8 from 0x7f5b90089ee0 to 0x7f5b70095e50
[2014-01-15 14:55:36] DEBUG[13218] rtp_engine.c: Copying payload 96 from 0x7f5b90089ee0 to 0x7f5b70095e50
[2014-01-15 14:55:36] DEBUG[13218] res_rtp_asterisk.c: Setup RTCP on RTP instance '0x7f5b70095c88'
[2014-01-15 14:55:36] DEBUG[13218] chan_sip.c: Peer doesn't provide T.38 UDPTL
[2014-01-15 14:55:36] DEBUG[13218] chan_sip.c: We're settling with these formats: 0x8 (alaw)
[2014-01-15 14:55:36] DEBUG[13218] chan_sip.c: We have an owner, now see if we need to change this call

Вроде как, что то с SDP сессией? Или на факсы это не влияет?

удалить закрыть спам изменить тег редактировать

спросил 2014-01-15 16:21:17 +0400

2life Gravatar 2life
20 15 5 16

обновил 2014-01-15 18:55:52 +0400

Comments

Читать умею [2014-01-15 14:55:36] DEBUG[13218] chan_sip.c: Peer doesn't provide T.38 UDPTL, но по факту если соединить шлюз и провайдера без АТС, я уверен факсы пойдут.

2life ( 2014-01-15 19:07:21 +0400 )редактировать

1 Ответ

0
ссылка удалить спам редактировать

ответил 2014-01-15 19:04:54 +0400

awsswa Gravatar awsswa flag of Russian Federation
685 5 2 9

Comments

Да, прочитал, спасибо конечно. T.38 пакеты ходят в обе стороны, но передача факса так и не начинается. По факту имею от провайдера: 36117 2014-01-15 12:56:25.117482 xxx.xxx.xxx.xxx 10.10.10.10 T.38 62 UDP: UDPTLPacket Seq=00000 t30ind: no-signal

2life ( 2014-01-15 19:35:35 +0400 )редактировать

снимайте дамп на оба плеча и выкладывайте на обменник - я посмотрю.

awsswa ( 2014-01-15 19:56:12 +0400 )редактировать

Попробовал, на виртуальный факс. Факсы работают, хотя есть всё таже ошибка Peer doesn't provide T.38 UDPTL Получается, она не влияет ни на что.

2life ( 2014-01-15 20:04:04 +0400 )редактировать

дамп снял, отправил в личку.

2life ( 2014-01-15 20:32:24 +0400 )редактировать

awsswa большое спасибо за помощь. В общем люди самое главное люди делайте дамп на два плеча, потом прослушивайте его, через Wireshark. В моём случае проблема была с шумоподавлением.

2life ( 2014-01-22 23:34:17 +0400 )редактировать

Ваш ответ

Please start posting your answer anonymously - your answer will be saved within the current session and published after you log in or create a new account. Please try to give a substantial answer, for discussions, please use comments and please do remember to vote (after you log in)!
[скрыть предварительный просмотр]

Закладки и информация

Добавить закладку

подписаться на rss ленту новостей

Статистика

Задан: 2014-01-15 16:21:17 +0400

Просмотрен: 510 раз

Обновлен: Jan 15 '14

Проект компании "АТС Дизайн"
Asterisk® и Digium® являются зарегистрированными торговыми марками компании Digium, Inc., США.
IP АТС Asterisk распространяется под лицензией GNU GPL.