diff options
| author | kpfleming <kpfleming@f38db490-d61c-443f-a65b-d21fe96a405b> | 2009-08-07 13:10:11 +0000 |
|---|---|---|
| committer | kpfleming <kpfleming@f38db490-d61c-443f-a65b-d21fe96a405b> | 2009-08-07 13:10:11 +0000 |
| commit | 4f91e656178c75315c96effd49201045b87d2c5c (patch) | |
| tree | 6a8f8fcb2bc3253dc161027339c0ef748a028557 /apps | |
| parent | 5133780835f2d30e333122a9314ab221fc1af72f (diff) | |
Merged revisions 210992 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
........
r210992 | kpfleming | 2009-08-07 08:08:00 -0500 (Fri, 07 Aug 2009) | 13 lines
Workaround broken T.38 endpoints that offer tiny MaxDatagram sizes.
Some T.38 endpoints treat T38FaxMaxDatagram as the maximum IFP size that should
be sent to them, rather than the maximum packet payload size. If such an
endpoint also requests UDPRedundancy as the error correction mode, we'll end
up calculating a tiny maximum IFP size, so small as to be unusable. This patch
sets a lower bound on what we'll consider the remote's maximum IFP size to be,
assuming that endpoints that do this really can accept larger packets than
they've offered to accept.
(closes issue #15649)
Reported by: dazza76
........
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@210995 f38db490-d61c-443f-a65b-d21fe96a405b
Diffstat (limited to 'apps')
0 files changed, 0 insertions, 0 deletions