[asterisk-dev] [Code Review] Rework of T.38 negotiation and UDPTL API to address interoperability problems

[Kevin P. Fleming]

Steve Underwood wrote:

> How do you interpret the meaning of T38FaxMaxDatagram? Its a stupid 
> name, as nothing in T.38 is actually referred to as a datagram. They use 
> the term packet for both the IFP and UDPTL levels.
> 
> T.38 D.2.1.3.1 says its "The maximum size of the payload within an RTP 
> packet that can be accepted by the remote device."
> 
> T.38 D.2.3.5 says its "This parameter signals the largest acceptable 
> datagram for the offering endpoint and the answering endpoint (i.e., the 
> maximum size of the RTP payload). The answering endpoint may accept a 
> larger or smaller datagram than the offering endpoint. Each endpoint 
> should be considerate of the maximum datagram size of the opposite 
> endpoint."
> 
> What exactly is the RTP payload? Before adding redundancy, or after? 
> What about UDPTL? They never mention T38FaxMaxDatagram as having any 
> relevence to UDPTL, although most systems only support UDPTL and most 
> send a value for T38FaxMaxDatagram. A transmitted RTP packet can 
> obviously be larger than T38FaxMaxDatagram, as you need to add the 
> framing words to the payload. What happens in the case of UDPTL, where 
> the framing and redundancy coalesce?
> 
> In practice it seems some systems treat T38FaxMaxDatagram as the maximum 
> IFP length, and some treat it as the maximum UDPTL length. I infer this, 
> because some system use a number too small for it to be anything but the 
> maximum IFP length.

The patch currently treats T38FaxMaxDatagram as the maximum UDPTL
payload size. The application is then given a maximum IFP length
computed by using the worst-case error correction overhead (and a little
bit of UDPTL overhead) for the mode the session is currently using.

> I've always regarded the number sent to my software as kinda iffy, and 
> just tried to keep my IFPs pretty short.

I suspect that most stacks do that as well, since it's not well specified.

> This area really needs exploring more in the FoIP working group.

Agreed. Do you want to bring it up, or shall I?

-- 
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
skype: kpfleming | jabber: kpfleming at digium.com
Check us out at www.digium.com & www.asterisk.org