[asterisk-bugs] [Asterisk 0015903]: udptl.conf parameter T38FaxUdpEC is not working correctly if set to t38UDPRedundancy

[Asterisk Bug Tracker]

The following issue has been UPDATED. 
====================================================================== 
https://issues.asterisk.org/view.php?id=15903 
====================================================================== 
Reported By:                schern
Assigned To:                kpfleming
====================================================================== 
Project:                    Asterisk
Issue ID:                   15903
Category:                   Channels/chan_sip/T.38
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     closed
Asterisk Version:           1.6.1.6 
JIRA:                        
Regression:                 No 
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Request Review:              
Resolution:                 no change required
Fixed in Version:           
====================================================================== 
Date Submitted:             2009-09-15 12:55 CDT
Last Modified:              2009-10-01 11:02 CDT
====================================================================== 
Summary:                    udptl.conf parameter T38FaxUdpEC is not working
correctly if set to t38UDPRedundancy
Description: 
If I set the parameter T38FaxUdpEC = t38UDPRedundancy in udptl.conf the SDP
part of the T.38 re-INVITE from Asterisk to the carrier always contains the
wrong EC method:
[...]
a=T38FaxMaxDatagram:140
a=T38FaxUdpEC:t38UDPFEC
[...]

Correct would be a=T38FaxUdpEC:t38UDPRedundancy.

In Asterisk v1.6.0.6 and 1.4.x the EC method is set correctly to the value
of the udptl.conf.
====================================================================== 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-10-01 11:02 kpfleming      Status                   assigned => closed  
2009-10-01 11:02 kpfleming      Resolution               open => no change
required
======================================================================