summaryrefslogtreecommitdiff
path: root/channels/chan_console.c
diff options
context:
space:
mode:
authorKevin P. Fleming <kpfleming@digium.com>2009-10-05 19:45:00 +0000
committerKevin P. Fleming <kpfleming@digium.com>2009-10-05 19:45:00 +0000
commit20743ec07dbd45e4a963680cf5d72d8d02b43193 (patch)
treeac6d0ac098854f416ac53091b8252a028e51c564 /channels/chan_console.c
parent10e8ee1746180f589f2c86027c989cc9c63366c8 (diff)
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
Diffstat (limited to 'channels/chan_console.c')
0 files changed, 0 insertions, 0 deletions