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