[asterisk-users] Fax throughput - Asterisk 1.6.1.9

[Cyprus VoIP]

Hello,

We upgraded the Asterisk to 1.6.1.11. Now, there's no RTP reINVITE, but 
the datagram handling of Asterisk is strange. Basically, it "takes a 
commission" from both ends, and ends up overflowing:

Reminder, we're dealing in this example with a passthrough, where we 
have an ATA device connected to Asterisk in the same LAN, the Asterisk 
is registered to a remote SIP Proxy server and behind it, a Fax server.

This is the reINVITE SDP received from the SIP Proxy:
-----------
Content-Type: application/sdp
Content-Length: 353

v=0
o=root 30427 30428 IN IP4 194.98.xxx.xxx
s=session
c=IN IP4 194.98.xxx.xxx
t=0 0
m=image 17548 udptl t38
a=T38FaxVersion:0
a=T38MaxBitRate:14400
a=T38FaxFillBitRemoval:0
a=T38FaxTranscodingMMR:0
a=T38FaxTranscodingJBIG:0
a=T38FaxRateManagement:transferredTCF
a=T38FaxMaxBuffer:72
a=T38FaxMaxDatagram:72
a=T38FaxUdpEC:t38UDPRedundancy
-----------

Asterisk sends this reINVITE SDP to the ATA device (notice that the 
datagram was reduced by 2):
-----------
Content-Type: application/sdp
Content-Length: 269

v=0
o=root 318120000 318120001 IN IP4 192.168.2.10
s=Asterisk PBX 1.6.1.11
c=IN IP4 192.168.2.10
t=0 0
m=image 4427 udptl t38
a=T38FaxVersion:0
a=T38MaxBitRate:14400
a=T38FaxRateManagement:transferredTCF
a=T38FaxMaxDatagram:70
a=T38FaxUdpEC:t38UDPRedundancy
-----------

Then, it gets OK SDP from the ATA with the same settings it suggested:
-----------
Content-Type: application/sdp
Content-Length:   275

v=0
o=101 0000000001 0000000002 IN IP4 192.168.2.11
s=A conversation
c=IN IP4 192.168.2.11
t=0 0
m=image 9100 udptl t38
a=T38FaxVersion:0
a=T38MaxBitRate:14400
a=T38FaxRateManagement:transferredTCF
a=T38FaxMaxDatagram:70
a=T38FaxUdpEC:t38UDPRedundancy
a=sendrecv
-----------

But, when it sends the OK SDP to the remote end, it lowers the datagram 
again:
-----------
Content-Type: application/sdp
Content-Length: 275

v=0
o=root 936220937 936220938 IN IP4 xxx.xxx.xxx.xxx
s=Asterisk PBX 1.6.1.11
c=IN IP4 xxx.xxx.xxx.xxx
t=0 0
m=image 4650 udptl t38
a=T38FaxVersion:0
a=T38MaxBitRate:14400
a=T38FaxRateManagement:transferredTCF
a=T38FaxMaxDatagram:65
a=T38FaxUdpEC:t38UDPRedundancy
-----------

Then, when the ATA device sends T.38 packets, it freaks outs:
-----------
pbx*CLI>  Got UDPTL packet from 192.168.2.11:9100 (type 0, seq 0, len 86)
[Dec 15 12:38:05] WARNING[5262]: udptl.c:997 ast_udptl_write: UDPTL 
asked to send 77 bytes of IFP when far end only prepared to accept 12 
bytes; data loss may occur. You may need to override the 
T38FaxMaxDatagram value for this endpoint in the channel driver 
configuration.
[Dec 15 12:38:05] ERROR[5262]: udptl.c:291 encode_open_type: Buffer 
overflow detected (77 + 3 > 72)
[Dec 15 12:38:05] NOTICE[5262]: udptl.c:1010 ast_udptl_write: UDPTL 
Transmission error to 194.98.xxx.xxx:17548: Message too long
  Sent UDPTL packet to 194.98.xxx.xxx:17548 (type 0, seq 35, len -1)
pbx*CLI>  Got UDPTL packet from 192.168.2.11:9100 (type 0, seq 0, len 162)
[Dec 15 12:38:05] WARNING[5262]: udptl.c:997 ast_udptl_write: UDPTL 
asked to send 77 bytes of IFP when far end only prepared to accept 12 
bytes; data loss may occur. You may need to override the 
T38FaxMaxDatagram value for this endpoint in the channel driver 
configuration.
[Dec 15 12:38:05] ERROR[5262]: udptl.c:291 encode_open_type: Buffer 
overflow detected (77 + 3 > 72)
[Dec 15 12:38:05] NOTICE[5262]: udptl.c:1010 ast_udptl_write: UDPTL 
Transmission error to 194.98.xxx.xxx:17548: Message too long
-----------

Thank you for your kind assistance and support.

Regards,

Andreas

-------- Original Message  --------
Subject: Re: [asterisk-users] Fax throughput - Asterisk 1.6.1.9
From: Cyprus VoIP <voipcy at gmail.com>
To: Asterisk Users Mailing List - Non-Commercial Discussion 
<asterisk-users at lists.digium.com>
Date: Friday, 04 December, 2009 18:21:59

>> It's probably because you are using 1.6.1.9; that release (and older)
>> had a 'feature' that allowed automatic switching back to audio from T.38
>> if one of the endpoints sent an audio packet. It turns out that wasn't a
>> good idea, and it's been removed... but in later versions. You'll have
>> to update to the latest release to get that fixed.
>>
> 
> Will do. Thanks for the explanation.