Hello, We upgraded the Asterisk to 1.6.1.11. Now, there's no RTP reINVITE, but the datagram handling of Asterisk is strange. Basically, it "takes a commission" from both ends, and ends up overflowing:
Reminder, we're dealing in this example with a passthrough, where we have an ATA device connected to Asterisk in the same LAN, the Asterisk is registered to a remote SIP Proxy server and behind it, a Fax server. 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 ----------- Asterisk sends this reINVITE SDP to the ATA device (notice that the datagram was reduced by 2): ----------- Content-Type: application/sdp Content-Length: 269 v=0 o=root 318120000 318120001 IN IP4 192.168.2.10 s=Asterisk PBX 1.6.1.11 c=IN IP4 192.168.2.10 t=0 0 m=image 4427 udptl t38 a=T38FaxVersion:0 a=T38MaxBitRate:14400 a=T38FaxRateManagement:transferredTCF a=T38FaxMaxDatagram:70 a=T38FaxUdpEC:t38UDPRedundancy ----------- Then, it gets OK SDP from the ATA with the same settings it suggested: ----------- Content-Type: application/sdp Content-Length: 275 v=0 o=101 0000000001 0000000002 IN IP4 192.168.2.11 s=A conversation c=IN IP4 192.168.2.11 t=0 0 m=image 9100 udptl t38 a=T38FaxVersion:0 a=T38MaxBitRate:14400 a=T38FaxRateManagement:transferredTCF a=T38FaxMaxDatagram:70 a=T38FaxUdpEC:t38UDPRedundancy a=sendrecv ----------- But, when it sends the OK SDP to the remote end, it lowers the datagram again: ----------- Content-Type: application/sdp Content-Length: 275 v=0 o=root 936220937 936220938 IN IP4 xxx.xxx.xxx.xxx s=Asterisk PBX 1.6.1.11 c=IN IP4 xxx.xxx.xxx.xxx t=0 0 m=image 4650 udptl t38 a=T38FaxVersion:0 a=T38MaxBitRate:14400 a=T38FaxRateManagement:transferredTCF a=T38FaxMaxDatagram:65 a=T38FaxUdpEC:t38UDPRedundancy ----------- Then, when the ATA device sends T.38 packets, it freaks outs: ----------- 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. [Dec 15 12:38:05] ERROR[5262]: udptl.c:291 encode_open_type: Buffer overflow detected (77 + 3 > 72) [Dec 15 12:38:05] NOTICE[5262]: udptl.c:1010 ast_udptl_write: UDPTL Transmission error to 194.98.xxx.xxx:17548: Message too long Sent UDPTL packet to 194.98.xxx.xxx:17548 (type 0, seq 35, len -1) pbx*CLI> Got UDPTL packet from 192.168.2.11:9100 (type 0, seq 0, len 162) [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. [Dec 15 12:38:05] ERROR[5262]: udptl.c:291 encode_open_type: Buffer overflow detected (77 + 3 > 72) [Dec 15 12:38:05] NOTICE[5262]: udptl.c:1010 ast_udptl_write: UDPTL Transmission error to 194.98.xxx.xxx:17548: Message too long ----------- Thank you for your kind assistance and support. Regards, Andreas -------- Original Message -------- Subject: Re: [asterisk-users] Fax throughput - Asterisk 1.6.1.9 From: Cyprus VoIP <voi...@gmail.com> To: Asterisk Users Mailing List - Non-Commercial Discussion <asterisk-users@lists.digium.com> Date: Friday, 04 December, 2009 18:21:59 >> It's probably because you are using 1.6.1.9; that release (and older) >> had a 'feature' that allowed automatic switching back to audio from T.38 >> if one of the endpoints sent an audio packet. It turns out that wasn't a >> good idea, and it's been removed... but in later versions. You'll have >> to update to the latest release to get that fixed. >> > > Will do. Thanks for the explanation. _______________________________________________ -- 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