15 Feb What Is Experience Worth?
It’s a challenge. It’s one we’ve taken on directly with our customers and as participants in the SIP Forum’s FoIP Interop Task Group.
Commetrex has made a corporate decision to do what we can to aid our customers and the industry to make this transition. We jump at the opportunity to work with our service-provider BladeWare customers in solving network-peering problems. For example, we are currently working with a fax-broadcast customer and his service providers to bring transaction-completion rates of a T.38-based broadcast even with that of TDM networks. We are working directly with a VoIP service provider to qualify a NAT-firewall solution. And another service provider is having trouble getting inbound faxes to succeed when the call was forwarded by his IP-carrier partners. And, our participating in the SIP Forum’s FoIP Task Group is intended to promulgate and broaden the benefit.
The fax-broadcast is proving to be quite a challenge because the evidence suggests that the problems, such as random timeouts, are being caused by the long-haul IP partners, and getting their cooperation is not easy.
The VoIP service provider is using an on-premises B2BUA in conjunction with a network-based TURN server to solve the NAT and firewall problems often encountered when aSOHOcustomer has independently obtained the DSL service and is currently using it for data only.
You might find the call-forwarding problem particularly interesting. Here, we have seven networks involved (yes…seven): An inbound fax call originates on the 1) PSTN, where it is handed to 2) Level(3), which passes it to 3) Bandwidth.com (no fax determination, as yet). Bandwidth.com determines that the call is to be forwarded and passes it to 4) XO Communications, Bandwidth.com’s “handoff” carrier for outbound 1+ calls. XO then passes it to 6) Global Crossing via (now get this) the 5) PSTN. Global Crossing sends it to 7) Intelemedia, our BladeWare customer, via the Global Crossing MPLS network. Whew! It should come as no surprise that this call-setup odyssey isn’t trouble-free. Inbound faxes that are dialed direct work; those calls that are forwarded never work. Specifically, BladeWare and the remote gateway give it a game try, but eventually the remote caller hangs up.
The problem begins with BladeWare receiving a “No Signal” T.38 packet after receiving a V.21 preamble. Now, this may not mean anything to you, but the reason for it may. All you need to do is take a look at the figure below. Note the gap in the data about 25-percent into the plot. That 40-msecond gap is what caused the no-signal. And it doesn’t have to be T.38. BladeWare supports G.711 pass-through fax, so Intelemedia tried the same call with G.711 and had 100-percent failures when the call was forwarded. Well, “duh”, you may say, G.711 doesn’t work over the Internet. Hold on. Intelemedia is getting 100-percent—so far—success rate with G.711 pass-through with Global Crossing’s MPLS when the call is not forwarded.
Here is the picture of the call in the frequency domain (higher frequencies plot as higher amplitude):
Our guess is there is a jitter buffer somewhere that is filling up or the call is transferred between boxes, somehow leaving the gap. And the signal is not just interrupted. For some 60-ms after the break, the signal has glitches, likely due to a single packet being repeated by the packet-loss-concealment logic of a tandem network entity. Here’s the gap up close showing the glitches following the gap at approximate 10-msecond intervals.
Although this is not really a BladeWare problem, it does indicate a common network-failure mode that BladeWare could handle with a slight modification, which we installed for our customer. It solved the problem.
That’s the value of experience.
No Comments