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