Commit Graph

4 Commits

Author SHA1 Message Date
Kevin P. Fleming 20743ec07d Allow non-compliant T.38 endpoints to be supportable via configuration option.
Many T.38 endpoints incorrectly send the maximum IFP frame size they can accept
as the T38FaxMaxDatagram value in their SDP, when in fact this value is
supposed to be the maximum UDPTL payload size (datagram size) they can accept.
If the value they supply is small enough (a commonly supplied value is '72'),
T.38 UDPTL transmissions will likely fail completely because the UDPTL packets
will not have enough room for a primary IFP frame and the redundancy used for
error correction. If this occurs, the Asterisk UDPTL stack will emit log messages
warning that data loss may occur, and that the value may need to be overridden.

This patch extends the 't38pt_udptl' configuration option in sip.conf to allow
the administrator to override the value supplied by the remote endpoint and
supply a value that allows T.38 FAX transmissions to be successful with that
endpoint. In addition, in any SIP call where the override takes effect, a debug
message will be printed to that effect. This patch also removes the
T38FaxMaxDatagram configuration option from udptl.conf.sample, since it has not
actually had any effect for a number of releases.

In addition, this patch cleans up the T.38 documentation in sip.conf.sample
(which incorrectly documented that T.38 support was passthrough only).

(issue #15586)
Reported by: globalnetinc


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@222110 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-10-05 19:45:00 +00:00
Kevin P. Fleming 19ba91cd22 Remove ability to control T.38 FAX error correction from udptl.conf.
chan_sip has had the ability to control T.38 FAX error correction mode on a per-peer
(or global) basis for a couple of releases now, which is where it should have been
all along. This patch removes the ability to configure it in udptl.conf, but issues
a warning if the user tries to do, telling them to look at sip.conf.sample for how
to configure it now. For any SIP peers that are T.38 enabled in sip.conf, there is
already a default for FEC error correction even if the user does not specify any mode,
so this change will not turn off error correction by default, it will have the same
default value that has been in the udptl.conf sample file.



git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@221592 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-10-01 16:16:09 +00:00
Mark Michelson ba8dcde549 Merged revisions 209131 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
  r209131 | mmichelson | 2009-07-27 12:44:06 -0500 (Mon, 27 Jul 2009) | 18 lines
  
  Allow for UDPTL to use only even-numbered ports if desired.
  
  There are some VoIP providers out there that will not accept SDP
  offers with odd numbered UDPTL ports. While it is my personal opinion
  that these VoIP providers are misinterpreting RFC 2327, it really is
  not a big deal to play along with their silly little games. Of course,
  since restricting UDPTL ports to only even numbers reduces the range
  of available ports by half, so the option to use only even port numbers
  is off by default. A user can enable the behavior by setting
  use_even_ports=yes in udptl.conf.
  
  (closes issue #15182)
  Reported by: CGMChris
  Patches:
        15182.patch uploaded by mmichelson (license 60)
  Tested by: CGMChris
........


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@209132 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-07-27 17:50:04 +00:00
Tilghman Lesher 2a9a03e6f0 Bug 5090 - sample configuration for udptl packets
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@8102 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2006-01-16 18:05:19 +00:00