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

T38, рвется прием

0

Есть следующая схема на Asterisk 1.8.9.0. Оператор ---SIP--- Asterisk ---SIP--- Panasonic -> Факс. IP Панасоника 192.168.4.102 (103), Астериск 192.168.4.100, Оператор 188.187.255.7. Внешний абонент звонит и отправляет факс, оператор работает только по T38, соответственно на Asterisk стоит t38pt_udptl = yes. Прием факса осуществляется аппаратом на стороне Панасоника. SIP дебаг тот который должен быть при поднятии сессии Т38:

<--- SIP read from UDP:192.168.4.102:35060 --->
INVITE sip:ВХОДЯЩИЙ НОМЕР@192.168.4.100:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.4.102:35060;branch=z9hG4bK0000124c;rport
Max-Forwards: 70
To: "ВХОДЯЩИЙ НОМЕР" <sip:ВХОДЯЩИЙ НОМЕР@192.168.4.100>;tag=as4e53398e
From: sip:2231@192.168.4.102;tag=7013
Call-ID: 2283361d2e9465a3556a2ebd2236bf0c@192.168.4.100:5060
CSeq: 1 INVITE
Contact: sip:utde@192.168.4.102:35060
Supported: 100rel
Allow: INVITE,ACK,CANCEL,BYE,PRACK,OPTIONS,REGISTER,INFO,UPDATE
User-Agent: Panasonic-MPR08-V4.2003/VSIPGW-V2.3001
Content-Type: application/sdp
Content-Length: 302

v=0
o=- 0 1 IN IP4 192.168.4.103
s=-
c=IN IP4 192.168.4.103
t=0 0
m=image 12038 udptl t38
a=T38FaxVersion:0
a=T38FaxFillBitRemoval:0
a=T38FaxTranscodingMMR:0
a=T38FaxTranscodingJBIG:0
a=T38FaxRateManagement:transferredTCF
a=T38FaxMaxDatagram:512
a=T38FaxUdpEC:t38UDPRedundancy
a=sendrecv
<------------->

Sending to 192.168.4.102:35060 (no NAT)
Got T.38 offer in SDP in dialog 2283361d2e9465a3556a2ebd2236bf0c@192.168.4.100:5060
Capabilities: us - 0xc (ulaw|alaw), peer - audio=0x0 (nothing)/video=0x0 (nothing)/text=0x0 (nothing), combined - 0x0 (nothing)
Non-codec capabilities (dtmf): us - 0x1 (telephone-event|), peer - 0x0 (nothing), combined - 0x0 (nothing)
Got T.38 Re-invite without audio. Keeping RTP active during T.38 session.


Transmitting (no NAT) to 192.168.4.102:35060 --->
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 192.168.4.102:35060;branch=z9hG4bK0000124c;received=192.168.4.102;rport=35060
From: sip:2231@192.168.4.102;tag=7013
To: "ВХОДЯЩИЙ НОМЕР" <sip:ВХОДЯЩИЙ НОМЕР@192.168.4.100>;tag=as4e53398e
Call-ID: 2283361d2e9465a3556a2ebd2236bf0c@192.168.4.100:5060
CSeq: 1 INVITE
Server: Asterisk PBX 1.8.9.0
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
Contact: <sip:ВХОДЯЩИЙ НОМЕР@192.168.4.100:5060>
Content-Length: 0
<------------>

<--- Reliably Transmitting (no NAT) to 192.168.4.102:35060 --->
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.4.102:35060;branch=z9hG4bK0000124c;received=192.168.4.102;rport=35060
From: sip:2231@192.168.4.102;tag=7013
To: "ВХОДЯЩИЙ НОМЕР" <sip:ВХОДЯЩИЙ НОМЕР@192.168.4.100>;tag=as4e53398e
Call-ID: 2283361d2e9465a3556a2ebd2236bf0c@192.168.4.100:5060
CSeq: 1 INVITE
Server: Asterisk PBX 1.8.9.0
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
Contact: <sip:ВХОДЯЩИЙ НОМЕР@192.168.4.100:5060>
Content-Type: application/sdp
Content-Length: 270

v=0
o=root 466464297 466464298 IN IP4 192.168.4.100
s=Asterisk PBX 1.8.9.0
c=IN IP4 192.168.4.100
t=0 0
m=image 4465 udptl t38
a=T38FaxVersion:0
a=T38MaxBitRate:2400
a=T38FaxRateManagement:transferredTCF
a=T38FaxMaxDatagram:397
a=T38FaxUdpEC:t38UDPRedundancy 

<--- SIP read from UDP:192.168.4.102:35060 --->
ACK sip:ВХОДЯЩИЙ НОМЕР@192.168.4.100:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.4.102:35060;branch=z9hG4bK000015c7;rport
Max-Forwards: 70
To: "ВХОДЯЩИЙ НОМЕР" <sip:ВХОДЯЩИЙ НОМЕР@192.168.4.100>;tag=as4e53398e
From: sip:2231@192.168.4.102;tag=7013
Call-ID: 2283361d2e9465a3556a2ebd2236bf0c@192.168.4.100:5060
CSeq: 1 ACK
Content-Length: 0

