[asterisk-users] Fax throughput - Asterisk 1.6.1.9

[Kevin P. Fleming]

Cyprus VoIP wrote:

> 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
> -----------

This is probably originating from a Cisco gateway. Cisco gateways
generate T.38 SDPs that do not conform to the T.38 recommendation in one
very obvious (and painful) way: they tell us that they can only accept
72 byte packets (T38FaxMaxDatagram), when in fact they can accept
packets much larger than that. When you notice that they are also
requesting that we use t38UDPRedundancy for error correction, that means
that the maximum IFP (single FAX protocol packet) we can include in a
UDPTL datagram is around 30 bytes, since we'd need to have room for two
of them and a bit of overhead. 30 bytes is a ridiculously small limit
for IFPs, and does not allow successful FAXing at any possible bit rate
(except for 2400 bits per second using 10 millisecond IFPs, but no FAX
stack would do that).

There is code in Asterisk already to deal with this problem, however...
see below.

> 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.

Have you followed these instructions? The message is fairly clear in
describing the problem, and the description of how and why this is
needed is spelled out in the sip.conf.sample file in the configs
directory of the source tree.

Setting a lower limit for the max datagram value used when communicating
with this peer (and others like it that generate incorrect
T38FaxMaxDatagram values) will resolve this problem.

-- 
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
skype: kpfleming | jabber: kpfleming at digium.com
Check us out at www.digium.com & www.asterisk.org