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