Summary:	ASTERISK-15889: Far Max IFP/Local max datagram Calculation and the reality
Reporter:	jasmin-annika (jasmin-annika)	Labels:
Date Opened:	2010-03-29 13:20:03	Date Closed:	2011-06-07 14:00:32
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Channels/chan_sip/T.38
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:
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
Comments:	By: Leif Madsen (lmadsen) 2010-03-31 09:24:21 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! By: Paul Belanger (pabelanger) 2010-04-28 16:13:29 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.