После это UDPTL debug:

UDPTL (SIP/utde-00000b19): packet from 192.168.4.103:12038 (seq 0, len 6)
UDPTL (SIP/188.187.255.4-00000b18): packet to 188.187.255.7:24330 (seq 0, len 6)
...
...
...

UDPTL (SIP/188.187.255.4-00000b18): packet from 188.187.255.7:24330 (seq 1752, len 58)
UDPTL (SIP/utde-00000b19): packet to 192.168.4.103:12038 (seq 1752, len 76)

Scheduling destruction of SIP dialog '2283361d2e9465a3556a2ebd2236bf0c@192.168.4.100:5060' in 32000 ms (Method: ACK)

set_destination: Parsing <sip:utde@192.168.4.102:35060> for address/port to send to
set_destination: set destination to 192.168.4.102:35060
Reliably Transmitting (no NAT) to 192.168.4.102:35060:
BYE sip:utde@192.168.4.102:35060 SIP/2.0

Via: SIP/2.0/UDP 192.168.4.100:5060;branch=z9hG4bK35baf329;rport
Max-Forwards: 70
From: "ВХОДЯЩИЙ НОМЕР" <sip:ВХОДЯЩИЙ НОМЕР@192.168.4.100>;tag=as4e53398e
sip:2231@192.168.4.102;tag=7013
Call-ID: 2283361d2e9465a3556a2ebd2236bf0c@192.168.4.100:5060
CSeq: 103 BYE
User-Agent: Asterisk PBX 1.8.9.0
X-Asterisk-HangupCause: Normal Clearing
X-Asterisk-HangupCauseCode: 16
Content-Length: 0
---

<--- SIP read from UDP:192.168.4.102:35060 --->
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.4.100:5060;branch=z9hG4bK35baf329;rport=5060
To: sip:2231@192.168.4.102;tag=7013
From: "ВХОДЯЩИЙ НОМЕР" <sip:ВХОДЯЩИЙ НОМЕР@192.168.4.100>;tag=as4e53398e
Call-ID: 2283361d2e9465a3556a2ebd2236bf0c@192.168.4.100:5060
CSeq: 103 BYE
Content-Length: 0
<------------->
--- (7 headers 0 lines) ---

SIP Response message for INCOMING dialog BYE arrived
Really destroying SIP dialog '2283361d2e9465a3556a2ebd2236bf0c@192.168.4.100:5060' Method: ACK

Почему рвется? Никак не до пру. Есть какие то мысли, что делаю не так? На 1.6.2.20 в аналогичной конфигурации работало.

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

спросил 2012-02-09 08:23:20 +0400

Ecuador Gravatar Ecuador
845 10 9 23

1 Ответ

0

Не совсем понятно, что у вас там к чему. Замечу лишь что астериск не возвращает канал в исходное состояние после сессии т38

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

ответил 2012-02-09 09:50:06 +0400

switch Gravatar switch
8334 11 7 91
http://lynks.ru/

Comments

Дак собственно сессия не заканчивается до конца

Ecuador ( 2012-02-09 10:38:00 +0400 )редактировать

попробуйте T38FaxMaxDatagram поиграться.

meral ( 2012-02-09 12:06:27 +0400 )редактировать

В какую сторону, до 512 пробовал. До этого 400 стояло

Ecuador ( 2012-02-09 12:17:17 +0400 )редактировать

я обычно пробую 160 240, 200, 400,800.

meral ( 2012-02-09 16:24:00 +0400 )редактировать

Попробую конечно, но по ощущению проблема не в этом

Ecuador ( 2012-02-10 10:09:41 +0400 )редактировать

На Астериске вообще какие рамки этого параметра? На Панасе 272 - 512.

Ecuador ( 2012-02-10 10:35:02 +0400 )редактировать

астериску вроде вообещ все равно. может еще быть что у вас fax ecm а не redunancy

meral ( 2012-02-10 15:11:51 +0400 )редактировать

Меня смущает "Scheduling destruction of SIP dialog '2283361d2e9465a3556a2ebd2236bf0c@192.168.4.100:5060' in 32000 ms (Method: ACK)"

Ecuador ( 2012-02-10 18:05:09 +0400 )редактировать

чем это? это вполне нормальное сообщение. аименно, если не прийдет подтверждение твчото случилосяс сервером на том конце инадо сделать hangup.

meral ( 2012-02-11 09:40:16 +0400 )редактировать

Как раз после него все рушится

Ecuador ( 2012-02-11 14:08:19 +0400 )редактировать

Ветка 1.6.2.Х работает, косяк в 1.8

Ecuador ( 2012-02-13 13:57:45 +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 ленту новостей

Статистика

Задан: 2012-02-09 08:23:20 +0400

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

Обновлен: Feb 09 '12

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