Need to connect a Cisco UC320 to Adtran 550

[etkbrettc]

We have a Cisco UC320 phone system and need to connect it to the adtran on FXO ports. The adtran has a T1/PRI module and FXO module. Is there a way to do this?

[Anonymous]

Are you sure you need FXO ports in the ATLAS? The FXO ports can either be configured in the NETWORK TERM in order to receive loop current and dial tone, or in the USER TERM to act as a DID line (but the end device still needs to provide loop current).

If I'm reading the specification for the Cisco UC320W correctly, it has "Support for up to 12 public switched telephone network (PSTN) lines (FXO);" so in the ATLAS, the FXS module provides PSTN lines which would then connect to the FXO ports on the Cisco. The FXS module provides dial tone and battery, where the FXO receives dial tone and battery from the circuit connecting to it. So if the Cisco needs a "plain old telephone service" (POTS) line, then you need the FXS module in the ATLAS.

So the FXS module will be configured under the DIAL PLAN in the USER TERM. If calls need to go out to the PSTN, then you'll need a connection to the PSTN. You mentioned the T1/PRI module; does that mean you have a PRI to the Telco? Whatever connection you have to the telephone company will be configured under the DIAL PLAN in the NETWORK TERM.

If I'm missing something or you have additional questions, let me know.

Thank you,
Patrick

[etkbrettc]

You just cleared a lot of for me. I do have a FXS module installed as well and yes the T1/PRI is connected to the telco. POTS is what the Cisco UC320 needs. I was able to do inbound and outbound calls with that setup but had some issues. The reason I started wondering if I needed a FXO module was because of 2 reasons.

1: When you are dialing out, you dial 9 and then the number. But, you just can't dial the number, you have to dial 1 then the number. (9,1-XXX-XXX-XXXX). I am not sure if this is on telco side or on the adtran line.

2. When a call comes in 2 things happened.

     A. User answered the phone and would hear "numbers being dialed" then the call would begin

     B. The call comes in as fxo1

Any insight on how to correct these issues would be greatly appreciated!

Thanks,

[Anonymous]

For #1, the ATLAS is not configured for 10-digit dialing. It defaults to 7-digit local dialing. You can change this under the DIAL PLAN, GLOBAL PARAM, in the NUMBER COMPLETE TEMPLATE. The first pattern is the 7-digit pattern of "NXX-XXXX". You can change this to "NXX-NXX-XXXX" to allow 10-digit local dialing. (I do not believe the Cisco is passing the "9" to the ATLAS.)

For #2-A, the FXS ports are probably configured with DIRECT INWARD DIALING set to ENABLED. When DID is enabled it outpulses however many digits are configured in the DID DIGITS TRANSFERRED. If the Cisco does not need the DTMF digits to know how to route the call, then set this to DISABLED. (This is found in the DIAL PLAN, USER TERM, in the IFCE CONFIG.)

#2-B I'm not sure what you mean. Is "fxo1" showing up on the phone's caller ID? If this is the case, then by default the "ANI to CALLER ID" on the FXS ports is disabled. You can set that to ENABLED for the ATLAS to send caller ID information between the first and second ring.

Hope this helps,

Patrick

[etkbrettc]

I made all those changes and it seems to be working except for one.... I don't see the "ANI to CALLER ID" in DIAL PLAN/USER TERM/Interface Configuration window. The last choice is "Dial on Offhook". Do I need to update the firmware of the adtran? It is running ATLAS 550 Rev. A.04 04/28/00 13:48:01

Thank you for all the help,

Brett

[Anonymous]

Wow! Hahahaha... Yes, upgrade the firmware!

It looks like you should be able to upgrade straight to C.09.04 from A.04. The only restrictions are if you had A.02, or A.03 you have to upgrade to A.05 first and then upgrade again after that.

You should also check the firmware you are running on the FXS module, as C.04 for the module was released in 2002.

The ANI TO CALLER ID setting was added via FW so upgrading should add that option to the menu.

Thanks,

Patrick

[etkbrettc]

Lol.... yeah, this thing has seen better days. And on top of that, i will need to install a new dallas chip because it doesn't save it's config. Looks like I will be soldering this weekend! I will do the update once I get the chip installed.

I have one final question. Once I get this all configured, the client has 6 phone lines provided by the telco. From the cisco UC320 I can control which lines ring which phones and other features as well. This is done by setting a number on the specific FXO port on the UC320. Can I set a specific number on the FXS port on the adtran that correlates to the port on the UC320?

