Features
Live Dialpad
IP Line provides support for the Live Dialpad feature. Live Dialpad
activates the primary line/DN key when the user makes a call by pressing
the keys on the dialpad without lifting the handset, pressing a line/DN key
or the handsfree key.
The Live Dialpad feature is supported on the following IP Phones:
• IP Phone 2001
• IP Phone 2002
• IP Phone 2004
• IP Phone 2007
• IP Audio Conference Phone 2033
• IP Softphone 2050
• WLAN Handset 2210/2211/2212/6120/6140
• IP Phone 1110
• IP Phone 1120E
• IP Phone 1140E
• IP Phone 1150E
• IP Phone 1210
• IP Phone 1220
• IP Phone 1230
Live Dialpad is enabled and disabled in the Telephone Options menu on the IP Phone. Feature processing is performed on the LTPS. The on or off state for the Live Dialpad feature is stored on the Call Server.
Diagnostics
Output of vxWorksShell command e2dsetShow() contains a state of the Live Dialpad feature.
Unicode support
IP Line provides Unicode capabilities on the IP Phone 2007, IP Phone 1110, IP Phone 1120E, IP Phone 1140E, and IP Phone 1150E. Using the Unicode feature the Call Server can easily display multilingual text on the IP Phones for the following languages:
• Japanese
• Greek
• Traditional Chinese
• Simplified Chinese
• Arabic
• Korean
• Hebrew
These languages are not available on IP Phones without Unicode capabilities. Japanese is available in Katakana version.
If an IP Phone without Unicode support registers to a TN with Unicode-only language configured, the IP Phone falls back to English. The information stored on the Call Server is not changed unless the user explicitly changes the language.
Personal Directory, Callers List, Redial List, and user-defined feature key labels support Unicode. Corporate Directory and Calling Party Name Display (CPND) do not support Unicode.
Pop-up and USB keyboard support
Only a limited subset of Unicode characters can be input using the dialpad. The Special Characters Input Screen includes the character set which is used by the current language. For languages with a large amount of characters, such as Traditional Chinese, Japanese, and Korean, localized input is not supported. The Pop-up and USB keyboard supports English input only.
Language synchronization
Language synchronization is handled strictly through UNIStim messaging. If the IP Phone receives an Assign IT Language from the Call Server, the IP Phone changes its local prompts to match the specified language. If a user sets the IP Phone language using the Telephone Options menu, the IP Phone sends a UNIStim Assign NI Language message to the Call Server. The Call Server then synchronizes its language with the IP Phone. The Call Server can use the Query IT Language message at any time to determine the current language of the IP Phone. If there is no default or programmed mapping for a language specified by the Call Server, then the IP Phone uses the same language that is previously used. It is up to the Call Server to only specify languages for which the IP Phone has fonts and font mappings. The Call Server retrieves a list of language codes using the
Display Manager Query Supported IT Languages.
Virtual Office interaction
Virtual Office log on can be performed from an IP Phone without Unicode support to an IP Phone with Unicode entries in the Personal Directory. Unicode name is displayed instead of the name of the entry. The entry cannot be edited, but it can be deleted.
IP Client cookies
IP Client cookies provide a transparent transfer of data from the Call Server to third-party applications, for example, Citrix AG. The cookies are a set of UTF-8 variable names and values, which are duplicated and synchronized between the LTPS and the IP Phone. IP Line uses public cookies which are visible to both the IP Phone and third-party applications. IP Client cookies are not supported on Nortel Phase I IP Phones and third-party IP Phones, such as WLAN Handset 2210/2211/2212/6120/6140, and IP Audio Conference Phone 2033.
New IP Phone Types
IP Phones Types provide the following functionality:
• unique TN types for each IP Phone
• special emulation mode for IP Phones that are not known to the TPS
• automatic and manual IP Phone TN type conversion
• existing IP Phone TN types are renamed to match the brand name of the IP Phone
• enhanced Model Names support is accessed from LD 20 and TM 3.1
Unique TN Types for existing IP Phones
TN Types match the brand name of the IP Phone. The names of existing IP Phone TN types are updated with a naming convention to match the brand name of the IP Phone.
Active Call Failover for IP Phones
The Active Call Failover (ACF) for IP Phones feature allows active IP calls to survive the following failures:
• IP/IP calls and IP/TDM calls survive signaling path TLAN subnet failures. IP/IP calls means both parties are IP Phones. IP/TDM calls means one party is an IP Phone and the other party is a TDM telephone or trunk.
• IP and IP/TDM calls survive Signaling Server restarts. The IP/TDM call does not survive if the Voice Gateway Media Card with
the DSP resource used for the call fails.
• IP and IP/TDM calls survive LTPS ELAN subnet failures.
• IP calls survive a Call Server cold start and Call Server failures in system configurations with a redundant Call Server of the following types
— Media Gateway 1000B for a branch office configuration
— Geographic Redundancy Secondary Call Server.
The feature addresses the Primary Call Server failures.
IP Phone to IP Phone calls survive the Call Server failures listed above.
ATTENTION
IP Phone to Media Gateway calls through IP Peer virtual trunk routes are preserved on the TDM side of the Media Gateway, in some cases, when the IP Phone is redirected in ACF mode from the main office CS 1000 to the MG 1000B at the branch office location, or from the Geographic Redundancy Primary to the Secondary Call Server. IP Phone to Media Gateway calls are preserved if the Media Gateway to which the call is established is not affected by the failure, or if there is cold restart of
the Call Server that controls the Media Gateway where the IP Peer virtual trunk call is established.
• For Call Server call processor types CP PII, CP PIV, and CP-PM:
— IP/IP calls survive a cold start on all systems.
— IP/IP and IP/TDM calls survive a warm start on all systems.
— Graceful switchover and graceful failover to the redundant Logical Call Processor (LCP) side of the Call Server makes the failure transparent and allows all the calls to survive without any loss.
When the IP Phone with an active call re-registers, the call data is rebuilt if the Call Server does not know about the call, using the internal IP Phone information. The ACF feature for IP Phones meets Joint Interoperability Test Command (JITC) requirements if the LAN/WAN network is engineered to provide full redundancy: that is, if a LAN/WAN network component fails, an alternate path between the clients and LTPS server is provided.
Minimum requirements
The ACF feature for IP Phones has the following minimum requirements:
• Call Server must be running CS 1000 Release 4.5, or later software.
• IP Phones (including IP Softphone 2050) must support Unistim version 2.9. (Use the isetShow command to determine the Unistim version. One of the columns in the isetShow output is UNIStimVsn.)
ACF mode
The ACF feature for IP Phones enables an IP Phone to re-register in the ACF mode during a supported system failure.
The ACF mode preserves the following:
• active media session
• LED states of the Mute, Handsfree, and Headset keys
• DRAM content
All other elements (the self-labeled line/programmable feature keys, context-sensitive soft keys, and text areas) are retained until the user presses a key or the connection with the Call Server is resumed. If the user presses a key during the failover, the display is cleared and a localized "Server Unreachable" message is displayed. The IP Phone uses this new mode of re-registration only when the Call Server explicitly tells the IP Phone to do so. IP Phones clear all call information if they register to a Call Server or LTPS that does not support the ACF feature.
IP Phone ACF timer
It is possible that there may be an LTPS supporting the ACF feature and an LTPS that does not support the feature in the same system. A situation can exist where it takes a long time to fix a failure and no failover Call Server is available. During this time, if the user released the call by pressing the Release key or hanging up the telephone, the call-associated resources are not used. The call-associated resources still exist on the Call Server because they are not released. To prevent this, the 10-minute Call Server ACF timer is introduced for each call. The timer prevents call processing-related resources from being unnecessarily
used when an IP Phone that had an active call unregisters and never re-registers.
The timer is set if:
• the ACF call status is UNREGISTERED; that is, when both parties go offline.
• only one of the parties is offline, and the other party does not support disconnect supervision.
Firmware downloads
If the IP Phone has an active media stream, the LTPS does not request the firmware download in order to avoid resetting the IP Phone and losing the call. Therefore, it is possible that a system has IP Phones with a mixture of firmware versions registered with it. The firmware can be downloaded later, after the idle IP Phone registers again or can be downloaded manually using appropriate CLI commands.
WLAN Handsets 2210/2211/2212/6120/6140
The Wireless LAN (WLAN) Handsets 2210/2211/2212/6120/6140 support Active Call Failover in the same manner as Phase II IP Phones if their firmware supports UNIStim 2.9.
Operating parameters
IP Peer calls
IP Peer calls survive the following failure types:
• TLAN subnet failures.
• Signaling Server platform failures/restarts. When the Signaling Server reboots after the failure, all sessions are lost. Therefore, when the local IP Phone or far-end telephone releases the call, no RELEASE message is sent to the other party. The other party must go on-hook to become idle.
• Call Server warm starts.
IP Peer calls do not survive the Call Server cold start; all virtual trunks are idled as the Call Server comes back up after the cold start. In this case, the local IP Phone must go on-hook to become idle. The zone bandwidth usage in the zone table remains zero for all IP Peer calls on this side; zone bandwidth usage is cleared for all calls as the Call Server comes back up after the warm start. In this case, Network Bandwidth Management information is lost and the Call Server is unable to restore the correct zone bandwidth usage for IP Peer calls.
IP/TDM calls
IP/TDM calls do not survive a Call Server cold start; all DSP channels are closed as the Call Server comes back up after the cold start. In this case, the local IP Phone must go on-hook to become idle.
Dialing state
Only established calls survive failures. All calls having the DIALING state on the Call Server are released when an LTPS or signaling failure occurs that causes an IP Phone to unregister.
Calls that are ringing are handled as follows:
• If the IP Phone originating the ringing call unregisters, the call is released by the Call Server.
• If the IP Phone receiving the call unregisters, the call receives CFNA treatment if possible.
Held calls
From the ACF feature perspective, held calls are considered to be
established. This means that the call is preserved on the Call Server
despite TLAN subnet or LTPS failure. The IP Phone itself is unaware of
the state of any held call.
Phase 0/1 IP Phones
Phase 0/1 phones do not support ACF.
Feature key labels
If user-defined feature key labels have been changed but no datadump
has been performed, the changes are lost if there is a Call Server failure.
SIP telephones
SIP telephones appear as IP Peer endpoints to the system.
NAT devices
The ACF feature cannot handle the case of a NAT device changing the media path mapping between the IP Phone private address and public address during the failover period. There is no way to discover the mapping while the port is in use. For instance, if a main office failure occurs and the user re-registers in local mode, NAT mapping is changed and the active call cannot survive.
Control messages
The LTPS sends the Audio Stream Control and LEDs Control commands in separate messages. If a failure occurs in the time between the two messages, the Audio Stream and LEDs states may not be synchronized. For example, it is possible for the Audio Stream to be muted and a network failure to occur at just the right moment to prevent the LED Control message for the mute LED from being received by the IP Phone.
Held Calls
When an idle IP Phone (one without an active speech path) re-registers, a firmware download can occur, if needed. If that IP Phone actually had calls on hold, this means the held calls cannot be retrieved until after the firmware download is finished.
Voice Gateway Media Cards
The ACF feature does not handle failures of the Voice Gateway functionality of the Voice Gateway Media Cards. ELAN and TLAN subnet failures that affect the signaling with the IP Phones registered to a Voice Gateway Media Card are addressed in the same manner as failures affecting the Signaling Server. However, if there is a failure affecting the speech path to an IP Phone, such as when a PBX link failure occurs and the 10-minute PBX link timer expires, the Voice Gateway calls are released.
Codecs
Not all the codec properties are restored for the failed-over call. The following default codec properties are used for the active failover call:
• VAD is OFF
• G.723 Working Rate is 5.3 kb/s
• G.729 Annex is Annex A
QoS monitoring
The QoS monitoring is always disabled for the failover call. This is only for the period of the failover call; for all subsequent calls, the QoS monitoring works as configured.
Virtual Office
Active Call Failover is not supported for the active call from an IP Phone logged on another IP Phone to a TDM resource or virtual trunk. Such a call is released when the LTPS detects that the connection to the IP Phone is lost. For example, IP Phone A is logged on to IP Phone B and talking to a TDM resource or a virtual trunk. If a TLAN subnet failure occurs and IP Phone
A re-registers with its home TN, the active call is released as IP Phone A re-registers.
Handsfree
Scenario: IP Phone A has handsfree denied and IP Phone B has handsfree allowed. IP Phone A is logged on IP Phone B and talks to IP Phone C using handsfree. If a TLAN subnet failure occurs and IP Phone A re-registers with its home TN (with handsfree disabled), the handsfree functionality is turned off and IP Phone A must go off-hook to continue the conversation.
ELAN subnet failure
The ACF state cannot be determined on the LTPS side during an ELAN subnet failure. This is because the ACF state is stored on the Call Server and it is not possible to send the ACF state on the LTPS side when the ELAN subnet has failed. When the ELAN subnet is down, the isetShow command always outputs the ACF state as UNKNOWN for all established calls (the state is shown as busy-UNK).
Feature interactions
This section shows the ACF feature interactions with Virtual Office and Branch Office.
Branch Office
When the first failed IP Phone re-registers in local mode, the branch office Call Server looks up the far-end branch IP Phone local TN using the specified far-end IP address and builds a local call. The call can be rebuilt only if both the IP Phones are branch users of the same branch office.
Example: A regular main office IP Phone talks to the branch IP Phone registered with the main office. A failure occurs on the main office, so that the branch IP Phone cannot register in normal mode again, and re-registers in local mode. Even if the main office IP Phone survives the failure, the call cannot be rebuilt because the call becomes an IP Peer call between the branch office and main office. This call becomes Partial Rebuilt and exists until released.
Virtual Office
It is possible that active IP Phone A, that was logged on to IP Phone B before the failure, cannot re-register with the Call Server, because IP Phone C performed a Virtual Office logon and uses IP Phone A TN. In this case, the Signaling Server/Voice Gateway Media Card locally handles the Release, Onhook and Mute events coming from IP Phone A in the Logged Out state.
Survivable Remote Gateway
The Survivable Remote Gateway (SRG) 1.0 and SRG 50 do not support ACF. If the IP Phone is an SRG user, the active call, either in normal mode or local mode, does not survive a failure.
NAT
The NAT discovery is delayed for an IP Phone with an active call when it re-registers. NAT discovery messages are sent through the port used for the RTP stream. NAT discovery is not initiated if the LTPS detects that the IP Phone has an active RTP stream.
Personal Directory, Callers List, Redial List
The display content is cleared and the Personal Directory/Callers List/Redial List applications are reset when the active call failover process starts. The applications can be used again only after the IP Phone re-registers. A user that is using one of the Personal Directory/Callers List/Redial List menus sees the display clear and loses any data in that transaction that was not selected or saved with the Personal Directory/Callers List/Redial List feature. ACF implementation does not maintain data present only on the Signaling Server/Voice Gateway Media Card. Transient data (for example, the Services key submenu the user is currently in) is lost when the failover occurs and the IP Phone re-registers.
Converged Desktop
If the Call Server maintains the active call information during the active call failover, and the SIP Gateway maintains the link and information with the MCS 5100 (the SIP Gateway has not failed or is not on the Signaling Server that reboots if that is the failure mode), a Converged Desktop call is maintained when the involved IP Phone re-registers to the system. If the Call Server loses the call information or the SIP Gateway Signaling Server reboots, the Converged Desktop call is impacted. A Converged Desktop consists of a telephone and multimedia PC Client (PCC) software.
The following are scenario examples.
Example 1: The IP Phone TLAN subnet fails and the IP Phone re-registers with the same or a different TPS.
In this case, both the voice and multimedia sessions survive: if a SIP call is established with the other party in the SIP domain, the call is not released as the IP Phone re-registers. The multimedia applications still work: the presence is updated on PCC after the telephone re-registers. If the unregistered converged IP Phone releases the call during the TLAN subnet failure, the Presence status is updated on PCC as the idle converged IP Phone re-registers.
Example 2: The IP Phone Signaling Server fails and the IP Phone re-registers with the same or a different TPS (active converged IP Phone and SIP Gateway are on different Signaling Servers in the same node). In this case, both the voice and multimedia sessions survive; the scenario is the same as the TLAN subnet failure in Example 1. Example 3: The IP Phone ELAN subnet fails and the IP Phone re-registers with the same or a different TPS. The voice session survives. If the ELAN subnet comes back up before the IP Phone changes the call state (that is, releases the call), then the multimedia session is not impacted.
If the IP Phone releases the call when the ELAN subnet is still down, the PCC status update happens when the idle converged IP Phone re-registers with the system. If the call is released by the supervisory timer, the status is updated on PCC after the ELAN subnet comes back up and the Converged Desktop AML ELAN subnet link is enabled (the CSA104 message is output on the
Call Server when this happens).
Example 4: Call Server warm start.
The voice and multimedia sessions survive. The Presence status is updated on PCC as the converged IP Phone releases the call after the warm start.
Example 5: Call Server cold start.
The voice and multimedia sessions are closed as the Call Server comes up. The Presence status becomes Connected - Idle even if the call is rebuilt and active after the Call Server cold start.
IP Phone firmware downloads
The firmware is not downloaded to an IP Phone that has an active RTP stream open when it registers with the failover system. The firmware is downloaded later when the idle IP Phone registers again or by using appropriate CLI commands. IP Phone as ACD agent or supervisor telephone If an IP Phone is used as an ACD agent (or supervisor) and the Call Server fails:
• In the case of a Call Server warm start (INI), the active calls are retained on the agent telephone.
• In the case of a Call Server cold start (SYSLOAD), the active calls are dropped and the agents are logged out.
This applies to both the In-calls (PRIMARY) key and any secondary DN key on the ACD telephone. TPS failures do not impact general ACD functionality, because the ACD feature is implemented on the Call Server.
CS 1000 base features
No feature works when the active IP Phone is disconnected and trying to re-register with the Call Server. All the features can be used in the context of the failover call after the IP Phone re-registers (if it is not a PARTIAL REBUILT call).
The feature context is lost on the Call Server if the Call Server fails. The feature context is not lost on the Call Server in a case of TLAN/ELAN subnet failure. Only the feature data on the IP Phone display is lost.
Feature context in Call Server failures
The context of any feature is lost on the Call Server in cases of Call Server failure (Call Server warm or cold start). The LTPS IP Phone display is lost as the IP Phone re-registers. This means if a feature is activated and the Call Server fails, all the user input and data is lost.
Example: IP Phone A is in a call; the user presses the Transfer key and starts dialing a DN. The Call Server cold or warm starts. Therefore, IP Phone A does not accept the user input and tries to re-register with the Call Server. When the Call Server comes back up and the IP Phones re-register, IP Phone A does not have the Call Transfer activated. The held call is also lost: it is not rebuilt after INI or by the ACF feature, because the call is not active.
TLAN/ELAN subnet and LTPS failures
When a network or Signaling Server/Voice Gateway Media Card failure occurs and the active IP Phone has some feature activated, the feature context and data is not lost on the Call Server. The user can proceed with the feature after the IP Phone re-registers. Only the LTPS display is lost when the IP Phone re-registers.
Example: IP Phone A is in a call; the user presses the Transfer key, and starts dialing a DN. A TLAN subnet failure occurs when the first digit is dialed. The user is unaware of the failure and continues dialing the DN. The digits dialed after the failure are ignored, the IP Phone detects the failure, clears the display, and tries to re-register with the server. The TLAN comes up again and the IP Phone re-registers. Although the IP Phone is now idle and the display is cleared, the IP Phone can resume
dialing the DN starting from the second digit. The IP Phone can also return to the held call by pressing the held call DN key.
CDR
No ACF-specific information is added to the Call Detail Record (CDR) records. In the case of Call Server failure, the CDR records for the call before the failure occurred are lost. CDR is restarted as the active IP Phone re-registers. Therefore, the records are generated only for the post-failure period of time.
