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

[Asterisk Bug Tracker]

The following issue requires your FEEDBACK. 
====================================================================== 
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:                     feedback
Asterisk Version:           1.6.2.6 
JIRA:                        
Regression:                 No 
Reviewboard Link:            
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Request Review:              
====================================================================== 
Date Submitted:             2010-03-29 13:20 CDT
Last Modified:              2010-03-31 09:24 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
====================================================================== 

---------------------------------------------------------------------- 
 (0120015) lmadsen (administrator) - 2010-03-31 09:24
 https://issues.asterisk.org/view.php?id=17112#c120015 
---------------------------------------------------------------------- 
Jasmin, thanks for the analysis!

Because this appears to be at more of a discussion stage, I'd like to
request you take this to the asterisk-dev mailing list (you can reference
the issue here if you like).

You may end up getting some comments here as well, but because this is a
discussion at this point, I'd like this to be exposed to as many people as
possible, which means asterisk-dev is the most appropriate location for
this.

Thanks! 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2010-03-31 09:24 lmadsen        Note Added: 0120015                          
2010-03-31 09:24 lmadsen        Status                   new => feedback     
======================================================================