210 likes | 485 Views
Cisco Unity Connection Notification. Jane Rygg Core Services Team UCBU North. Notification TOI Content. Changes from 4.x Notification architecture UMSS Media settings Resync When to expect MWI lamp updates When to expect notifications Diagnostics and troubleshooting tips.
E N D
Cisco Unity ConnectionNotification Jane RyggCore Services TeamUCBU North
Notification TOI Content • Changes from 4.x • Notification architecture • UMSS • Media settings • Resync • When to expect MWI lamp updates • When to expect notifications • Diagnostics and troubleshooting tips
Notification Activity • Notification activity is asynchronous in nature. Notification dial-outs and MWI updates are sent out as port resources allow. • Notification activity is driven by message activity, configuration changes, and resync requests. • These events are communicated to the Notifier via the NotifyQ table in the UnityDynDb database. • The Notifier gets these events FIFO but the event handling is split up in order to process the various types of events in manner appropriate to the type of event. It is desirable to process message store events as soon as possible and they are typically quick to process. Resync events take longer to process since they typically involve reading the subscriber information from the database and also not as time critical.
UMSS Interaction • A “Notify” flag in the mailbox gets set to TRUE if mailuser has enabled MWI or notification devices. When this flag is TRUE, UMSS will send events about message activity to the Notifier. • Message counts for a mailbox are available without actually needing to count the messages • Mailbox object id used to identify mailuser (distinct from subscriber object id)
Media Settings • Ports have Outgoing Hunt Order – highest hunt order is preferred and round robin usage with ports of same hunt order. Hunt order is used to minimize collision for incoming and outgoing calls and round robin strategy is used to distribute port for port memory MWI. • Port capabilities same as in 4.x • To use a port for MWI, MWI must be enabled at the Port Group level as well as MWI capability at Port level. • The Phone System MWI settings: • Update for Every New Message: MWI lamps updated for each message count change – used if phone display includes message counts • Use Same Port for Enabling and Disabling MWIs (port memory) – needed for some legacy switches. Integration guide will indicate if needed. • Port memory requires that a port used for an MWI On be saved. If such a port is deleted, all MWIs associated with that port will be turned off. • Minimum free answer ports – Advanced Telephony page
Port Settings – Outgoing Hunt Order • Highest hunt order is preferred and round robin usage of ports with the same hunt order. Hunt order is used to minimize collision for outgoing and incoming calls and the round robin strategy is used to distribute ports for port memory MWI.
Port Settings – Port Capabilities • Port capabilities same as in 4.x
Port Group Settings – Enable MWI • To use a port for MWI, MWI must be enabled at the Port Group level as well as have MWI capability at Port level.
Phone System MWI Settings – Always Update • Update for Every New Message: MWI lamps updated for each message count change – phone display includes message counts
Phone System MWI Settings – Port Memory • Use Same Port for Enabling and Disabling MWIs – needed for some legacy switches. Integration guide will indicate if needed.
Advanced Telephony – Min Free Answer Ports • Minimum Number of Ports (per Phone System) for Answering Calls – MWI and notification dial-outs are limited such that this number of ports is always free to answer incoming calls.
Resync • Resync involves resync with message store, directory database, and MWI (either hard or soft). • Soft MWI resync will result in MWI update only if ON/OFF state isn’t compatible with message counts. Hard resync will always result in MWI update. Note that for the always- update feature, a soft resync will also always result in MWI update. • The Notifier startup resync is a soft MWI resync. • A Resync MWI task can be scheduled which includes all switches and is a hard MWI resync. • A resync can be started from the Phone System page. It is a hard MWI resync for all mailusers with MWI on the switch. • A resync for a mailuser can be started on the MWI page for the mailuser. This is a hard MWI resync. • The resync-done event occurs after database and message store resync but MWI events could still be pending (especially if the MWI resync is a hard resync).
When to expect MWI lamp updates • Message events • Message count goes from 0 to 1, lamp goes on • Message count goes from 1 to 0, lamp goes off • Always update feature results in lamp updates for every message count change • Resync • If the resync is a hard MWI resync, always • If the resync is a soft MWI resync, if the lamp is currently off but the user’s message count is non-zero.
When to expect MWI lamp updates (cont.) • Configuration changes • Disable MWI: lamp goes off if currently on • Delete a MWI: lamp goes off if currently on • Enable MWI: lamp goes on if user has non-zero message counts • Add a MWI: lamp goes on if user has non-zero message counts • Change MWI extension or switch: if lamp on, then old extension turned off and new extension turned on • Change DTMF access if MWI inheriting user’s DTMF access id: if lamp on, then old extension turned off and new extension turned on • Remove user: all MWI lamps for user go off if currently on
When to expect notifications • Message events • When schedule is on and new messages received based on Notification Event: • Every New Urgent Voice Mail – New urgent message received • Every New Voice Mail – New message received • First Urgent Voice Mail – Urgent message count goes from 0 to 1 • First Voice Mail – Message count goes from 0 to 1 • Schedule considerations • Delay before sending notification • Repeat notify – if this is used there will be notifications at the specified minute interval after the hour • Notifications go out when schedules go from off to on. Note that schedules are per time zone of user. • New devices must have a schedule associated with them. Default devices with default subscriber template are associated with business hours schedule.
When to expect notifications (continued) • Configuration changes • If a notification device is changed from disabled to enabled, a notification will go out if the user has messages corresponding to the device and the schedule is on. • Resync • If mailuser has messages corresponding to the event of the notification device (urgent voice mail or normal voice mail), then a notification dial-out will occur if the schedule is on.
Diagnostics – Macro Traces • MWI macro trace – select SIP or TAPI • Other Notification Problems macro trace – select SIP or TAPI • SMS troubleshooting will require the SMS Device micro trace • Gather diagnostics from both CuNotifier and CuCsMgr diagnostic files. The CuNotifier diagnostic file will contain information about the determination to send a notification or MWI update and the CuCsMgr diagnostic file will contain information about the actual notification or MWI update.
Diagnostics – Notifier Micro Traces • Initialization • MWI Device • Conversation Device • Pager Device • SMTP Device • Resources • NotifyQ Events • Resync • Message Counts • Rule Evaluation • Schedules • SMS Device • Low numbered levels (below 10) are low level debug info and shouldn’t be needed. If used, don’t let them running long as they will be chatty.
Windows Events • The event source is CiscoUnity_Notifier • Media type MWI errors result in a warning event about the failure to set the mailuser’s MWI. • If no ports with MWI capability then a warning event about the situation will appear once, after the first attempt to use a port for MWI. • Resource type MWI errors (such as no ports with MWI capability on a certain switch) result in a error event about the failure to set the mailuser’s MWI. • If no ports with notification capability then a warning event about the situation will appear once, after the first attempt to use a port for message notification. • Resource type notification errors (such as no ports with notification capability on a certain switch) result in a warning event about the mailuser’s notification failure.