We have a customer that has a policy that mobile phones do not have their own voicemail. The CallForward Busy and CallForward No Answer on the mobile phone is directed to the subscribers direct-in-dial in the office.
However, when the call is routed to Unity, we are prompted with standard Unity messages, not the subscribers Personal Greeting.
This has to do with the DNIS and RDNIS I assume. How do we change this in Unity? Globally/per subscriber?
Any help would be great.
Crack open CallViewer (Start > Programs > Unity) and have a subscriber's cell phone forward a call to Unity. What number pops up there, the office number or the cell phone? It's probably the cell phone number. Adding whatever appears as the call's forwarding station (the cell phone number) to that subscriber's Alternate Extensions page in SAWeb.
There's no way to get Unity to look at the second forwarding station's extension, but since you know the call will be coming from their cell phones, you can add the cell phone number as an alternate extension and get things working.
Okay, I have the cell's number listed as an alternate extension. If the user calls the vmail from the cell, Unity responds with "Please enter your password". If you call the cell and it forwards to Unity, the SMDI link shows the call, but Unity plays the Opening greeting instead of the subscriber greeting. What am I missing?
"the SMDI link shows the call"
What exactly is it showing here? To get to the subscriber's greeting the SMDI will need to show the call as a forwarded call with the subscriber's extension (or alternate extension) as the Called number.
It might calls are showing up as direct when the cell phones forward to Unity's main pilot number. Some sites have worked around this by instead setting cells phones to forward to the subscriber's DID, which then in turn forwards the call to Unity. With this, Unity receives the call as forwarded from the subscriber's primary extension and has no problem playing the subscriber's greeting. The drawback here of course is callers have to sit through two CFNA timers before finally hitting voicemail.
The SMDI Integration shows that my extension called the Nextel and the NEXTEL as the called number. The forwarded Extension field is blank. My old voicemail routed based on the called number not the forwarded number. Routing the Nextel to the office number is a poor fix, but it's better than nothing. Thanks.
Was hoping there would be some hack for the system to also look at the called number.
How does the SMDI packet for these forwarded mobile calls compare to calls forwarded from an internal phone? The way Unity's serial engine parses SMDI data I don't see how it could be different if the calling and called numbers are showing up in both cases. The SMDI protocol doesn't have distict Called and Forwarding fields.
The forwarding extension field is blank in the intergration table view. Called number and calling number are populated. The SMDI string reports the call as a forwarded no answer from the cell number. This is why I'm confused as when the caller dials voicemail directly the system responds with the correct greeting.
Ok, I see what's going on. If the Called number prefix in the SMDI packet has a match then we'll put the extension in the Forwarding field on Unity. If the prefix does not match then we use the Called field. Don't ask me why, it just is.
Then, as you've pointed out, the Attempt Forward routing rule for forwarded calls will look for matches only in the Forwarding field, not the Called. Again, I have no idea why it was done that way but that's how it is.
Here're some examples. I'm calling from x4321. I have the extension length set to 4 and my switch file has SMDIPrefix1=555.
The Called number is 0001234. So the prefix is 000, which always is considered a match. Thus Unity puts 1234 in the Forwarding field and Attempt Forward works.
The Called number is 5551234. So the prefix is 555 which matches the entry in my switch file. Again, Unity puts 1234 in the Forwarding field and Attempt Forward works. Note that the prefix gets stripped.
This time the prefix is 777, which does not match. So Unity leaves the whole thing, 7771234, as the Called number. Nothing is placed in the Forwarding field and Attempt Forward fails
Now, I'm not sure how you've got things set up but I'd wager there's a way to make this work for you. One way would be to not use prefixes at all but rather just set the extension length to match the full SMDI field length. Depending on your system this may require you to have alternate extensions for both subscriber's mobile number and their full 7 or 10 digit primary number.
Hopefully, I've given you enough to work with. If not, with additional details on your config I might be able to help a bit more.
I tried adding the AC and NPA to the SMDI list, and now calls from my cell get my greeting. Hooray!
But life is not rosy in Unity land, and here's why...
I have a dual integration. CM 3.3(2) and Centrex with two NPAs. If I add the AC and NPA for all the various users' cell phones and then just put the EXT in the alternate list, I'm going to end up with duplicate 4-digits in the mailboxes. e.g. I have a user whose number is 510-287-2180, and a cell phone user 925-123-2180. How do I work around this?
BTW I have folks using this Unity from AC 415, 925, 707, 209, 510, 916, Basically all of Northern Ca...
Yeah, I was afraid of that. In general, things get a bit sketchy whenever you start needing more than one SMDI prefix. If someone has the 2000-3999 range in the 510-287-xxxx area and also has the 4000-4999 range in 925-123-xxxx area they might list two SMDI prefixes, 510287 and 925123. But what happens now when an outsider calls from 925-123-3000? We'll strip off the 925-123 and just pass on the 3000 as the extension. That's no good.
A way around this would be by using Extension Remapping. Set the default extension length equal to your SMDI field length (10) and dont bother with SMDI prefixes at all. So Unitys serial parser will just pass everything through as a 10 digit number. Forwarded calls will use the forwarding number field whenever a called number is available.
Now, to get things down to 4 digit extensions, check out sample.txt in \CommServer\IntLib\ExtensionMappint\ So, for example, to solve the dilemma I mention above,
This will strip down numbers like 510-287-3000 to just 3000 but leave 925-123-3000 untouched. For your case, just enter enough mappings to get down to everyones unique 4 digit primary extension. Then use 10 digit alternate extensions for the mobile phones.
Here youll find a further details on the Extension Remapping feature http://www.cisco.com/en/US/products/sw/voicesw/ps2237/products_administration_guide_chapter09186a00801ba476.html#1604861