Chaining between Call Handlers (noobie..)

[MitelInMyBlood]

LOST...

24 yrs exp on Octel, 24 days w/Unity Connection & no training. Need some pointers

Assuming it's possible, how difficult is it to daisy-chain multiple call handlers together to build a menu tree application with branching, i.e., where option choice 1 takes the caller to a whole new set of prompts & options? Ideally I would like to be able to do this in UC rather than in Contact Center. Octel was simple, UC so far seems a little counter-intuitive or else I'm intimidated by the programming interface or missing something obvious.

Like Octel, would you have to build it from the bottom-up?

Also, what about licensing, do call handlers consume any of my license resources?

Any "Dummies Guide" or good documentation out there you can point this tired old man to?

Thanks!!!!!

Original MUG/NAMU Charter Member

 

[whykap]

First off, no licensing is consumed by call handlers.
You don't have to build the AA from the bottom-up but it would be a lot easier.
Have you read the unity connection admin guide? It tells you how to build a CH. If not I can send you the link.

I agree with you. i would keep the AA on unity and not ucx unless your AA is very deep and repetitive. Then ucx would be a lot easier to manage and handle all the greetings.

 

[pndscm]

I think you pretty much have to build it from the bottom up. You can't have level 1 Caller Input One pointed to a CH on level 2 if you haven't built it yet.

 

[MitelInMyBlood]

Thanks - both

Bottom-up construction made sense to me for exactly the reason stated, which was the same way it was on the Octel. You can't point an option to an undefined destination if that destination itself is another branch in the tree.

And yes, a link to the Unity Cxn admin guide might help. I may have it at the office, but I'm home this week and hoping to do a little boning-up so I don't sound like a complete idiot in the meeting w/the client next Monday.

Thanks again

Original MUG/NAMU Charter Member

 

[whykap]

Since you just installed it, I assume you are running the latest version

http://www.cisco.com/en/US/docs/voice_ip_comm/connection/8x/administration/guide/8xcucsag060.html

 

[MitelInMyBlood]

Yes, rls 8. Thanks for the link. Man It's hell being 64 and having to relearn all this crap again from scratch. We've managed to get most of the basics working on CUCM & Unity Cxn, now have to start digging a little deeper. This user interface just seems so dang unintuitive... as tho to intentionaally force you into using a VAR

Original MUG/NAMU Charter Member

 

[whykap]

Allow me to disagree. Once you understand the product you will agree with me as well. Don't tell me that you were an expert on the mitel two months after you first touched it.

You need to be patient and pay your dues, meaning spending time with the product and pulling your hair out for a while. One thing that you got on your side is the free resources that cisco has for you, from the open online documentation to cisco TAC to all the forums like this one.

I work for a VAR and trust me most of us do not want to be on a customer site configuring phones and users and vm boxes. We want the customer to take all that over if possible.

If your employer is expecting you so fully support this product, I suggest some training would be highly beneficial, especially now that you have gotten some exposure.

Good luck and we are always here to help the best we can.

 

[MitelInMyBlood]

Thanks.

You're right, learning the Mitel didn't exactly come overnight, but actually in reverse order which was more beneficial - I had the Mitel dropped in my lap for 18 months before the first instructer-led class, by which time I was thirsty and more importantly, knew the questions I needed to ask. Also the Mitel was established, up & running when I first inherited it, so there was no crisis. I was also 40 at the time.

By contrast, the Cisco was handed to us literally on its knees, still in boxes. A VAR commissioned it & got it passing call traffic during which time 2 of us were sent to 1 total week of ACUCW1 - that's it. We didn't have time for any addt'l training as the rollout was happening. It took us several weeks to build up a head of steam to be able to get to 100 a week, then finally 150 a week in 2 bites, but still there are some fairly good sized VM menu trees we've had to dodge along the way, leaving several end users on Mitel phones while we figure out how to rebuild Octel menu tree apps on Unity.

Aside from the call tree apps we still have a couple hundered phones to roll out for our execs, mktg dept and some other "high maintenance" users, 6 of which today are still on Etrali Mach-2 Turrets, but only for the Turret's 1500+ speed call capability, not ARDs, broker boxes or shoutdown lines, thank goodness. The turrets will get replaced with 7975s + a 7916 sidecar along with click-2-call and some Excel files, crude perhaps, but functionally equivalent. Cisco doesn't make a phone with 1500+ speed call buttons. The turret users will probably get migrated to Cisco phones as a last order of business, once everything else is stable. CUP-C doesn't seem as well-suited for this app as did plain vanilla click-2-call, so C2C is probably the direction this high-volume speed call thing is headed.

