"Portable Directory Number" is another term used to describe voice clustering. See the Voice Clustering book in this online help system for more information.
This feature provides call redirection over a DPNSS network of mixed-vendor (Mitel and other) systems supporting the DPNSS call redirection protocol. It provides Attendant Recall functionality over a mixed-vendor DPNSS network.
The sequence of events in a typical MSDN/DPNSS Redirection might be as follows:
A caller on System A calls the attendant at System B and asks to be connected with someone on System C.
The call is transferred, but the target extension is either busy or not answered.
System A rings the attendant at System B again, indicating redirection.
Note: The target extension can be on local (System A), on the attendant system (System B), or another system (System C).
MSDN/DPNSS Redirection
In the Class of Service Options form of the incoming trunks at the target system, set the No Answer Recall Timer to at least 15 seconds less than the No Answer Recall Timer of the incoming network trunks at the attendant system.
In the Class of Service Options form of the incoming trunks at the target system, set the Camp-on Recall Timer to at least 15 seconds less than the Camp-on Recall Timer of the incoming network trunks at the attendant system.
Diverting party DPNSS strings are accepted but not sent to other vendor's systems. This allows telephone displays to be updated properly and correct voice mail greetings to be played.
Coordinate the No Answer Recall timers and Camp-on Recall timers that are associated with each trunk of every system in the network. Ensure that the timers associated with the incoming trunks at target systems have lower settings than the timers for the incoming DPNSS trunks at the attendant system.
Note: The No Answer Recall timer and Camp-on Recall timer are set on the Class of Service Options form.
A redirection involves the following system actions:
(a) When a call originating from a remote system station is connected or camped-on to a busy station by the attendant, the no answer recall or camp-on recall timers for both incoming trunks (at the target system and the attendant system) will start.
(b) Assuming that the timers are set up correctly (see above), the timer at the target system will run out first. The target system will then recall the attendant (at the attendant system), and indicate via DPNSS signaling that the call is a redirection.
(c) If the timers are set up incorrectly, so that an incoming trunk timer on the attendant system runs out first, a local recall will be initiated by that system before redirection can take place, without DPNSS signaling.
Interworking: When using MSDN/DPNSS Redirection in a network which includes systems using older versions of the MSDN/DPNSS software, or with other systems that do not support redirection, note the following:
(a) If the originating party's system supports redirection, but the attendant system does not, the redirection will take place, but appear as an ordinary call to the attendant.
(b) If the attendant system supports redirection, but the originating party's system does not, redirection will not take place, as it is the originating party's system that initiates redirection. However, if redirection does not take place, the functionality of local recall still exists. If both the originating and attendant systems are Mitel systems, the attendant will be recalled via local recall without DPNSS signaling.
The Route Optimization feature optimizes network channel utilization. It ensures that as few channels as possible are used, by replacing non-optimal call routing resulting from call transfers, congestion, or network conferences, with routings using the fewest possible network channels. To prevent "anti-tromboning", route optimization is triggered when calls are routed back to a local node via transfer and the originating system identifies that it has been answered locally.
Route Optimization of a Transferred Call illustrates the optimization of a non-optimal route resulting from a call transfer. Party A calls Party B on a remote PBX. Party B transfers the call to a third PBX. This creates the non-optimal call routing A - B - C. The Route Optimization feature will replace this call with a direct A - C call.
Route Optimization of a Transferred Call
Route optimization will automatically take place whenever a call transfer is not using an optimal route.
Route optimization applies only to voice calls.
Route optimization occurs when first or second choice routing is chosen on a remote node.
Route optimization does not apply to calls that have been forwarded or to calls that have been rerouted from a set.
Route optimization does not apply to attendant serial calls.
Does not occur when the answering party is a voice mail port.
Does not occur when calls are holding in an ACD queue. (This should be taken into account when programming route optimization attempts. If the number of attempts becomes exhausted before the queued call is answered, route optimization will not take place for that call).
The network must be programmed with a uniform numbering plan.
Automatic Route Selection (ARS) programming on all nodes should reflect the optimal network routing.
As route optimization involves conferencing, the number of available conference circuits will determine the number of concurrent route optimizations and real conferences possible. Conference breakdown to a two-party call, over DPNSS, will trigger route optimization.
"Maximum Trunks in Conference" field on the System Options form must be greater than 0.
Neither party can activate any features during a route optimization attempt.
If the answering party attempts to activate a feature during the route optimization attempt, the attempt is ignored.
If the calling system receives an intrusion notification in response to the route optimization request, the route optimization attempt is aborted.
Note that when a call on an IP trunk is route optimized, the parties on the call will experience a 0.5 second (or less) break of silence in the call.
Programming route optimization involves setting the following fields in the System Options form:
Route Optimization Establishment Timer (10s - 120s) - Set the time allowed to establish an optimum route call. The default is 10s. This value should be extended as the size of the network increases.
Route Optimization Attempts per call (0 - 3) - Set the number of route optimization attempts to be made for each call. The default is 3 attempts. A value of zero disables route optimization. If Route Optimization Network ID or Route Optimization Trailing Digits, or both, are blank, route optimization is also disabled.
Route Optimization Network ID (max 7 digits) - Identify the system for network routing. The Primary Node ID should be used if one exists, otherwise use the ARS value that will cause calls to be routed to this system.
Route Optimization Trailing Digits - Enter the number of digits that will follow the Network ID in the dialing string. This should match the uniform numbering plan in use in the network.
No user action is required to activate route optimization once it is enabled on the system. The only noticeable effect is that callers cannot use features involving DPNSS signaling during a route optimization attempt.
Route optimization involves the following system actions:
Thirty seconds after a voice call has been established, the calling system sends a route optimization request to the answering system. The delay allows a user to activate a feature (most likely attendant transfer).
The Route Optimization Establishment Timer starts. The timer allows a CDE programmed amount of time for successful establishment of a new, optimal call (default 10 seconds). Timer expiry is treated as a rejection.
A route optimization request may be rejected for a number of reasons (see Conditions). If rejected, the calling system will try again in 60 seconds. The number of retries is programmable in CDE, up to a maximum of 3.
If the request is not rejected, the answering system selects a free and optimal DPNSS channel, and establishes a call to the original calling party. Only the first ARS routing is accepted.
The original calling system conferences the new incoming call with the original call, and sends a message to the answering system indicating that the optimization can be completed.
The answering system transfers the original channel to the new channel, and sends a message back to confirm that this has been done. The original calling system then drops the original channel, and route optimization is complete.
Route Optimization Flag in SMDR Reports
An SMDR call record will be generated for both the pre-optimized and post-optimized trunks. The pre-optimized trunk is designated by a lower case "r" and the post-optimized trunk by an upper case "R", in column 85 or 96 (with the SMDR option Extended Digit Length enabled) of the SMDR call record. For further information, see SMDR reports.
This feature extends the functionality of the Attendant Serial Call feature over the digital network. It allows a centralized attendant to set up serial calls for users on remote systems, using the DPNSS protocol. MSDN/DPNSS Serial Call extends this functionality over the digital network, with the same appearance to users and attendants.
The calling system must either support the DPNSS serial call protocol, or be calling the attendant's system through another gateway system which supports the DPNSS serial calls.
Calling party must be permitted serial calls. Conferences and other attendants, for example, cannot participate in a serial call.
Route optimization does not apply to attendant serial calls.
None.
The system actions involved in a MSDN/DPNSS serial call are described in the following paragraphs:
(a) Set up: In established conversation with the calling party, the attendant presses the "Set Serial Call" softkey. The attendant's system sends a serial call request to the calling system. If the conditions listed above are satisfied, and a serial call is not already in effect, the calling system registers the request and sends an acknowledgment to the attendant's system. The serial call is now in effect.
(b) Operation: The attendant connects the calling party to the desired destination. When the destination party hangs up, the calling system recalls the attendant system. The attendant console display indicates that the call is a serial recall.
(c) Cancelation: A serial call is canceled in each of the following cases:
The calling party hangs up.
The attendant presses the "Cancel Serial Call" softkey. This causes a cancelation request to be sent to the calling system. If this request is not received, the attendant will be recalled (until the calling party hangs up).
The attendant hangs up on calling party. The system automatically clears the call, and no serial recall occurs.
Interworking with non-DPNSS networks: A system supporting DPNSS signaling can act as a "gateway" to a non-DPNSS signaling system, permitting serial calls between the networks. In such a case the gateway system acts as the calling system.
The 3300 ICP supports MSDN/DPNSS features for PSTN calls that are received from a Siemens iSDX PBX. See for Siemens iSDX DPNSS Interworking details.
In large or complex MSDN/DPNSS or MSAN/APNSS networks, there will usually be more than one possible route from one node to another. When a call is set up using a chosen route and encounters congestion at an intermediate or gateway node, it will not be completed. The stepback feature allows a call to back up one or more nodes and attempt an alternative path to its destination, before being abandoned.
Stepback
If an expensive route is selected at a transit system (before or after stepping back), the user is not provided with the choice of setting callback or camp-on on the busy route. The caller will hear the expensive tone from the transit system, but will not see any "EXPENSIVE ROUTE" display.
A call set up during route optimization will not step back upon encountering congestion.
Route lists in alternative route selection must be programmed to provide alternative routing. Each route in the route list should be connected to a different node so that an alternative route will not return to the same congested system.
The stepback feature will not operate if a RAD has been programmed in the Trunk Groups form for the case of all trunks busy, and the call is to be redirected to the RAD.
Stepback only works within the MSDN/DPNSS or MSAN/APNSS network boundary.
Route lists must be programmed as necessary, to provide alternative routing for the stepback feature to follow. See Automatic Route Selection, for information on programming route lists.
Not applicable.
For information on how MSDN/DPNSS and MSAN/APNSS network calls are recorded in SMDR reports, see Station Message Detail Recording.
Tandem switching permits the interconnection of an MSAN/APNSS or MSDN/DPNSS trunk to a similar MSAN/APNSS or MSDN/DPNSS trunk, for the purpose of completing a telephone call across a telephone network.
Tandem Configuration
The principle function of a tandem PBX is to interconnect an incoming traffic channel with another traffic channel. A tandem connection involves a similar MSAN/APNSS or MSDN/DPNSS link on both sides of the tandem PBX.
The "Timed Recall" feature provides a timed recall for unanswered calls and calls transferred to a busy extension in the following instances:
an incoming trunk or station call is transferred across the MSDN/MSAN network to a station or trunk which does not answer
an incoming trunk or station call is transferred across the MSDN/MSAN network to a busy device.
The party who invoked the transfer receives the recall after a programmable period as defined in the No Answer Recall Timer or the Camp-on Recall Timer fields of the class of service assigned to the local outgoing digital trunk.
The 'Transfer to a Busy Device' feature allows a user to transfer an incoming trunk or station across the MSDN/MSAN network to a busy device. The transferred party is automatically camped-on to the busy device when the party who invoked the transfer hangs up. Camp-on is not possible if the called station has Do Not Disturb activated.
When a call is transferred from system A to system B over MSDN/DPNSS trunks to an ACD path, with no RAD programmed, the call recalls the transferring device. The call recalls based on the No Answer Recall Timer of the MSDN trunks class of service. This occurs because system A does not know the call was transferred to an ACD path on system B. This information is not shared over the MSDN/DPNSS link.
If a RAD picks up the call, the call is connected to system music (or silence if no music present) and remains on system B without recalling. This is not an issue when the call is transferred from a device on the same system as the ACD path, because the system recognizes the call is ringing an ACD path and does not invoke a recall, even with no RAD in place.
