[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:                     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-23 22:36 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.


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

---------------------------------------------------------------------- 
 (0096926) arcivanov (reporter) - 2008-12-23 22:36
 http://bugs.digium.com/view.php?id=14119#c96926 
---------------------------------------------------------------------- 
My previous note notwithstanding, let's consider the following scenario:

X <=> Asterisk <=> Y

1) Let's assume that X and Y can support datagrams of 512 bytes.
2) Y detected fax tone, sends re-invite that includes:
a=T38FaxMaxDatagram:512.
3) Asterisk processes the re-invite and sends it to X with the following
attributes: a=T38FaxMaxBuffer:512, a=T38FaxMaxDatagram:512
4) X sends a 200 OK to Asterisk with, a=T38FaxMaxBuffer:512,
a=T38FaxMaxDatagram:512; then ACKs.
5) Asterisk sends 200 to Y with a=T38FaxMaxBuffer:512,
a=T38FaxMaxDatagram:512.
6) Y ACKs.

Asterisk is unable to support 512 byte datagrams, yet both X-Asterisk and
Y-Asterisk channels have negotiated the 512 byte datagrams. This is due to
the fact that in chan_sip.c (lines 7326 - 7331) the joint capability will
NOT take datagram sizes under consideration. The udptl.c (lines 1268 -
1274) will silently max out the datagram sizes at LOCAL_FAX_MAX_DATAGRAM,
that is defined as 400 (line 89).

I unfortunately lack the physical hardware to reproduce this scenario. 
However, the fix (ensuring that joint capability always caps the
datagram/buffer sizes at maximum supported by Asterisk proxy) should be
completely benign with respect to existing clients. 

I'll submit a patch fixing this scenario for consideration.

Note: all code references are for branch 1.6.1,rev. 166730. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2008-12-23 22:36 arcivanov      Note Added: 0096926                          
======================================================================