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