VoIP Fax from IPO to S8300 1

[CarGoSki]

Here is a good one for all of you. The Scope is to provision for an IPO to receive fax calls from PSTN in the US. The fax call then should be converted to VoIP and ride the existing network to London where it is received by an s8300. The s8300 then routes the calls to a hunt group of 8 analog extensions connected to a brooktrout card. The Umero container then receives the calls, performs OCR and converts to pdf for email distribution.

Routing is performed by detecting DTMF from the IPO.

Impossible you say?

Well, I just came back from provisioning it however I am having mixed results. The fax calls route to London properly every time however I am getting some scrambled DTMF in some cases. Naturally routing can not be performed properly when DTMF is detected incorrectly. I currently have a 70% success rate.

It is interesting that the s8700 in London is only to be used for VoIP faxing and has virtually no programming in it. This is a worldwide rollout where many locations in the world will send their faxes to this central location.

Currently, an s8700 in Holland is sending faxes to London at a roughly 99% success rate. Singapore to London was a bust for now and my project(US to London) feels like a bust.

In the IPO, I created an incoming route from the PRI to a system short code for every fax DID.
A typical route looks like this:
Line:0
Incoming Num:7177
Destination: 7177
Bearer: Any

A typical short code would look like this:
Code Number:7177
Tel Number:7177D,7177
Line Num: 100

I have tried tel Nums like:
7177D7177,7177
7177D,,7177
7177,D7177

On the s8300 side a typical IP trunk and H.323 signaling group were set up using the B protocol. The call is sent to a hunt group directly from the trunk group.

The IPO is 2.1.27 with a vcm 20.

Any comments??

 

[nohuhu]

CarGoSki,

first, it is recommended to upgrade ipo to 3.0. second, did you try set up dtmf out-of-band sending? and third, it doesn't help to have additional digital-to-analog conversions along the voice path. you should consider using pure-ip faxing or switch to isdn cards in london. not necessary e1, isdn-bri would suffice. that way, you could do without dtmf at all. if you don't send dtmf it couldn't be garbled, right?

 

[CarGoSki]

We had discussed upgrading IPO binaries and VMPro to 3.0 but opted out for the moment. Do you know if 3.0 or 2.1.31 specifically addresses DTMF over a vcm channel?

The IP trunk for IPO and the Signaling group for s8300 are both set for out of band. As a matter of fact when out of band is not used, no DTMF is detected at all.

The IP trunk for IPO has Fast start, Fax Transport, Out of band and direct media path enabled. Site testing with these variables has shown that if any of those variables change either dtmf is not present at all or the call does not connect.

We used a lab config where we connected our house IPO and s8700.

We do wonder about latency however. At first latency averaged 500ms and above. Sometimes as bad as 1000 to 2000 ms if replication was being performed over the network. This improved to about an average of 170ms after a bandwidth upgrade. We used an extended ping test from origination to destination using 2k packets over the course of 200 continous pings.

We will likely gather a group of people to packet sniff the network, perform extended ping tests and Monitor the traffic while sending test faxes.

We can read the Brooktrout Trace logs and clearly see where digits are interpreted incorrectly. We did trace call flow for the T.30 specification using the Trace logs.

 

[nohuhu]

CarGoSki,

i can't be exact at the moment but 3.0 has many improvements and bug fixes and afair some of them are related to voip.

as for latency, 500 ms is awful. according to standard, delays up to 150 ms are acceptable for voice grade quality and i can say from experience that fax calls are even more sensitive to jitter than voice. the matter is not how long it takes a packet to go site-to-site, but how variable the delay is. so you should seriously consider contracting some provider that can guarantee qos along the path or you'll never reach the quality you want. ping with 2k packets will not prove anything because typical voice packet using g.729 codec and 20ms payload with all overhead will be about 200 bytes. so again the matter is not how fast the large packets will traverse the network, it's how fast, stable and non-varying the path is for small packets. and test of 200 packets again will not prove anything, you should monitor the quality for at least a full day, better for a week. voip quality monitor that comes with avaya site administration would help in this case.

as i said previously, you should consider not using analog brooktrout cards. passing fax traffic overseas using such a non-stable network is a challenge by its own right and it doesn't help much having another rocks that you may stumble upon. try to simplify your scheme, it will give you better results.

anyway, as i see now the biggest part of the problem lies not in the fax-over-ip and not in analog fax lines on the other side, it's in overall quality of service support of your network. if you don't improve it, you'll never achieve successful solution.

 

[CarGoSki]

Yes it is all good advice no doubt and there is no qos for packet traffic in this case.

Thanks for your contribution.

 

[Morrack]

Just out of curiousity, why not capture the fax at the IPO in the US and email it to london for OCR, etc.?


Peter Sherwood

Morrack Consulting

http://www.morrack.com

 

[CarGoSki]

The IPO would have to capture the fax and output tiff. Then smtp the tiff to email. That would work but I don't recall seeing where the IPO can do that.

Originally, the IPO did send fax calls to a local brooktrout T1 board where it was received by Faxination, converted and emailed. Since the plan is to centralize operations from London, the local brooktrout board and server will be removed.

Faxination is out and Umero is in.

 

[Morrack]

Why not keep the current faxserver in place then? I'm not familiar with faxination (I'm a GFI fan) but surely it can email tiff files - who cares if it's a Umero server or not in the US, all it's doing is receiving and emailing. London will do with the tiff file whatever stuff you need done that prompted you to switch to Umero.


Peter Sherwood

Morrack Consulting

http://www.morrack.com