So how do you solve this problem? You have two switches, let’s say one is in New York and the other is in Seattle. You have the same vendors interconnected on both switches, so calls coming into NY can easily terminate in Seattle and vice versa. While that will technically work, it is not your preference. You would rather the NY calls terminate in NY if possible, and if not, then try Seattle.

While it was possible to build this on RouteNGN™ in the past, it was needlessly redundant and complicated to maintain. Tags allow users to give priority to outbound endpoints within a single endpoint group based upon the tag applied to individual inbound endpoints, also contained within a single endpoint group. Using our example from above, we can ensure that the NY IP addresses route to the NY based vendors first and Seattle IP addresses route to the Seattle based vendors first.

To implement just make sure the ‘Contact EP Tags Prefs’ on the inbound endpoint matches the ‘Tags’ field on the outbound endpoint. In other words:

This setting will be applied before the Priority setting, so it is possible to mix and match between the two. RouteNGN users may also include the Max Contact Endpoints setting to further refine the routing rules.

Another use case for Tags is isolating dialer traffic from conversational traffic. The ability to tag dialer traffic will help to protect conversational traffic from the inherent and unpredictable fluctuations in dialer traffic volume. Furthermore, by utilizing the randomizing feature of endpoints with the same priority, the traffic may be evenly spread across multiple termination nodes.