[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-22 08:51 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.


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

---------------------------------------------------------------------- 
 (0096782) file (administrator) - 2008-12-22 08:51
 http://bugs.digium.com/view.php?id=14119#c96782 
---------------------------------------------------------------------- 
Packets are not forwarded unaltered and the ast_udptl_bridge code is not
used. It is entirely possible and acceptable for the two ends to negotiate
independently. Data is received on one udptl port and then encapsulated in
an Asterisk frame. It is then written out the other udptl port with a
packet created following the new parameters that have been negotiated (such
as error correction type). Are you seeing an issue somewhere? 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2008-12-22 08:51 file           Note Added: 0096782                          
======================================================================