[asterisk-users] Fax throughput - Asterisk 1.6.1.9

[Cyprus VoIP]

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

Hi,

Yes. I saw the message and the required addition in the sip.conf. The 
problem is that if I set it to 72, other terminating gateways that 
support 400 or more would also be limited to 72.

What doesn't make sense is Asterisk's "commission". Why doesn't it 
simply pass/use whatever it gets without cutting the values? It looks 
like it's a bug.

Alternatively, I could (had I known how ;-)) set this ATA not to relay 
the RTP via Asterisk, in which case maybe Asterisk would leave the 
values unchanged. When I use another port on this ATA from the same 
location to the same destination without passing through the Asterisk, 
the faxes go through. How should I define this peer in sip.conf so that 
Asterisk wouldn't relay the RTP for it?

Thanks,

Andreas