Allow non-compliant T.38 endpoints to be supportable via configuration option.
authorKevin P. Fleming <kpfleming@digium.com>
Mon, 5 Oct 2009 19:45:00 +0000 (19:45 +0000)
committerKevin P. Fleming <kpfleming@digium.com>
Mon, 5 Oct 2009 19:45:00 +0000 (19:45 +0000)
commit20743ec07dbd45e4a963680cf5d72d8d02b43193
treeac6d0ac098854f416ac53091b8252a028e51c564
parent10e8ee1746180f589f2c86027c989cc9c63366c8
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
UPGRADE.txt
channels/chan_sip.c
configs/sip.conf.sample
configs/udptl.conf.sample
main/udptl.c