Re: [asterisk-users] Asterisk 1.6.1.11 Fax
Steve Underwood wrote: Something is wrong if Asterisk is sending: a=T38FaxFillBitRemoval a=T38FaxTranscodingMMR a=T38FaxTranscodingJBIG Spandsp supports T38FaxFillBitRemoval, but neither spandsp or Commetrex support the other two options. The Commetrex guys have said so in the FoIP working group. Agreed... if he's actually running a FAX application on Asterisk. If this is a bridged call, the other endpoint may have offered to support those features. Without a description of the actual call scenario, we can only guess :-) -- 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
[asterisk-users] Asterisk 1.6.1.11 Fax
Hello, We're trying to receive faxes on the Asterisk server, but for the time being T.38 negotiation fails. The SDP that the Asterisk reINVITE sends contains these lines: -- m=image 4968 udptl t38 a=T38FaxVersion:0 a=T38MaxBitRate:9600 a=T38FaxFillBitRemoval a=T38FaxTranscodingMMR a=T38FaxTranscodingJBIG a=T38FaxRateManagement:transferredTCF a=T38FaxMaxDatagram:1400 a=T38FaxUdpEC:t38UDPRedundancy -- The MaxDatagram and MaxBitRate are definitely not what they should be, and maybe other parameters are also wrong. I would like to have 400 and 14400 respectively. That's the udptl.conf: -- ; ; UDPTL Configuration (UDPTL is one of the transports for T.38) ; [general] ; ; UDPTL start and UDPTL end configure start and end addresses ; udptlstart=4000 udptlend=4999 ; ; Whether to enable or disable UDP checksums on UDPTL traffic ; ;udptlchecksums=no ; ; The number of error correction entries in a UDPTL packet ; udptlfecentries = 3 ; ; The error correction type to be sent ; ;T38FaxUdpEC = t38UDPFEC T38FaxUdpEC = t38UDPRedundancy ; ; The maximum length of a UDPTL packet ; ;T38FaxMaxBuffer = 200 T38FaxMaxDatagram = 400 VoipFaxMaxRate = 5 ; The span over which parity is calculated for FEC in a UDPTL packet ; udptlfecspan = 3 ; ; Some VoIP providers will only accept an offer with an even-numbered ; UDPTL port. Set this option so that Asterisk will only attempt to use ; even-numbered ports when negotiating T.38. Default is no. use_even_ports = yes -- Can anyone help us identify the problem? 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
Re: [asterisk-users] Asterisk 1.6.1.11 Fax
Cyprus VoIP wrote: We're trying to receive faxes on the Asterisk server, but for the time being T.38 negotiation fails. The SDP that the Asterisk reINVITE sends contains these lines: -- m=image 4968 udptl t38 a=T38FaxVersion:0 a=T38MaxBitRate:9600 a=T38FaxFillBitRemoval a=T38FaxTranscodingMMR a=T38FaxTranscodingJBIG a=T38FaxRateManagement:transferredTCF a=T38FaxMaxDatagram:1400 a=T38FaxUdpEC:t38UDPRedundancy -- The MaxDatagram and MaxBitRate are definitely not what they should be, and maybe other parameters are also wrong. I would like to have 400 and 14400 respectively. There is no point in having a smaller T38FaxMaxDatagram value; Asterisk's FAX applications can handle larger packets than 400 bytes, so Asterisk is telling the sending endpoint that it can send them if it wishes to do so. As far as the T38MaxBitRate, that is only a suggestion in the negotiation, and rarely has any effect on the negotiation process or on the resulting FAX transmission. As before, you've provided only a very small amount of information, not enough to be able to help you determine what is wrong. Nothing in that SDP offer indicate any problems of any kind. In addition, you haven't indicated which FAX applications in Asterisk you are using (app_fax or res_fax), which could also have an impact on the T.38 negotiation process. If you'd like people to be able to help you debug problems, you need to provide enough information for them to do so; most of us are not clairvoyant, telepathic or omniscient. In any situation where T.38 negotiation is failing, that means a 'sip set debug on' log trace that shows the entire T.38 negotiation transaction, ideally with 'core set debug 10' and 'core set verbose 10' as well so we can see all the actions that Asterisk and the FAX application took during the negotiation process. -- 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
Re: [asterisk-users] Asterisk 1.6.1.11 Fax
We're trying to receive faxes on the Asterisk server, but for the time being T.38 negotiation fails. The SDP that the Asterisk reINVITE sends contains these lines: -- m=image 4968 udptl t38 a=T38FaxVersion:0 a=T38MaxBitRate:9600 a=T38FaxFillBitRemoval a=T38FaxTranscodingMMR a=T38FaxTranscodingJBIG a=T38FaxRateManagement:transferredTCF a=T38FaxMaxDatagram:1400 a=T38FaxUdpEC:t38UDPRedundancy -- The MaxDatagram and MaxBitRate are definitely not what they should be, and maybe other parameters are also wrong. I would like to have 400 and 14400 respectively. There is no point in having a smaller T38FaxMaxDatagram value; Asterisk's FAX applications can handle larger packets than 400 bytes, so Asterisk is telling the sending endpoint that it can send them if it wishes to do so. As far as the T38MaxBitRate, that is only a suggestion in the negotiation, and rarely has any effect on the negotiation process or on the resulting FAX transmission. As before, you've provided only a very small amount of information, not enough to be able to help you determine what is wrong. Nothing in that SDP offer indicate any problems of any kind. In addition, you haven't indicated which FAX applications in Asterisk you are using (app_fax or res_fax), which could also have an impact on the T.38 negotiation process. If you'd like people to be able to help you debug problems, you need to provide enough information for them to do so; most of us are not clairvoyant, telepathic or omniscient. In any situation where T.38 negotiation is failing, that means a 'sip set debug on' log trace that shows the entire T.38 negotiation transaction, ideally with 'core set debug 10' and 'core set verbose 10' as well so we can see all the actions that Asterisk and the FAX application took during the negotiation process. Hi Kevin, thank you for your response. Before posting my question, I analyzed the entire SIP negotiation and it was fine. The problem began in the T.38 negotiation itself, after the Asterisk's reINVITE. I don't have the old calls traces anymore, but I'll make new ones tomorrow and post them here. Regarding the MaxBitRate, is it possible to increase it to 14400 or is 9600 the max allowed? Regards, 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
Re: [asterisk-users] Asterisk 1.6.1.11 Fax
Cyprus VoIP wrote: Before posting my question, I analyzed the entire SIP negotiation and it was fine. The problem began in the T.38 negotiation itself, after the Asterisk's reINVITE. I don't have the old calls traces anymore, but I'll make new ones tomorrow and post them here. The T.38 negotiation is part of the SIP negotiation, so that comment doesn't make a lot of sense. Regarding the MaxBitRate, is it possible to increase it to 14400 or is 9600 the max allowed? It is controlled by the endpoint that is performing the T.38 negotiation in Asterisk, either an application or a channel driver (if the call is bridged to another channel). It can be set to any value allowed by the T.38 Recommendation, but it will only be set to values that the application actually supports. Increasing it is no way going to make your T.38 negotiation succeed if they are failing, nor will it make FAXes work if they are failing. It's purely an informational element. -- 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
Re: [asterisk-users] Asterisk 1.6.1.11 Fax
On 12/11/2009 03:33 AM, Kevin P. Fleming wrote: Cyprus VoIP wrote: Before posting my question, I analyzed the entire SIP negotiation and it was fine. The problem began in the T.38 negotiation itself, after the Asterisk's reINVITE. I don't have the old calls traces anymore, but I'll make new ones tomorrow and post them here. The T.38 negotiation is part of the SIP negotiation, so that comment doesn't make a lot of sense. Regarding the MaxBitRate, is it possible to increase it to 14400 or is 9600 the max allowed? It is controlled by the endpoint that is performing the T.38 negotiation in Asterisk, either an application or a channel driver (if the call is bridged to another channel). It can be set to any value allowed by the T.38 Recommendation, but it will only be set to values that the application actually supports. Increasing it is no way going to make your T.38 negotiation succeed if they are failing, nor will it make FAXes work if they are failing. It's purely an informational element. Something is wrong if Asterisk is sending: a=T38FaxFillBitRemoval a=T38FaxTranscodingMMR a=T38FaxTranscodingJBIG Spandsp supports T38FaxFillBitRemoval, but neither spandsp or Commetrex support the other two options. The Commetrex guys have said so in the FoIP working group. Regards, Steve ___ -- 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
