[Freeswitch-dev] mod_fax

[Steve Underwood]

Stéphane Alnet wrote:
> 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).
>   
T.38 specifically says the called end is the one which should initiate 
T.38 negotiation. The presence of absence of CED and CNG has nothing to 
do with it. If the calling end tries to initiate T.38 its a protocol 
error, though a common one. As with most SIP implementation, the 
industry standard is "as broken as our bunch of monkeys could make it".
>   
>> 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.
>   
QoS is a largely unrelated issue, in that SIP servers don't cooperate 
with QoS managers. The SIP server needs to do its best to get the calls 
through, and hasn't the slightest clue what the channel's capacity might 
be. Whilst switching to a higher bit rate might overwhelm the channel, 
the SIP server has no way of telling in advance. To stick with a low bit 
rate codec is completely useless. Renegotiating to a usable codec is the 
less worst thing we can do.

Regards,
Steve