[asterisk-bugs] [Asterisk 0017112]: Far Max IFP/Local max datagram Calculation and the reality

[Asterisk Bug Tracker]

The following issue has been UPDATED. 
====================================================================== 
https://issues.asterisk.org/view.php?id=17112 
====================================================================== 
Reported By:                jasmin-annika
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   17112
Category:                   Channels/chan_sip/T.38
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     closed
Asterisk Version:           1.6.2.6 
JIRA:                       SWP-1188 
Regression:                 No 
Reviewboard Link:            
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Request Review:              
Resolution:                 suspended
Fixed in Version:           
====================================================================== 
Date Submitted:             2010-03-29 13:20 CDT
Last Modified:              2010-04-28 16:13 CDT
====================================================================== 
Summary:                    Far Max IFP/Local max datagram Calculation and the
reality
Description: 
Hi,

in udptl.c there is a function which calculates the max. IFP-data asterisk
expects it can send to a peer based on the received max datagram value from
it.
And there is a function, which calculates the max datagram-value ( from an
internal max ifp-size, that asterisk does not want to be exceeded), which
is sent to a peer.

Now there is the problem, that some devices (for example the AVM Fritzbox,
very popular in Germany) does not behave as asterisk expects. For example
if asterisk receives a fax document from such a Fritzbox and sends a
maxdatagram value of "200" to it, the Fritzbox sends up to 190 bytes of IFP
without redundancy. That's far more than asterisk expects!
In general, asterisk can handle this, but if it is a bridged fax call (for
example to a pstn-gw), then a major problem appears, because asterisk
itself can not forward 190 Bytes to the pstn-gw, which also has a max
datagram value of 200. This doesn't work, because the calculate_far_max_ifp
comes to a max ifp size (with redundancy) far smaller than the 190 Bytes of
IFP to send.

So there is a major problem in the concept of the max ifp calculation.

One solution would be to decode the ifp packets received from the fritzbox
and then repack the packets in multiple udptl-packets to respect the
calculated far max ifp. But that would be a very complex solution and would
not respect the thing, that the far max ifp/datagram calculation is only an
assumption, which is different from the reality.

Another solution would be to abandon the far_max_ifp concept. I think that
is the way, which respects the real situation, because the value, which is
calculated by the calculate_far_max_ifp function, is NOT the max ifp, which
the peer accepts. It is something like an "optimal" value if we look at the
added redundancy data.

If the code would be changed, that asterisk only uses this value, if it
has the possibility to dictate the max IFP to send, that would be a working
solution.

On the other side, the repacking of IFP would be a solution, which would
limit the problems with the pstn-gw, because then it has not to deal with
obscure packets from different end-user-devices. But that's another
topic...

What do you think?

Best wishes
Jasmin
====================================================================== 

---------------------------------------------------------------------- 
 (0121121) pabelanger (manager) - 2010-04-28 16:13
 https://issues.asterisk.org/view.php?id=17112#c121121 
---------------------------------------------------------------------- 
There is currently a discussion on asterisk-dev mailing list about the
future of T.38.  I would encourage you to append your comments to it. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2010-04-28 16:13 pabelanger     Note Added: 0121121                          
2010-04-28 16:13 pabelanger     Status                   feedback => closed  
2010-04-28 16:13 pabelanger     Resolution               open => suspended   
======================================================================