Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

New Member

Unity Bridge question re: auto-created subscribers

Have Bridge successfully up and running, Bridge is synchronizing users from the Octel system via Namenet, and then into Unity beautifully.

Only one problem here, the Bridge Subscriber extension is set to the Dial ID + the user's extension. Unfortunately, the customer would like to be able to dial the Octel users by extension only. Extensions are unique between the two systems so this should not be a problem.

It seems as if the CsBridgeConnector process on the Unity box is the one that actually decides to prefix the extension with the Dial ID here. I'm sure this behavior is by design to avoid extension conflicts, etc. But is there a way to tweak this behavior? This would be ideal. If this is not possible, are there any good pointers or tweaks to batch populate the SQL database with a bunch of Alternate Extensions?

Thanks in advance for the help.

Also, on a completely different note, it appears that I've got all the subscriber data from Unity sync'd with the Bridge, but it seems the Octel is not trying to "pull" the NameNet subscriber info in any way, so I'm not getting Unity subscribers populated in the Octel database. I'm 95% sure it's might be the Octel configuration, but any tips here would be appreciated as well.

1 ACCEPTED SOLUTION

Accepted Solutions
New Member

Re: Unity Bridge question re: auto-created subscribers

Actually, there is not currently a configuration setting in 3.1(x) that can manipulate the way in which the primary extensions are auto-created. It's been discussed and is being considered for a future release.

As Jeff mentioned, you could add alternate extensions. Other options are:

1. Manually change the extensions for those who have already been auto-created.

2. Import Bridge Subscribers with the desired extensions using the ExternalUserImport utility. When the Bridge sends the remote Octel subscriber info to Unity, Unity will simply update the voice and text name of the already existing Bridge subscribers and leave your primary extensions intact.

In regards to your second question, within Octel Analog Networking local subscriber info is not pushed out to remote nodes. It's up to each local node to request information from a remote node when it wants it. Depending on the Octel model/version there are some that will let you demand an update for a subscriber, or range of subscribers, on a remote node. The Bridge follows this model as well. When someone addresses a message to a remote address for which the Bridge does not currently have voice/text name, THEN it will request that from the remote node. You can also manually add mailboxes to the Octel node(s) on the Bridge to trigger this activity without a message being sent. You can also use the Bridge MBUpload.exe utility to trigger this activity for a range of subscribers on multiple remote nodes. But it will always be a matter of one Octel analog networking node requesting info from another, never an offering (push) of info from the source node.

6 REPLIES
Cisco Employee

Re: Unity Bridge question re: auto-created subscribers

I ran this one past the VMI group and they think there's a configuration option in the registry for this but they QA folks want to make sure it was tested properly first - I'll pass the info along as soon as I can get it.

If you get in a jam, making a script to add alternate extensions here would not be a big amount of work... it'd be nicer to see if the bridge connector could do what you want first, though.

New Member

Re: Unity Bridge question re: auto-created subscribers

Actually, there is not currently a configuration setting in 3.1(x) that can manipulate the way in which the primary extensions are auto-created. It's been discussed and is being considered for a future release.

As Jeff mentioned, you could add alternate extensions. Other options are:

1. Manually change the extensions for those who have already been auto-created.

2. Import Bridge Subscribers with the desired extensions using the ExternalUserImport utility. When the Bridge sends the remote Octel subscriber info to Unity, Unity will simply update the voice and text name of the already existing Bridge subscribers and leave your primary extensions intact.

In regards to your second question, within Octel Analog Networking local subscriber info is not pushed out to remote nodes. It's up to each local node to request information from a remote node when it wants it. Depending on the Octel model/version there are some that will let you demand an update for a subscriber, or range of subscribers, on a remote node. The Bridge follows this model as well. When someone addresses a message to a remote address for which the Bridge does not currently have voice/text name, THEN it will request that from the remote node. You can also manually add mailboxes to the Octel node(s) on the Bridge to trigger this activity without a message being sent. You can also use the Bridge MBUpload.exe utility to trigger this activity for a range of subscribers on multiple remote nodes. But it will always be a matter of one Octel analog networking node requesting info from another, never an offering (push) of info from the source node.

