Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations gkittelson on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Help! Call Forwarding Off Net and maybe an AA tutorial?

Status
Not open for further replies.

bostong3

Technical User
Sep 29, 2003
43
US
Hi All, We're an Avaya shop that recently acquired a company with a Cisco UCM deployment spanning 3 offices. I used to know something about the Cisco platform, but it seems to all be failing me now. I believe the CUCM is 'System version: 8.0.3.20000-2' if it matters.

Last week we moved one of the sites to our Avaya platform, but have had a few problems that we weren't able to work around on the CUCM:

1. We'd like to be able to forward the user's extensions on the CUCM to their new DIDs. At the moment, when dialing the user's extension (satellite office) via the Auto Attendant (@Main office), you get a message "You can not be transferred to this number. Check the number and try again." I'm assuming that is because there is no hardware associated with it, but who knows.

2. I need to edit an option on this Auto Attendant, but can't find the logic anywhere. I remember there being a separate module on another system that we had acquired once, but that doesn't seem to be the case here.

Any help would be greatly appreciated!!

Thanks!
 
8.x is a pretty recent release on the system, its a shame to waste that .... however .. Assuming you have not deleted any phones yet, all you should need to do, is in the Call Forward and Call Pickup Settings section, enter the number in the Destination of the forward all line. Make sure you add a calling search space option that will allow the call to go through. Do not check the voice mail option. Once saved, the phones should forward to the destination. If they are going out of the system over PSTN, make sure you enter all digits you need to make the call happen, ie 9 in front of it.
 
I agree that it's a shame to replace a newish system, but we obviously don't have the expertise to maintain it and need to roll these people in to established call centers. Hopefully, we'll get a good trade in on it :)

Thanks for the advice, but it still doesn't seem to be working. Maybe I'm doing it in the wrong screen? I've added the DID in the Directory Number Configuration screen next to Forward All. Changed the CSS to the HQ_LD_CSS and I'm still getting the "You can not be transferred to this number. Check the number and try again.
 
If you dial the whole number from a working phone, can you get through? If not, do you still have trunks associated with the cisco system operational?

You should be able to do it from there, but just to be sure, go to Device-Phone, select Directory number - begins with XXXXXX, then find. This will bring up the phone itself. Click on the appropriate extension on the left, then go down to Call forward section. The Destination should be exactly as you dial it if you were dialing from another phone. This should reflect exactly what you put in the other page, but it's good to check.
 
Sorry, forgot to include that you need to make sure you put in your CSS device information in the second line, below your CSS plan info.
 
bostong3

My friend, I feel your pain. 3 years ago we migrated a large Mitel system, on which everyone each had 20+ years experience, (I had 25) over to a new Cisco Call Manager. (obviously not our decision)

Most of the pain felt was that so much of the legacy voice terminology, almost universal across our industry for decades, had been unnecessarily changed to the extent that it made searching Cisco's docs to find answers virtually impossible.

The first year was a living hell, feeling like we were being held hostage by a VAR who wouldn't talk to us unless the "meter was running" to the tune of $175 an hour and management who had trusted and relied on our expertise for years suddenly had the opinion that we were all blubbering idiots.

In the final analysis, the Cisco Call Manager and Unity Connection Voice Mail and the remaining "farm" of various servers & gateway routers one day all came together into a pretty nifty phone system that permits a LOT MORE flexibility in call handling than the Mitel ever did. Sure there are a couple things we miss, mostly their default-shipping 14 line instruments and their magnificent suite of intuitive diagnostic commands and fully intuitive, human-readable SMDR logs. Those will long be missed, but we'll survive.

At age 67 I am living proof that you can teach an old dog new tricks. I understand your reasoning, but have to agree with the others that you're scuttling an awfully nice (and expensive) phone system in rder to continue living in the past.

As others have suggested, check your Calling Search Space & partitions to verify that a tandem (trunk-to-trunk) call is allowed. Sounds like it maybe isn't.



Original MUG/NAMU Charter Member
 
As for the Auto Attendant, you didn't mention on what sort of platform it was located. It could be on a Unity Connection Voice Mail system (UCXN), or be a scripted application running on Contact Center Express (UCCX). If they did not have an ACD/call center, then likely they wouldn't have wasted the $$ on a dedicated server and so most likely the AA is running on a System Call Handler in the voice mail system (Unity Cxn.) These can support up to 10 options on a single branch and be nested almost indefinitely. It would also have a Directory Handler that provided a Dial By (spoken) Name feature, ie, a prompt that asks, "Who would you like to reach?".

