Late T.38 re-Invites: A Report from the Field
Our largest BladeWare customer, a service provider with thousands of ports deployed, reported that they had been seeing a high failure rate on outbound faxes, sometimes up to 20%. They had looked at the captures and noticed that BladeWare was sending a SIP 406, Not Acceptable Here code, for the failing calls. “What was going on?” they asked.
It turns out that one of their carriers was experiencing some unusually high traffic loads, causing their generation of T.38 re-Invites to be slow, sometimes over 20 seconds. Well, as we’ve stated in the past, it only takes about 7.5 seconds for the two endpoint terminals to get far enough into a fax call so that interrupting them to switch to T.38 will kill a fax (the point of no return).
You can see this very clearly in the capture above, which is from testing we did in 2Q09, but is typical of the problem reported yesterday. The calling fax terminal can “hear” the called terminal at 433, when it starts collecting the DIS, as shown the RTP capture, below.
In this particular call, which was captured prior to our patent-pending late-T.38-re-Invite discovery, the RTP stream was shut down at about 444.4, killing the fax by accepting the re-Invite when it should have given the network the ol’ 406.
But why did the calls fail after the 406 in the recent case? Well, it turns out that some gateways mute the RTP stream as soon as they decide to issue a re-Invite. Ironically, the strategy is to try to reduce the chances that this very problem will occur by not allowing the signal to get through to the terminals, what some call “T.30 leakage.” But, in this case, the called gateway was so late, it actually killed the call.
For more information on Commetrex’ Smart FoIP, please contact us at 770-449-7775 (push 1 for Sales) or at sales@commetrex.com.
