Unity Connections 7 and CUCM 6

Answered Question
Mar 8th, 2010

Hello All,

Having a strange issue, no idea why.  I've installed CUCM 6 and everything appears fine with that.  I went through the Cisco Guide for Unity 7 SCCP integration with CUCM 6.x and that all appears fine.  I can connect to Unity Connections fine, the Voicemail buttons on the IP Phones work fine as well.  I've imported the CUCM users into Unity Connections as well.  I have a partition setup on CUCM "RCSIPP" contained in the CSS "RCS_CSS".  The Unity VMPilot partition is also contained in that CSS.  I created a DN "1000" and set it up to forward all calls to VoiceMail.  I assigned that DN in Unity as the extension for the System Call Handler "Opening Greeting".  When I dial in from the PSTN or within the network using 1000, the Opening Greeting call handler picks up.  When I dial an extension for a user configured in Unity, I hear the "Please wait while we transfer you to that extension" but then the call goes directly to voicemail.  For troubleshooting purposes I even disabled all voicemail forwarding on the user.

When I place the user's DN into the <none> partition in CUCM, then the Unity Connections Call Handler forwards perfectly to the user's extensionas it ought to.  I have gone through seemingly every setting that seems to have an effect and yet nothing works.  The only temporary workaround I have found is to place all CUCM DN's into the <none> partition.  I know I have had this working before, I thought I had setup everything correct this time as well but am apperently missing something?  Any help with this issue is GREATLY appreciated.  Most likely it is something stupid I am overlooking but this is very very vexing.  Thanks in advance for any assistance.

I have this problem too.
0 votes
Correct Answer by William Bell about 6 years 8 months ago

I know you provided partition and CSS assignments in your post but it isn't clear to me what partitions your phone DNs are in and what CSS is assigned to your voicemail ports.  Your voicemail ports will need to have a CSS assigned which includes the directory numbers for the lines assigned to your IP phones.

You can also use Dialed Number Analysis (DNA) to confirm that you can reach the IP phones partition from the CSS assigned to voicemail ports.  You could also configure one phone to use the same CSS as the voicemail ports (double check that line CSS configs match as well).  Then see if you can call other extensions.

You can also check restriction tables.  I believe the default config should be adequate, but that depends on what your extension range is.  For instance, a leading "9" on your extension range may require you to tweak the restriction tables.

Finally, check what the "transfer extension" is on your test voicemail users just to be sure.  I suspect you have already done this and you have a CSS/partition issue.

HTH.

Regards,
Bill

Please remember to rate helpful posts.

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 4.8 (4 ratings)
Loading.
Correct Answer
William Bell Mon, 03/08/2010 - 23:35

I know you provided partition and CSS assignments in your post but it isn't clear to me what partitions your phone DNs are in and what CSS is assigned to your voicemail ports.  Your voicemail ports will need to have a CSS assigned which includes the directory numbers for the lines assigned to your IP phones.

You can also use Dialed Number Analysis (DNA) to confirm that you can reach the IP phones partition from the CSS assigned to voicemail ports.  You could also configure one phone to use the same CSS as the voicemail ports (double check that line CSS configs match as well).  Then see if you can call other extensions.

You can also check restriction tables.  I believe the default config should be adequate, but that depends on what your extension range is.  For instance, a leading "9" on your extension range may require you to tweak the restriction tables.

Finally, check what the "transfer extension" is on your test voicemail users just to be sure.  I suspect you have already done this and you have a CSS/partition issue.

HTH.

Regards,
Bill

Please remember to rate helpful posts.

fieryhail Mon, 03/08/2010 - 23:59

Sorry about the missing information in the OP.  Just for the record, I have desktop IP Phones in the RCSIPP partition and IP Communicator devices in the RCSIPC partition.  The voicemail ports are in the VMRestrictedPT CSS as the Unity Connections guide suggested.  By adding the RCSIPP and RCS IPC partitions to the VMRestricted CSS, Unity transfers calls to the DN's as expected.  My DNs are all in the 1000 or 2000 range, nothing in 9000 except the VM Pilot, 9999.  This brings me to yet another question though, If I create a new CSS for another company per se, and new route partitions there, some of the same DN's will exist, for instance, there will be a 1001, 1002, 1003, etc for both companies.  Now I plan to use an Asterisk system for VM for the other company, no budget for Unity licensing in that case.  I am assuming that there will be no issues?  Calls between companies will not be necessary.  Thanks again.  And thanks very very much for the assistance.

William Bell Tue, 03/09/2010 - 07:50

With Unity Connection 7 you have the ability to partition your VM system in a manner similar to what you would need.  You have partitions and CSS configurations in Unity Connection that you could use to group the users on your system.

