[Freeswitch-dev] mod_fax

[Stéphane Alnet]

Hello,

Some notes based on my past experience with fax-relay. Sorry for the
long-ish post.

> As an aside,
> the called party should be the one to initiate an attempt to use T.38,
> but in the real world the calling party often does.

Depending on whether CNG shows up first or CED shows up first, the
switch to fax-relay might happen one way or another. Fax server
entities also tend to bypass some steps and start in fax mode (some
even forget to negotiate a voice codec).

> If T.38 is not available (which it isn't ever right now), and the call
> starts with a low bit rate codec, we should initiate a reinvite to use
> Alaw or ulaw. If that fails we might as well abandon the call.

BTW the full specs are available for free:
http://www.itu.int/rec/T-REC-T.38/en
http://www.itu.int/rec/T-REC-T.30/en

T.38 Annex D has an example for a fax-only call, but generally
speaking, in the PSTN there's no such thing as "a fax call" (or a
"modem call"). A call always starts as a voice call, and might switch
to fax mode (and back).

The basic issue Steve mentioned is that if you negotiate (at the start
of the VoIP call) a codec that is supposed to use, say, 28kb/s
(G.729), then to respect QoS over the entire call you should only
accept fax calls that will fit within that amount of bandwidth
(accounting for IP/UDPTL overhead, that might be up to 14,400b/s for
example -- don't quote me on the numbers).

In the early days, one would renegotiate the codec to G.711
("upspeed") when a fax tone was detected (assuming all fax calls use
64kb/s); if QoS denied the bandwidth upspeed (either because of
per-call bandwidth restriction configured on the gateway, Call
Admission Control, RSVP, ..), then the call would be dropped. However,
I don't think the upspeed to G.711 is strictly required, and in a
fax-relay scenario, the hop-on and hop-off gateways could also decide
to only offer the appropriate fax rates to the fax machines
(overriding the speeds offered by the actual fax machines in the T.30
stream; see spec T.30 page 53). So if the call started as a G.729
call, the gateway(s) could "clear the bits" in T.30 for anything above
the matching bandwidth.

Where it gets tricky is that some T.38 options (for example UDPTL
redundancy) might mean that the actual bandwidth available to T.30 is
much lower than the bandwidth available to the voice codec; if you
start with G.729 and then switch to T.38 with one-time redundancy, the
"assumed bandwidth" falls to 28kb/s/2=14kb/s, so you might only be
able to drive 9,600b/s fax out of that.
Another issue is that some fax models use proprietary mechanism to
switch to higher speeds. So a fax machine from brand A might do
14,400b/s with a fax machine from brand A, regardless of what the T.30
negotiated speed was. (I never looked into the gory details, so take
this as hearsay.) However in that last case there's little you can do
anyhow -- you will most probably end up oversubscribing the bandwidth
assumed for the call in any case.


Finally, in some environments, it might be OK to go over the bandwidth
assumed for a voice call in order to get a fax call through (call
completion is more important, and the network is over-engineered to
account for this). Also, fax is only half-duplex, so in large
installations, things tend to level out statistically speaking (most
traffic in fax-relay is from the sender to the receiver; however the
caller might not be the sender). Finally, fax bandwidth usage can go
over voice codec bandwidth usage in regular scenarios -- there's
nothing restricting fax-relay UDPTL traffic to 64kb/s.

HTH,
Stéphane