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

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
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:                     new
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-21 20:34 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.


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

---------------------------------------------------------------------- 
 (0096771) arcivanov (reporter) - 2008-12-21 20:34
 http://bugs.digium.com/view.php?id=14119#c96771 
---------------------------------------------------------------------- 
I might be wrong, but I can't find ast_udptl_bridge to be used anywhere in
Asterisk. ast_udptl_read and ast_udptl_write, on the other hand, appear to
be used in chan_sip. Can someone with experience weigh-in whether my
concerns above are valid? 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2008-12-21 20:34 arcivanov      Note Added: 0096771                          
======================================================================