[asterisk-users] Fax throughput - Asterisk 1.6.1.9

[JR Richardson]

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

I was having similar issues, trying Asterisk 1.6.1.12-rc1 resolved it.

http://www.mail-archive.com/asterisk-users@lists.digium.com/msg234015.html

Good luck.

JR
-- 
JR Richardson
Engineering for the Masses