1 of 5 04/10/2013 15:29 Version 02, October 2006 Private to Public Overflow between IP Media Gateways Detailed description Table of contents Steps of an Overflow Overflow to a DID Set Overflow to DID Set from Domain 2 Overflow to a Non DID Set Overflow to a Set Rescued by a Passive Communication Server Interaction with the Routing Service Intelligence Accounting Former Releases Compatibility Restrictions Steps of an Overflow Example of Overflow
2 of 5 04/10/2013 15:29 Overflow to a DID Set 1. 2. 3. The calling party (61001) dials the destination number: 63001, located in domain 3 There is no resource available to reach domain 3. An overflow is required The system checks the right to overflow of the calling party (61001). Note: If this parameter is set to No, then the call is rejected. 4. The system builds the called party public number with the following configuration data: The prefix to add. For this example node: 0 The node DID translation table. In this table, the internal number 63001 (DID number) is associated to the public number 01 23 45 30 01 For DID numbers, the translator assigns one public number to one DID number. All DID internal numbers are translated into an external number. The number built is 0 01 23 45 30 01. 5. 6. 0 must be the ARS prefix. The ARS process is invoked The ARS process is configured as follow: For the public number 01 23 45 30 01 there are two possible routes: The first route uses trunk group 1 The second route uses trunk group 2
3 of 5 04/10/2013 15:29 In this example, the calling party is located in domain 1, trunk group 1 is available. Trunk group 1 is used. Overflow to DID Set from Domain 2 For a call from set 62001 belonging to domain 2, steps 1 to 5 are the same. In step 6, the first route through trunk group 1 is not available. The ARS tries route 2 through trunk group 2. In domain 2, trunk group 2 is available. Trunk group 2 is used. Overflow to a Non DID Set When the calling party 61001 calls a non DID set (63555) located in domain 3, steps 1 to 3 are the same. In step 4, all non DID numbers are translated to a unique number. This unique number is the set number (DID) of the domain attendant. Steps 5 and 6 are the same. All non DID internal numbers are translated into the same external number. Overflow to a Set Rescued by a Passive Communication Server The Communication Server sees any set that belongs to an IP field rescued by a Passive Communication Server as Out of Order. The system must check whether overflowing on a set which is out of order is authorized or not. Interaction with the Routing Service Intelligence As of R8.0.1, the private to public overflow feature can be used by the Routing Service Intelligence (RSI) interface for call processing in the event of IP link congestion or failure. The right to private to public overflow is defined in the RSI feature class of service and not in the set's phone feature class of service of the calling party. Incoming Call routing in the RSI can be interrupted, when the IP link with the called party fails or is satured. When this situation occurs and the RSI enables private to public overflow, call can be redirected to the called party using the public network. The called party can be a business set, a hunting group, an attendant, or an attendant group. Example of Call Overflow to the Public Network
4 of 5 04/10/2013 15:29 In this example, a user A from IP domain 1 calls a local RSI. A route request is sent to the CTI application, which returns a route select message to RSI. RSI, in turn, routes the call to a user B belonging to IP domain 2. In the mean time, a failure or saturation is detected between IP domains 1 and 2. Two scenarios can occur: The RSI does not authorize private to public overflow. In this case, the call is not distributed to user B. According to the call routing strategy applied within the RSI, a reroute request or an end of service notification is sent to the CTI application with the following reason: resource not available The RSI authorizes private to public overflow. In this case, the call is routed from the RSI to user B through the public network, using the same overflow mechanisms as described in: Steps of an Overflow. If the local private to public overflow succeeds, an end of service notification is sent to the CTI application. If this is not the case, according to the call routing strategy applied within the RSI, a reroute request or an end of service notification is sent to the CTI application with the reason for call failure Note: For more information on the RSI routing mechanisms and messages exchanged, see the Routing Service Intelligence - Standard Edition documentation. Accounting
5 of 5 04/10/2013 15:29 One accounting ticket is created per overflow call. In this ticket, the Obtaining mode field is set to overflow. For more details on Accounting, see: Internal accounting / Overview. Former Releases Compatibility As of R6.1, the maximum number of node DID translation tables is increased from 32 to 200. These tables are broadcast to the other nodes of the same ABC network. When more than 32 tables are sent to a node in a former release, a number of tables are lost. When there are less than 32 node DID translation tables, it is possible to have nodes in former releases. When there are more than 32 node DID translation tables, all network nodes must be in release R6.1 or higher. Restrictions The service provided by the Local Private to Public Overflow between IP Media Gateway is not a virtual private network as carried out by the feature VPN Overflow (see: VPN overflow / Overview). The service provided is similar to that of Overflow on public network (see: ABC-F homogeneous private network / Available features / Overflow on Public Network). The service provided by the overflow is limited to the services of the public network (e.g. ISDN services). In case of overflow, ABC-F2 services are no longer provided. For example, a forward on voice mail is displayed for an internal call and not for an overflow call.