[asterisk-bugs] [Asterisk 0014119]: [patch] Multi-host T.38 negotiation

[Asterisk Bug Tracker]

The following issue has been RESOLVED. 
====================================================================== 
http://bugs.digium.com/view.php?id=14119 
====================================================================== 
Reported By:                arcivanov
Assigned To:                file
====================================================================== 
Project:                    Asterisk
Issue ID:                   14119
Category:                   Channels/chan_sip/T.38
Reproducibility:            always
Severity:                   feature
Priority:                   normal
Status:                     resolved
Asterisk Version:           1.4.22 
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:             2008-12-21 19:16 CST
Last Modified:              2009-03-10 14:27 CDT
====================================================================== 
Summary:                    [patch] Multi-host T.38 negotiation
Description: 
Below please find the refined SIP negotiation log for the following setup:

Gafachi (64.192.112.13, sip.gafachi.com) <=> NAT <=> Asterisk Proxy
(192.168.157.42, pbx1) <=> Grandstream HT2886 (192.168.157.11, fax1)

NOTE: The Asterisk is 1.4.22 patched with "relaxed-T.38" and "boolean
handling" patches from issue http://bugs.digium.com/view.php?id=13976.

Potential Problem http://bugs.digium.com/view.php?id=1
    Note the a=T38FaxMaxBuffer:512, a=T38FaxMaxDatagram:512 in Asterisk's
response to HT286. According to udptl.c we're not even capable of reading
UDPTL packets that exceed LOCAL_FAX_MAX_DATAGRAM, which is defined as 400.
Assuming that Gafachi and HT286 would have agreed on 512 (not in this case
though) could Asterisk even pass-through those packets? Are we passing the
packets between the peers without reading them at all? Or does the bridge
try to analyze the UDPTL packets to any extent before forwarding them? I
can't get my head around the entire udptl.c to answer that question.

Potential Problem http://bugs.digium.com/view.php?id=2
     Depending on the answer to the question in
http://bugs.digium.com/view.php?id=1 the same might apply to
error correction negotiation mechanisms and rate management negotiations.


======================================================================
Relationships       ID      Summary
----------------------------------------------------------------------
related to          0013976 Invalid SDP attributes for boolean T.38...
related to          0013050 Memory segmentation fault on T.38 pass ...
====================================================================== 

---------------------------------------------------------------------- 
 (0101488) file (administrator) - 2009-03-10 14:27
 http://bugs.digium.com/view.php?id=14119#c101488 
---------------------------------------------------------------------- 
As a result of another issue the maximum size was raised, which means this
has already been taken care of another way. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-03-10 14:27 file           Note Added: 0101488                          
2009-03-10 14:27 file           Status                   confirmed => resolved
2009-03-10 14:27 file           Resolution               open => no change
required
2009-03-10 14:27 file           Assigned To               => file            
======================================================================