[cisco-voip] direct to VM route RP & Unity Digital network

Lelio Fulgenzi lelio at uoguelph.ca
Sat Oct 29 20:51:54 EDT 2005


I see now. Well, just as you have to forward the phone to the correct Unity server, you have to direct the *XXX calls to the correct Unity server. If your extension range is unique, which I assume it is because everyone is using the same partitions and calling search spaces, then you can simply route specific patterns or ranges to the correct voicemail server. So, *[0-4]XXX to one server and *[5-9]XXX to the other server. Now, if you have non-contiguous ranges at each location, well, this gets a little more difficult as you will begin to have one offs. You won't need any extra partitions or calling search spaces, just let everyone dial the route points.
  ----- Original Message ----- 
  From: Ruttman, Peter G. 
  To: cisco-voip at puck.nether.net 
  Sent: Saturday, October 29, 2005 6:16 PM
  Subject: RE: [cisco-voip] direct to VM route RP & Unity Digital network


  If you call the extensions everything works because I have the voice mail profiles pointing to the proper pilot points for the proper unity servers.  The issue is with our requirement for the direct to VM route point.  A user can type * and the 7-digit phone number to and go directly to voice mail which bypasses the ringing of the person's phone.  The RP has a voice mail profile associated with it and since we currently only are using a single scheme for partitions and CSSs I have no way of addressing both unity servers so I just point it to one of them.  I was hoping that I could convince the unity server that would get the calls to forward on any calls for subscribers that are not in its local database to forward them on to the other server via digital networking but it isn't working.  I know that portions of digital networking are working because you can go to the automated attendant and dial the extension of a subscriber on the other unity server and it will transfer ove!
   r to the other unity server.  I can also server the global directory on either server as well. Perhaps there is no way to do what I want without building separating partitions and CSSs for each building so I can have two separate RPs for the voicemail transfers but it is a lot of extra configuration for one feature.  Any thoughts?

  ________________________________

  From: Lelio Fulgenzi [mailto:lelio at uoguelph.ca]
  Sent: Sat 10/29/2005 12:50 PM
  To: Ruttman, Peter G.; cisco-voip at puck.nether.net
  Subject: Re: [cisco-voip] direct to VM route RP & Unity Digital network


  Can you explain your problem a little more? Do you mean when you call the extension and then it is forwarded to voicemail that you get the opening greeting? If you haven't already, you should be forwarding each phone to the individual Unity server on which the voicemailbox exists. So you will have to two voicemail pilots in this case.
   
  It is possible to have the same voicemail pilot pointing to two different Unity servers, but then you would need different partitions and calling search spaces. Also, if one client were ever to visit the other site, you would need a seperate pilot to access their voicemail box on the other Unity.
   
  We have three Unity servers operating with one cluster and everything is working fine, so it is possible.
   
  Let us know.
   
  Lelio

  ----- Original Message ----- 
  From: Ruttman, Peter G. <mailto:PRuttman at foley.com>  
  To: cisco-voip at puck.nether.net 
  Sent: Saturday, October 29, 2005 10:40 AM
  Subject: [cisco-voip] direct to VM route RP & Unity Digital network

  Hi Folks,

  We are putting in a new remote office that has two building that are connected by T1s.  We have exchange at both locations so we felt we better but Unity in both locations as well.  For Callmanager we have a centralized model that runs out of our datacenters so we were going to treat these two building as if they were the same for things like partitions, CSS, device pools, etc.  We have run into one snag now with unity.  We have enabled digital networking and from the primary unity server in the larger office you can dial the number of subscribers on the other unity server as well as look them up in the directory.  The problem is that we have a route point in the form of *[office 3 digit code]XXXX.  So for this office it would be *102xxxx.  Since we only have one set of partitions and CSSs we can only point this route point to one of the two unity servers so I pointed it to the primary one out there (the larger building).  When you type the pattern in a phone it goes to the!
    primary unity server.  If the subscriber is actually on the primary unity then you get the subscriber's unity greeting.  If the subscriber is on the other unity server you get the main greeting.  Of course, you can type the number again and it will go to the other server but that isn't what we are looking for.  Does anyone have any suggestions other then setting up additional partitions and CSSs to fix this problem for us?

  Pete

  The preceding email message may be confidential or protected by the attorney-client privilege. It is not intended for transmission to, or receipt by, any unauthorized persons. If you have received this message in error, please (i) do not read it, (ii) reply to the sender that you received the message in error, and (iii) erase or destroy the message. Legal advice contained in the preceding message is solely for the benefit of the Foley & Lardner LLP client(s) represented by the Firm in the particular matter that is the subject of this message, and may not be relied upon by any other party. 


  Internal Revenue Service regulations require that certain types of written advice include a disclaimer. To the extent the preceding message contains advice relating to a Federal tax issue, unless expressly stated otherwise the advice is not intended or written to be used, and it cannot be used by the recipient or any other taxpayer, for the purpose of avoiding Federal tax penalties, and was not written to support the promotion or marketing of any transaction or matter discussed herein.



  ________________________________




  _______________________________________________
  cisco-voip mailing list
  cisco-voip at puck.nether.net
  https://puck.nether.net/mailman/listinfo/cisco-voip



  The preceding email message may be confidential or protected by the attorney-client privilege. It is not intended for transmission to, or receipt by, any unauthorized persons.  If you have received this message in error, please (i) do not read it, (ii) reply to the sender that you received the message in error, and (iii) erase or destroy the message.  Legal advice contained in the preceding message is solely for the benefit of the Foley & Lardner LLP client(s) represented by the Firm in the particular matter that is the subject of this message, and may not be relied upon by any other party.      

    
  Internal Revenue Service regulations require that certain types of written advice include a disclaimer. To the extent the preceding message contains advice relating to a Federal tax issue, unless expressly stated otherwise the advice is not intended or written to be used, and it cannot be used by the recipient or any other taxpayer, for the purpose of avoiding Federal tax penalties, and was not written to support the promotion or marketing of any transaction or matter discussed herein.


  _______________________________________________
  cisco-voip mailing list
  cisco-voip at puck.nether.net
  https://puck.nether.net/mailman/listinfo/cisco-voip
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://puck.nether.net/pipermail/cisco-voip/attachments/20051029/6f4fe851/attachment-0001.html


More information about the cisco-voip mailing list