911 is also (for now) staying on the Mitel because it's tied-in with an Amcomm/Xtend Enterprise Alert 911 package that does some gee-whiz stuff that Cisco's 911 package didn't (yet) offer. Part of the Mitel is new (3300 IP) so that's where we'll put 911 for now, along with DISA (Direct Inward System Access) until we can wean customers away from it. The 3300 will be around for a while as we have a large number of field offices that themselves are all brand new Mitel IP, so the 3300 in the corporate office will serve as a gateway to that network for the foreseeable future.



Original MUG/NAMU Charter Member

 

[whykap]

It sounds to me you have enough experience that you will pick up the new system very quick. the fact that you were already on IPTEL before will also help. If you were still on strictly TDM, say all SX2000 would make the learning curve much longer.

It can be very frustrating having mgmt expectations to be so high and not understanding that every phone system is different with its own tricks and intricacied and there is a learning curve for everything. You should have put the execs on the cisco phones first, with no training, and see how fast they figure those phones out.
It would be fun but also career adjusting for you.

 

[MitelInMyBlood]

You're preaching to the choir.

Our mgmt told us we'd be forklifting the Mitel SX2K as far back as last January. In reality the Cisco gear didn't show up on site until the end of June and we weren't even able to begin deploying sets (Unified of course) until 2nd week of July with a goal of having approx 1400 sets deployed & fully operational by 12/31. Fine if you know what you're doing, not so fine for two old geezers (50 yrs combined experience) on Mitel 2K & 4 yrs on Mitel IP. We were headed toward Mitel IP, trained & certified 3 yrs ago and all up to date on current certifications, even had some initial sets deployed when new mgmt came on board mumbling something about Cisco. The rest is history. By the way, CUP-C is unstable on Exchange 2010, delaying that rollout, making endusers mad because they lost their Jim-Dandy 14-button sets expecting to be able to replace all their speed calls with CUP-C click 2 dial and Presence. Guess what isn't working....

Original MUG/NAMU Charter Member

 

[meneerB]

hi MIMB,

i'm an Avaya guy witch some experience on a 3300 and now cucm6 for 2 years.
didn't you think i curse(d) a lot...

mitel vs cisco
I think the mitel 5340 rocks (lots of buttons + submenus) according to the stupid 7961 with only 6 buttons...
but: very bad UI on the mitel: it looks like all menus where developed by other people.

OPSmgr (version late 2008): perfect with all templates, but very unstable: every vew weeks databases out of sync in the 3300 cluster.

that said: the cucm webgui (and cisco cluster) is very stable! but no templates! BAT technically works, but is wayyyy to much work for simple day-2-day MACs.

If i may choose: Avaya...
(I don't have experience with IVR on mitel/cisco, so i cant say much about it.
but what you have with octel, i have with avaya, just perfect
now waiting to implement it on cisco also...

goodluck with your implementation!
ps. just a question: do you get enough help from your VAR??

 

[MitelInMyBlood]

Calling the VAR means spending money & casts us in a bad light of being ignorant & no longer being able to be depended to do anything the client wanted and make the PBX sing, dance & prance like we once could. I think most of all we miss the great (command line) trunk/call routing & call trace diagnostics. Our preference for VM servers going forward was also Avaya and we almost succeeded there, but....

The 5340 Mitel instrument with 48-line capacity ROCKED! Agreed OpsMgr sucked and always did from it's original implementation. Extremely unstable, poorly written, 100% Java based and a horrible GUI. We were/are managing 48 separate (networked) systems with Enterprise Manager/Ops today. I'm glad to see OpsMan finally going away. Enterprise Mgr is similarly hobbled, in my opinion, but is better than nothing for managing multiple machines across the enterprise.

I'm 3300-Certified through 4.2 and SX2K-Certified beginning at E-Stream (1988), also SX200 certified including IP. I don't enjoy being handed a learning curve at age 65.


Original MUG/NAMU Charter Member