MODEMs over IP trunks

[tangodelta]

We have a cluster! A cluster of seven 3300 MXe III ICPs with ASU IIs attached. We have lot's of modems we call at remote locations.

Everything was working good in the "interim" configuration where the analog lines to one 3300s ASUs were routed on a T1 trunk to the existing PBX and existing OPX line to the remote modem.

Then we migrated some of the remote modem lines to ASU II lines attached to a remote 3300. Others were migrated to T1 trunks connected to remote 3300s.

This means the connection is from ASU through an IP trunk to a remote 3300 and either an ASU or another T1 trunk to the remote modem. At this point all modem lines became very unreliable.

Sometimes they work well, sometimes not. Usually they work well for about 30 seconds and then no data flows. Basically they are unusable.

A work around I found was to establish a T1 E&M "tie trunk" between nodes using our internal communication system. The modem lines work well doing that.

The IT people say QOS has been implemented properly.

We are all new at this. Are we missing something? Is it possible to make modems work over IP trunks?

Please, no three page dissertations about why are we should not be using modem dial up lines. And none about how VOIP sucks for data lines. We all ready know that, told managers that. They wanted to have a VOIP system.

 

[Supernova99]

Unfortunately MoIP is not supported so it will always be a bit unreliable. (there is no international standard as modems are considered 'legacy' equipment)
There are a few things to try to make it a bit better:
No voice compression
For incoming calls to modems: Program the modem on the same controller as the incoming trunk
The same for outgoing modem calls: Make sure the modem is on the same controller as the outgoing trunk
Modem to modem internally across IP trunking try and adjust the baud speed rate lower.


Share what you know - Learn what you don't

 

[kwbMitel]

I have found some success in those instances when the modem cannot be connected to the same controller in using SIP media converters.

Using this method the signal doesn't get converted as many times.


**********************************************
What's most important is that you realise ... There is no spoon.

 

[bribob]

Have you done any research into T.38? I haven't played with it yet but there's a 50% change it might help. I say 50% because it's designed for fax, which is mostly one-way.

Do the MCDs have compression configured for any of the IP trunks? [read: what audio codec is being used on the IP portion of the call path.]
Do the networking guys have compression configured on any of their links?

Could you tell us more about the "T1 E&M "tie trunk" between nodes using our internal communication system" that you setup? Did you emulate a T1/PRI using a media converter of some sort? If so, did it transit over your IP network?

I also agree with Supernova, dial down those modems to the slowest possible speed and work your way up.

 

[Waldosworld]

Have your tried reducing the baud rate?
Considering 14.4K is the best rate for Fax over IP using T38.

 

[tangodelta]

Thanks for all the replies. We are looking in to the compression issue. The main ICP (MCD, 3300, can I call it a PBX?) was designed and set up so faxes work. Not so sure about the other cluster 3300s or the IP connections to them. It has been a long road from planning to roll out.

Supernova99 (TechnicalUser) 10 Jan 14 3:36
Unfortunately MoIP is not supported so it will always be a bit unreliable. (there is no international standard as modems are considered 'legacy' equipment)
There are a few things to try to make it a bit better:
No voice compression
For incoming calls to modems: Program the modem on the same controller as the incoming trunk
The same for outgoing modem calls: Make sure the modem is on the same controller as the outgoing trunk
Modem to modem internally across IP trunking try and adjust the baud speed rate lower.

MoIP, LOL. Never heard that term related to modems over IP. Be careful if you google the term. All modem lines are on an ASUII connected to the same controller as the incoming/outgoing trunk. Most of the calls are initiated at a ripping 9600 baud.

Legacy. That's me, started out as a microwave radio/analog mux technician in 1973. Phones and PBXs came later since they are "communications" and the comm guy should be able to take care of them. My knowledge now is mostly in T1 based transmission systems including that mysterious and wonderful optical stuff.

bribob (TechnicalUser) 10 Jan 14 12:33
Have you done any research into T.38? I haven't played with it yet but there's a 50% change it might help. I say 50% because it's designed for fax, which is mostly one-way...

No, but I will look in to it. Probably better than 50% as most of these calls consist of the originator logging in to a device and asking for data. Most of the data comes from the device. Mere humans are usually not involved.

kwbMitel and Waldosworld thank you for your inputs.

TD

 

[tangodelta]

bribob (TechnicalUser) 10 Jan 14 12:33
...Could you tell us more about the "T1 E&M "tie trunk" between nodes using our internal communication system" that you setup? Did you emulate a T1/PRI using a media converter of some sort? If so, did it transit over your IP network?

I am not sure about length limitations in posts here, so I am making the answer a separate post. Plus I don't want to clutter up the original issue with explanations of our internal communications system.

This is not your typical 3-400 user office system. That is part of it and it was relatively easy to roll out with the usual growing pains and issues. The other, larger part is several hundred voice and data (dial up modem) lines to remote locations. Most of these remote locations have no network (as in inter/intranet) but do have T1 and a channel bank. The telephone access works through FXS modules in the channel banks. This has been a problem during transition as apparently the Mitel will not do traditional FXS/FXO signalling on a T1 E&M trunk. At least as far as we and our vendors know. Different issue. The previous and still existing PBX had no problems with these old industry standards.

