In this post i would like to shed some light on of the important aspect of Unity connection , i would try to cover in deep depth the basics, overview and features of this concept and most importantly i would like to cover the troubleshooting basics that you can use while dealing with real-world issues. So lets get started - I will be starting by providing the agenda first; which is as below;
Agenda
⧫ What is Digital Networking?
⧫ Connection Locations/Nodes⧫ Directory Replication
⧫ New and Changed Behavior
⧫ Traces
⧫ Q&A
Digital Networking :- Similar to Unity, Unity Connection Digital Networking allows for multiple UC node to share a common user directory. Rather than using a third party directory, nodes exchange information using custom XML messages delivered via SMTP and inserted into the database,using a process similar to Unity Bridge/VPIM Directory. Real-time info is pulled from the local database only.As a result of the common directory, users can exchange messages (reply,forward, etc) and transfer to other users seamlessly.
What objects are replicated?
- Users
- Contacts
- Distribution Lists and Member Info
- Partitions
- Search Spaces
- VMS Locations
- VPIM Locations
Requirements
▪UC 7.0(1) or later (not allowed with Business Edition/co-res)
Similar to (primary) location objects in Unity, one is created to represent each node (single server or a/a cluster) in the directory.
Usually referred to as VMS (Voice Messaging System) Locations in traces, SQL tables, etc
Adding a Node
- Two ways to add a node
➤Manual – download config file, upload to remote node
- After two nodes are joined to the same digital network, additional nodes only need to be joined to one node, info will be automatically replicated to other nodes.
Manual
- Download config file from first node, upload it to the second node
- Useful when web (https) connectivity is blocked between node
- Config file contains all necessary information to create VMS location object
Sample Config File*
locationObjectId,98c3347a-f84a-4c7a-a3cb-6da8e3d53591; locationDisplayName,pancakes;locationHostAddress,14.107.3.42;locationSmtpDomain,pancakes;userSynchronizationUserObjectId,b82de726-ff2c-4822-914c-ad1fc8024ff9;userAlias,Replication;systemVersion,7.1.2.0ES9;locationCertificate,
Automatic
- Easiest option, should be used as first option
- Just provide IP and credentials of remote node
- All info from config file is transferred automatically via HTTPS
- CUCA micro traces on each node will show the transaction
Enabling CuReplicator
- The process that handles processes incoming and generates outgoing directory messages is the CuReplicator service.
- After joining the first and second node, you’ll see a warning on the Connection Location page that the service needs to be enabled for replication to occur.
Removing a Node
Push Synchronization
Object order
➤During synchronization, we will send these objects first in order to satisfy dependencies for later objects:
–VMS Locations
–Partitions
–Search Spaces
–VPIM Locations
➤After sending these, we will send the rest of the objects according to their USN order:
–Users
–Contacts
–Distribution Lists & Members
Push Synchronization State Machine
Pull Synchronization State Machine
Normal Replication
Each change creates a new USN for the node.While synchronizing with a remote node, we may send new changes along with older synchronizing changes.As objects are created, modified, or deleted, the SQL stored procedures that make these changes automatically add a new row to tbl_ObjectChange.CuReplicator service checks the table for updates, when one or more are detected,directory messages are created for each node and passed to the SMTP process via separate drop folder.Local SMTP process picks up the messages and passes them to the remote nodes. SMTP on the remote nodes recognizes the directory messages and drops them into a separate drop folder. CuReplicator on remote nodes picks up the directory messages, adds the data to the local tbl_ObjectChange, and pushes out the directory changes to the local database.Once the changes are committed, each remote node sends an acknowledge message to the original node via SMTP. Normal replication will be temporarily suspended during bulk operations, such as running Bulk Edit or Bulk Admin, to cut down on unnecessary updates.
• In 2.x, voice messages were delivered by handing them to the SMTP server, which would pass them to the MTA, which completed the delivery.
• This process remains essentially the same for remote recipients, with the one difference being, if the SMTP server receives a message addressed to a remote node, it passes the message to the remote server, where it is then delivered as a local message
• Messages to PDLs require some special treatment. Essentially, messages addressed to PDLs are sent to each node. Each node then expands out the local recipients for the PDL and is responsible for delivery to those users only (handled by MTA).
Cross-Server Login and Transfers
Similar to the function in Unity, this allows for a single pilot to be used for message access, a single auto attendant that can reach all users, etc.
On the originating server (where calls are initially sent), enable cross-server features on each remote location that you want to handle:
On the receiving server, enable processing of cross-box requests (System Settings->Advanced->Conversation):
•The DTMF handoff is slightly different than Unity
•For all Cross-Box handoffs, the originating server sends DTMF B and waits for the receiving server to reply with D. The next string depends on the type of call
•Login: 0<user's extension>#
•Transfer: 2<calling party>*<user's extension>#
•Send to Greeting: 3<calling party>*<user's extension>#
Cross-Server Cautions
•Keep partitions and search spaces in mind. The path that the caller initially takes on the originating and receiving servers must use a search space that includes the partition of the user.
•There is a new field included on the user page:
This field is only used if cross-box transfers are –not- enabled for this user’s location. Any attempts to transfer to this user from a remote node will be release transferred the extension specified here instead.
Traces
•Joining Nodes – CuCa 3,4 – output in diag_Tomcat
•SMTP sending/receiving – SMTP 12,15 has most details, optionally turn on all
•Processing of incoming/outgoing directory messages and syncs – CuReplicator 3,13 for most details
•Delivery of voice messages – MTA (all)
•Contents of directory or voice messages – packet capture, filter on port 25 (and, optionally, remote node’s IP):
utils network capture file <filename> count 100000 size ALL port 25.
No comments:
Post a Comment
What do you think about it