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

[Asterisk Bug Tracker]

The following issue requires your FEEDBACK. 
====================================================================== 
http://bugs.digium.com/view.php?id=14119 
====================================================================== 
Reported By:                arcivanov
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   14119
Category:                   Channels/chan_sip/T.38
Reproducibility:            always
Severity:                   feature
Priority:                   normal
Status:                     feedback
Asterisk Version:           1.4.22 
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Disclaimer on File?:        N/A 
Request Review:              
====================================================================== 
Date Submitted:             2008-12-21 19:16 CST
Last Modified:              2008-12-22 08:52 CST
====================================================================== 
Summary:                    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.


====================================================================== 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2008-12-22 08:52 file           Status                   new => feedback     
======================================================================