Now, given your scenario.  You have a 4-digit dial plan and two separate voicemail systems.  To accomodate this you would need to use a separate CUCM-CSS/CUCM-Partition solution.

Personally, I always use a flat addressing solution.  In North America this would be a 10-digit dial plan.  Meaning all phone numbers, voicemail boxes, etc. are configured as 10-digit patterns using the NANP.  Then use translations to "fake" users into believing they have an abbreviated dial plan.  It is a more scalable solution to the problem.  But that is a little off topic.  In your case, use a separate CSS and partition solution on the CUCM side to ensure there is no overlap.

HTH.

Regards,
Bill

Please remember to rate helpful posts.

fieryhail Tue, 03/09/2010 - 13:35

Thnks again for the response Bill,

It's an option I had never considered.  Using a 10-digit dial plan and translation patterns to fake an abbreviated dial plan.  I'm going to be installing a demo version of CUCM 7 and would be interested in trying this out with that install, do you think you may be able to give me guidance, links perhaps to implementing a strategy such as that?  I have so far not used translation patterns before.  Also, I've been having a very strange issue with my h.323 gateway since I upgraded the IOS On the router.  I had posted another post on NetPro regarding that.  IP Communicator is not able to dial out to PSTN now for some reason, though it appears to work fine internal to internal.  Yet, IP phones such as 79xx dial out to PSTN just fine.  Thanks again.

William Bell Tue, 03/09/2010 - 20:21

Take a look at this section and surrounding sections from the SRND:

http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/srnd/6x/dialplan.html#wp1045576

This should give you some good ideas.

The same basic ideas existing CUCM 7x dial plan.  Actually, I have used the flat-addressing/translation model for every design I have done since 2001.  While it wasn't a staple of the SRND back then, using a flat-addressing model whether you have a variable length dial plan or not is the only way to roll in my opinion.  Translation patterns are your friend ;-)  Especially handy in CUCM 7x since you can toggle the "urgent priority" flag.  Anyway, take a look and see if you get some ideas from the SRND.

HTH.


Regards,
Bill

Please remember to rate helpful posts.

WSonnylal Wed, 03/10/2010 - 05:07

Assuming a flat dial plan as mentioned and multiple individuals from different organizations.  How do you prevent directory lookups, dial by last name etc from crossing the boundaries of the different organizations?  Sure you can apply translation patterns and route filters to prevent routing of the calls but you still have the problem of users being able to find irrelevant records in cuc using the TUI or ciscopca.

William Bell Wed, 03/10/2010 - 06:35

You are correct, you would have to address directory enabled features.

For the CUCM corporate directory, the answer is simple:  you have to build your own corporate directory XML application.  The answer is simple because there is no trickery you can apply on the CUCM native directory application to segment the directory.  It also isn't all that hard to build but that depends on your comfort level with things like that.

For the CUC, I believe you have options but I haven't explored this from a "hosted solution perspective".  You can use the CSS and partition config objects of CUC to separate the users.  You can assign a partition to the users mailbox extension (e.g.2025551000/customerA-pt).  This completely segregates the system and I don't see a problem with that because the scalability considerations with CUC are different than with CUCM.

You could also assign a different partition to the abbreviated/alternate extension.  So, for example:

Main extension: 2025551000/allcustomer_pt

Alternate: 1000/customerA_pt

Using this approach, you would need to look at the Search Scopes assigned to applications like "Attempt Sign-In" and "Attempt Forward" so that they can see the allcustomer_pt.  You would also make sure that the CSS assigned to various VM users uses a CSS that only includes the customer partitions they are allowed to see.  You have to also look at any system default call handlers, system applications, etc. to make sure that non-user facing apps can see allcustomer_pt while user facing apps (typically ones you would build yourself) can only see the customer PTs you want them to.  Now, I'll admit I have not done this in a production environment with CUC since (a) my customers usually aren't selling "hosted solutions" (though I do have one that does and I am glad you made me exercise my noodle on this question) and (b) the partitioning feature in CUC is relatively new to me (a few months) and I haven't played with it to much.  That being said, I sacrificed my lab config to try out some of what I was saying and it appears to work conceptually.

HTH.

Regards,
Bill

Please remember to rate helpful posts.

WSonnylal Wed, 03/10/2010 - 06:39

Thanks so much for going through this.  This is very helpful for a project that I'm looking at right now.

fieryhail Wed, 03/10/2010 - 07:29

Thanks very much for your input on this.  As you can tell we're looking at running a hosted system on a small level and there doesn't appear to be much in the way of documentation available on this.  Excellent input!

Actions

This Discussion