Again, thank you for all the information. This has been extremely helpful!

Brett

[Anonymous]

Yes. The FXS ports will need to be listed seperately - each port having its own USER TERM entry. Then each port can have its specific IN#ACCEPT, so only that particular number will be routed to the specified FXS port.

Hope that makes sense,

Patrick

[etkbrettc]

Hi Patrick,

I would like to thank you for all your help. We ended up replacing the Adtran with a newer model 500. I just got it installed and used all your advice and got it working great. So thank you for that

I do have one more question. We are having a delay during phone conversations. When they are on the phone, they say it takes a second for them to hear a response from the person. When I was on the phone with them, I noticed that I would hear them in real time but when I would respond, I would hear an echo of myself then they would respond, like they heard my echo and not me actually responding. Do you think this is provider side or something on the Adtran? THis was happening on the first Adtran we installed as well. Thank you for all your help.

Brett

[Anonymous]

Hey Brett,

Glad to hear you have it working!

As far as the echo goes, there is a built-in echo cancellation but no way to increase that in the ATLAS. There is nothing in the ATLAS to add or remove audio delay. You can test by dialing directly from one FXS port to another (by dialing the IN#ACCEPT) and verify there is no noticeable delay in the audio. You can then dial so the call goes to the PSTN and back (sometimes dialing 10-digits will do this, or if the IN#ACCEPT is only 4-digits you can dial 7 or 10 digits, etc.) and see if there is any delay at this point.

I'm afraid that for any audio delay you'll have to contact the carrier/provider.

-Patrick

[etkbrettc]

The echo was on the provider side and that is gone. Now I am trying to figure out the roll over. I have added the number to the User Term on the other ports but now it is just ringing one user now. How i have it set up is the main number is on port one of the FXS module and each port after has a number assigned (4 ports in total). 2nd port has the second number listed first and then the main number listed second. I believe this is the last hurdle I have before we have this system up and running properly.

I just wanted to thank you for all your help on this. It has been a long project and I appreciate all the help you have given on this. I usual work in the Networking field but was asked to do this and learning as I am going. Thanks Patrick.

Brett

[Anonymous]

It sounds like you have the FXS ports configured for roll-over. If all the FXS ports have the main number in the IN#ACCEPT list, then the ATLAS will route the call to the first available port. So if you want the call to go to the second port, the first port will either need to have a call on it, or at least be offhook. Once the call is routed to a port it will not roll-over after that - so it will not roll-over after a certain number of rings, etc. The call will either be answered or not.

[etkbrettc]

Weird that it is just ringing the second number directly.... without the first number being in use. I will play with it.

[Anonymous]

I'm not sure what you mean by "ringing the second number directly" then. Is it ringing the 2nd FXS port while the 1st port is available?

If that is the case, then make sure the SEARCH (under the IN#ACCEPT) is set to PRIMARY for both, or PRIMARY on port 1 and SECONDARY on port 2 and the following ports.

[etkbrettc]

Ok, I will play with that.

And lastly, the call's aren't disconnecting in the system after they hang up. Is there somewhere to diagnose what is causing this or is it the UC system that is probably causing this?

[Anonymous · Accepted solution]

The calls are disconnecting in what system, after who hangs up?

Does your system connected to the FXS ports hang up, and the call stays active, or does the far end hang up and the equipment off the FXS port keep the call active?

If the equipment connected to the FXS ports hangs up and the ATLAS doesn't detect it, then there is nothing we can do. The ATLAS looks at the impedance on the port to determine if the end equipment is off-hook or on-hook (essentially an "open" is off-hook and a "short" is on-hook).

If the far end hangs up and the equipment connected to the FXS ports doesn't detect it, you can try adjusting the "Forward Disconnect" under the DIAL PLAN, USER TERM, in the IFCE CONFIG. This sets how long the ATLAS will remove loop current when the far end disconnects the call. (The default is "Disabled" which means loop current is never removed.)

[etkbrettc]

We got it!

I changed the Forward Disconnect on all the lines to 600ms and it cleared all the calls and now the calls are getting stuck on the UC system. I also figured out where I need the roll-over line to be configured. I needed it on port 4 since that line was the second line for the receptionist. Once I did that, I was able to call, put her on hold, and call the main number and it rolled over to her secondary line. They are going to play with it for a bit but it seems to be working properly now.

Patrick, thank you for all your help and guidance. I wouldn't have been able to do this without your help and hopefully this thread will help others if they ever have this type of setup.

Thanks again,

Brett