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: kpflem...@digium.com Check us out at www.digium.com & www.asterisk.org _______________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users