This topic describes how to implement TEHO in a multisite environment.
PSTN breakout occurs at the gateway that is located closest to the PSTN destination.
- Route pattern for each area that can be reached at different costs; one per site, in different partition
- Route patterns point to route lists (with different gateway priorities: cheapest gateway first, local gateway next)
- Phone CSS or local route group for correct route-pattern selection
When you implement TEHO, PSTN breakout occurs at the gateway that is closest to the dialed PSTN destination. This action occurs because you create a route pattern for each destination area that can be reached at different costs. These route patterns refer to route lists that include a route group for the TEHO gateway, first, and the local route group as the second entry so that the local gateway can be used as a backup when the IP WAN cannot be used.
Your country or provider might not permit the use of TEHO. There can also be issues with emergency calls. Therefore, ensure that your planned deployment complies with legal requirements.
Considerations When Using Remote PSTN Gateways
When you use backup TEHO, you must consider several potential issues.
What should the calling number look like?
- Using PSTN number of originating site at TEHO gateway:
- Keeps standard numbering to the outside
- Possible callbacks from the PSTN
- Legal issue in some countries, or not permitted by provider
- Issues with emergency dialing
- Replacing PSTN number of originating site with the PSTN number of TEHO site:
- Confuses called party
- Called party can use signaled calling number in the future to reach calling party
- If DID is supported on only one gateway, IVR script at the gateway without DID must know how to route calls to directory numbers of all sites
- There are issues with emergency dialing
The first thing to consider when you use TEHO is the calling number that you want to use for the outgoing call. There are two options for configuring the calling number for the outgoing call:
- Use the PSTN number of the originating site at the TEHO gateway: When you use the PSTN number of the originating device for the caller ID of a TEHO call, the called party is not aware that TEHO has been used. Standard numbering is maintained for all PSTN calls, regardless of the egress gateway; callbacks to the calling number are possible. However, sending calls to the PSTN with PSTN caller IDs of other sites may not be permitted, or the receiving PSTN provider may remove caller IDs from the signaling messages.
Your country or provider might not permit sending calls out of a gateway with the calling number of another site. There can also be issues with emergency calls. Therefore, ensure that your planned deployment complies with local requirements.
- Replace the PSTN number of the originating site by the PSTN number of the TEHO site: When you use the calling number of the backup gateway, called parties may get confused about the number that should be used when calling back. For instance, they may update their address books with the different number and accidentally end up sending calls to the TEHO site every time they call. Further, DID ranges would have to include remote phones or IVR scripts (automated attendants) to be able to route calls to phones located in any site, regardless of where the PSTN call was received.
Your country or provider might not permit the use of a remote gateway for PSTN access. There can also be issues with emergency calls. Therefore, ensure that your planned deployment complies with local requirements.
In general, it is highly recommended that you use the local route group feature when implementing TEHO. In order to provide a local backup for TEHO calls, call processing must route all calls differently, based on the source (physical location) and on the dialed number, when the TEHO path cannot be used. When you are not using local route groups, this approach can require a huge number of route patterns, partitions, CSSs, and route lists, resulting in complex dial plans. Such dial plans are difficult to maintain and troubleshoot.
You must also consider CAC when implementing TEHO. When the primary TEHO path is not admitted, the local gateway should be used instead.