Our internal communications system is a T1 based system using several different types of transmission media. Not including the vast and mysterious ethernet based thing.

All of the PBXs (3300s, no one seems to like me calling them a PBX) are equipped with Dual T1/E1 Framer modules that are connected to a DACS (our generic term for a digital cross connect system). These framer modules are provisioned for what Mitel calls "T1/D4 Digital E&M trunks". PRI only comes in to play where we interface with a LEC for outside calls. These tie trunks are at the DS0 level so PRI won't work, we need CAS. The DACS allows us to pluck one 64kB DS0 from a T1 and route it to any other DS0 on any other T1 in the system. So we send the "trunk" to the FXS module and connect a POT to the loop side and viola, a POT line. The only media converter involved is in the 3300.

Using the work around a modem call to a remote PBX will use that old reliable tried and true ancient D4 T1 framed ESF like what ma bell and many others have been using for eons. Works fine almost all the time. All the information arrives at the destination in the correct order by the same path. Proven four nines reliability. That means it works 99.9999% of the time. That equates to .5 minute outage per year. What's the reliability for VoIP or for that matter your own internet connection?

I believe that is why my work around of creating a T1 E&M tie trunk between the nodes works. VoIP is still and probably never will be ready for prime time data transmission using the ancient EIA (RS) 232 method.

TD

 

[bribob]

TD, sounds like you've made the best out of a sticky situation. I had assumed that you only had an IP network to work with between sites.

My guess is that management wanted VoIP for the cost savings aspect and better call quality for the human users, not taking into consideration the feelings of the "ancient" machines. Is management looking to scrap your existing (proven four/9) system?

This probably won't help for the sites that DO NOT have an IP network (WAN/LAN), but have you looked into eliminating the analog portion of your scenario and gone straight from RS232 to IP? I've used the Precidia iPocket (

http://www.precidia.com/products/ipocket_232/

) for RS232 PMS integration and haven't had any issues. iPocket-to-iPocket / iPocket-to-Telnet...

 

[tangodelta]

An update just FYI. One of the remote 3300s had two T1s for network. About 3Mb, thats the way routers with T1 interfaces spell it out, 1.5Mb per port. Anyway, we got our IT peeps to dedicate one of the T1s to voip traffic, putting admin LAN, video etc on the other T1. At that point the modem connections started working pretty good. Slower but if the call was initiated at 9600 data would flow. I have played with it manually and can get links up to 28.8 to work. FWIW to you all.

bribob, they might like to get rid of the T1 based microwave/lightwave system but they cannot because our bread and butter data flows across it to and from our own facilities and other entities all over the US.

The main reason they wanted VoIP was because HQ had it and they wanted to be like their masters. The "better call quality for humans" has yet to be the result. Actually complaints are up several hundred percent and what used to be about 5% of my job is now about 25% of five peoples jobs. Maybe it's just growing pains. Maybe it's just the glorified magic jack. One thing I have noticed about the attitude toward phone call quality. It used to be we wanted every call to work every time with good voice quality. Now it seems to be hang up and try again because we have no idea and IT is busy.

TD

 

[RotaryDialTommy]

I have been involved in Telecom/PBX since 1972 , I'm glad I retired last year . Tango I hope you are near retirement , it's only going to get worse .

 

[tangodelta]

Tommy, since you ask I have about 700 work days but who's counting?

I have been involved in the multiplexing side of telecom since about that time. Successfully transitioned to the T1 world shortly after. Can set up a telephone from said mux and occasionally connected one to a 1A key system to save a telephone type a long trip. (or was it screw the telephone guy out of a nice TDY?)

The PBX part came about 16 years ago with a job change and involved one type of CBX. Once I understood the difference in terminology from the mux world it was a piece of cake. The in house part was a pain only because of liberal cubical hopping policies by management. The off premis part was easy because the PBX could be programmed to make a "trunk" use FXO signalling. Send that DS0 "trunk" to a FXS card in a mux somewhere and presto-a telephone that rings, gets dial tone and the CBX displays the extension just as if the phone were connected to a local copper pair.

Now it's modify the mux card to use what I call trunk signalling, (0000,1111) create a trunk service number so there is a type of caller id displayed and a speed dial so users don't have to enter the direct trunk select code. Oh yeah and for the TSN to work speed dial has to send the trunk number again after the trunk is selected. There are other ways to make it work but this is the fewest steps.

Since I really need to keep working for those 700 odd days, I am trying to look at it as a challenge. 700 days plus whatever OT I am encouraged to work, mostly to try to figure out the issues with the new telephone system and play catch up since telephony is now a full time job.

The worse is here now as after 15 years of providing what I believe was pretty darn good service to on and off site telephone customers, I am now part of a team (nothing wrong with the team part, except it reflects the workload for the new system) providing so-so maybe it will work phone service.