Overview

You may wish to add an additional set of STPs to which 3rd party traffic can be routed, and you wish to know whether adding this additional set of STPs to your current configuration will route traffic smoothly. For instance, it may be the case that you are anticipating some of your STPs to be out of service, and you wish to add a new set of STPs to your configuration, so that the traffic can be migrated to this new set of STPs. 

Solution

1. If GTT rules are routing to some STPs (e.g. P and Q) and these STPs are out-of-service, you must update the GTT rules on the configuration files to route the available STPs. If the GTT rules are not updated, the RTR will send SCCP abort / UDTS indicating no translation to specific SCCP CdPA address.
2. Consider an example where you have 4 STPs - P, Q, R and S. Of these, P&Q are expected to be out of service, so you wish to migrate their traffic to STPs R & S. Update your GTT rules in your config.txt files with the attribute outputloadshareset from P&Q to P&Q&R&S. E.g.
   • From <gttrule inputgtaddressinfo="1111*" outputloadshareset="STP-PandQ"/>
   • To <gttrule inputgtaddressinfo="1111*" outputloadshareset="STP-PandQandRandS"/>
     where 1111* is an example generic global title address information.
3. When you configure the GTT rules in this manner to send to any of the 4 STPs, it will work as the RTR will load share traffic on the available MTP destinations. So in case STPs P&Q are not available, traffic will be routed to STPs R&S instead.

If you need any additional information about the gttrule entity and its attributes, please refer to section 19.2.10 gttrule Entity on Page 634 of the attached RTR Operator Manual.