New Member

Re: Unity Bridge question re: auto-created subscribers

Thanks for both your replies. Given the choice that exists today, option 2 above looks like the best one (the remote Octel system in question is massive with 3000 or so subscribers). I was not aware that the sync process would leave the specified extensions untouched, good to know. Regarding future functionality, I know this customer and several others right now would definitely appreciate the ability to manipulate the autocreated extensions in some way, preferably by leaving Dial ID's off.

I do have one follow on question, when a subscriber on either system changes their spoken name recording, I take it the system administrator has to manually initiate some process to get the new name recording sync'd on the other side? I haven't tested it yet but I suspect this is the case based on the "pull" nature of how OctelNet seems to work. Any thoughts on this?

I was thinking if a Octel "permanent" subscriber was deleted and recreated on the Bridge, the Bridge would initiate the new pull and propagate this info into Unity.

Not too sure what need to happen in the other direction, or if simply using the Synchronize button from the Unity server would do the trick.

New Member

Re: Unity Bridge question re: auto-created subscribers

Yes, I agree with you about the ability to manipulate autocreated extensions. In fact, the network addressing needs more flexibility period - then the autocreation logic should be included as a subset of that. Improvements in this area are in the requirement/design stage right now and are being targeted for an upcoming release.

Within Octel Analog Networking, a voice name change will only be picked up by a remote system if the text name also changes. When one node delivers a message to the other a text name compare is always done (in case the extension has been re-assigned, etc.). If the text name on the receiving node for the to: mailbox does not match the text name in the message for the to: mailbox, the following happens:

-the receiving node refuses the message and tells the sending node it's due to text name mismatch.

-the sending node NDRs this message

-the sending node deletes the old record in its directory for this remote mailbox

-the sending node makes a new admin call to the remote node to retrieve the text/voice name for the mailbox it just deleted.

-the new text/voice name and the associated mailbox are added in to the directory on the sending node.

You are correct that deleting an entry in the Octel node directory on the Bridge and then readding it would have the same effect.

To find out more about how Octel Analog Networking works, check out the networking sections in the following Avaya docs. They've been very helpful for me. You are very wise to have all of these Octel Analog Networking questions - knowing this stuff is critical to a successful Bridge experience. I think these docs will help you alot. Thanks.

Avaya Octel 100 docs http://support.avaya.com/elmodocs2/Octel/octel100/index.jhtml

Avaya Octel 200/300 Serenade docs http://support.avaya.com/elmodocs2/Octel/octel200300/

Avaya Octel 250/350 Aria docs http://support.avaya.com/elmodocs2/Octel/octel250350/

Avaya Interchange docs http://support.avaya.com/elmodocs2/intuity/intrchng/r53_2/r53_2.jhtml

New Member

Re: Unity Bridge question re: auto-created subscribers

Thanks Joe! Last question.. I promise.. you mentioned the mbupload utility above, I assume this utility allows for batch population of the Bridge database. But I can't find any documentation that tells me what infile format the utility expects. Also, it looks like it's looking for a database path too, I assume this is the path to the Access file used by the Bridge.

New Member

Re: Unity Bridge question re: auto-created subscribers

I thought this tech tip got posted to CCO quite a while back but I just looked there and there's no link. Try this link...

http://www-tac.cisco.com/Support_Library/Software/Voice_Telephony_and_Messaging/Cisco_Unity/UsingtheCiscoUnityBridgeMailboxImportTool.doc

If that doesn't get it for you I'll email it to you.

This info will also be in the Cisco Unity 4.0(1) Bridge Networking Guide.

91
Views
0
Helpful
6
Replies
CreatePlease login to create content