Figure out what you have and perhaps I or someone else can assist



Original MUG/NAMU Charter Member
 
Thank you for sharing your experience and I'm sure (or at least hoping) that your comments were not meant to be condescending. However, I can assure you that this system is certainly not being "scuttled to in order to continue living in the past". Considering the only information that I provided is that we are an Avaya shop and are replacing a CUCM I'm not sure how you can make that assumption. I came here to ask for assistance and feel instead that I'm being made to justify our standard operation procedure. That's not fair and is not in the spirit of a user forum.

Even though this has absolutely zero relevance to the question I posted yesterday... In the last 10 years we have repeatedly evaluated all top telephony vendors (hardware and cloud) and every single time Avaya has come out on top in features that we require and TOC. We are a global company with over 10,000 employees most of which are on the same current release of the Avaya Aura enterprise solution. We also maintain contact centers across the globe with the use of the on board Avaya Aura Call Center Elite (best of breed, btw). In the coming months, we will be implementing full SIP services, which if were already available, we'd be able to upgrade the Cisco 7945 sets to SIP and register them to the Avaya solution so that we could assign call center feature.

Some quarters it seems our company acquires other companies for sport. While this may or may not make us popular, it's not my job to pass judgment on the corporate business model. It is my job to ensure that we have a cohesive worldwide telephony solution that can be quickly deployed and expertly maintained and unfortunately, today it is not cost effective to have staff that can manage a mixed Avaya, Cisco, Nortel, Ericsson, Shoretel, Asterisk, Panasonic, Toshiba, etc.... deployment of our size. We do what we can, but when it makes sense the acquired sites need to be integrated into the corporate telephony solution. (ie Call Center, no local staff with telecom experience) Please be assured that every decision we make is based on a cost benefit analysis and not done just for the sake of tearing out a Cisco platform.

That said, the CUCM that we are "scuttling", services maybe 100 phones, their "call center" is more like a call answer group than a real ACD and their management has ZERO insight into call volumes or other relevant statistics. These agents are being cross trained and included in existing ACD groups on the Avaya. The local IT staff is capable of changing names on phones and resetting passwords and they don't sound all that confident in that. (This is fairly consistent across every company we've acquired with a Cisco deployment...very VAR dependent.) The local IT staff "thinks" this solution might be a CUBE, but they are not sure what that even means and until about 10 minutes ago the only thing they've been able to get us access to is the UCM webgui. I asked for access to the voicemail module and was given access to a user PCA portal before finally getting access to the Unity Connection.

Sorry to go on the defensive, but the Cisco vs Avaya argument is tired and your business should deploy what is best for your business requirements. And I do take exception to any suggestion that Avaya Aura is dated technology. Then again, perhaps my handle "bostong3" threw you off... this account was created 10 yrs ago. :)

For now, it looks like I don't have enough access or information about this system to ask for assistance so I'll be turning to the VAR to assist in maintaining the solution. Thanks anyway.
 
boston3g

First let me apologize for the remark. It was not meant to be condescending, though I can certainly see how it could be interpreted as such.

Coming from 25 years w/Mitel and already well on our way into a Mitel VOIP deployment, it made no sense to us either to rip out a perfectly working system and change horses in mid stream. That decision was made by New management that came on board after old management retired. Interestingly the new guy (Director) came from a fairly large Avaya system at a water utility company, so we were surprised as anyone by the total shift in direction.

You are correct in your observation that Cisco is heavily VAR-dependent, which is by design, unless you're willing (as we were) to bite the bullet and get retrained - both time consuming and costly and a learning curve that seemed progressively steeper (frustrating) as we went. After 3 years we're certainly far from pros, but have gained the skills necessary to become almost fully independent of the $$VAR$$ except to leverage them today for occasional staff augmentation when rolling out another deployment into a field office where we're adding another subscriber.

Regarding your Unity Connection VM system, is it safe to ask if you've tried the same login credentials on it that you use with the Call Manager?

Original MUG/NAMU Charter Member
 
Thank you for understanding my frustration... I probably overreacted a bit and if so I apologize as well.

I was finally able to get things "figured out". It's not pretty but as of yesterday morning, I have 33 extensions forwarded to their new DIDs and an option repointed to a new destination.

Thanks for pointing me towards the System Handler. It certainly wasn't easy! :)

Thanks again
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top