In all the documentation I have on Unity, I haven't seen anything that indicates the standard for directing incoming calls on a gateway. Would I configure the gateway to direct incoming calls to an attendant DN (or Web Attendant Hunt group)? Or would I configure the gateway to direct incoming calls directly to a Unity VM port?<br><br>I've been working with two designs on our demo system. One where the incoming call is directed to a single extension (an attendant). This would be in a scenario where a live person answers calls during the day. After hours (or when the attendant takes breaks) the phone is manually forwarded to a Unity VM port and Unity plays the appropriate greeting based on the schedule. I've also used Web Attendant Hunt Groups - where as long as someone in the hunt group is logged in the call is routed to an attendant. If everyone in the hunt group were to log out (or be at capacity, or unavailable, etc.) the last member of the Hunt group is Unity.<br><br>I guess what I'm asking is - is this considered standard? Or would I configure the gateway to direct incoming calls directly to Unity, and, based on the Unity schedule, allow it to direct calls back to the Cisco Call Manager, or to a Unity greeting/Call Handler?<br><br>Now for the last scenario I'm considering... If I have a client that always wants the automated attendant (Opening Greeting) would I (again) configure the gateway to point directly to a Unity VM port?<br><br><br><br>Brian Carscadden<br>Sr. System Engineer<br>CCNA, CCDA, CIPT, MCP<br>TransNet Corporation<br>908 253-0500
If you want to use auto attendant (i.e. Unity is answering incoming calls) I would think youd want your calls to go right to the uOne line hunt group head and have it snag the first available in the hunt group and have it spill over to an operator console or something along those lines.
We have not tested the Web Attendant stuff with 3.0(8) however when we looked at it in 3.0(7) it caused some problems with transfers I would avoid that with Unity for now. The application sounds interesting but well need some time to iron out the kinks. Id play it safe and go direct.
Yeah, the integrations group has the web attendant on it's list of stuff to get tested with the help of the CM test group. We'll get it ironed out in short order I'm sure... it's a pretty cool looking feature.
In general having Unity answer all incoming calls during the day is fine if you want folks to "0 out" to the operator. If you want us to simply turn around and bounce the call right to an operator without "talking" to the incoming caller I don't think that's your best bet (I think this is what you had in mind). Folks using auto attendant usually have Unity answer all incoming calls and let folks decide if they want to try an extension, navigate some audio text options (i.e. directions to the building, get to tech support etc...) or time out/0 out to an operator.
If you're looking to have a haman interface on all incoming calls during the day, I would definitely have the switch stack up the calls for the operator(s) rather than having Unity field them and bounce them back based on schedule. the caller experience there could be odd if you're not real careful (i.e. they'd hear dead air for a period of time).
One thing to look out for when you forward the operator extension(s) to Unity after hours... make sure the ID of the operator number(s) do not correspond to any mail user or call handler IDs in Unity. All calls will be presented as forwarded from extension X in this scenario. We will lookup X and if a match is found, route the caller to that greeting instead of the opening greeting. You can work around this with fancy routing rules up front but in general it's better to avoid it entirely.
SIP traces provide key information in troubleshooting SIP Trunks, SIP
endpoints and other SIP related issues. Even though these traces are in
clear text, these texts can be gibberish unless you understand fully
what they mean. This document attempts to br...
Please find the attached HTML document, download and open it on your PC.
This provides an easy to use form where you simply answer a few
questions and it will render the proper jabber-config.xml file for you
to copy/paste. There is built in logic to verif...
CUCM Database Replication is an area in which Cisco customers and
partners have asked for more in-depth training in being able to properly
assess a replication problem and potentially resolve an issue without
involving TAC. This document discusses the bas...