In the last entry we worked with a Basic LRT that modified a test TFN number to be routed to an internal number. This new scenario will apply an LRT to apply different routes to session agents.
To accomplish this, we will create a new “internal” connection (with all the configuration needed to have this realm working – phy-interface, network-interface, realm-config, sip-interface, steering-pool and cloning an ubuntu VM) that help us to have different routes for different calls, this is a graphical representation:
Before proceeding with more detailed info and config, lets define the testing cases we will be working on:
Test case 1: Call to 8001234567 is received in the External realm interface, using LRT configuration route is called to the Internal realm, number will be modified to the internal client to the last 7 digits 1234567.
Test case 2: Call to 8337654321 is received in the External realm interface, using LRT configuration route is called to the Internal_101 realm, number will be modified to the internal client to the last 7 digits 1234567.
With this in mind, lets define all IP addressing that will be used in this environment:
To simplify this entry, cloning and administration of the new Ubuntu VM required in this environment is not included.
Let’s start adding the following config:
- phy-interface
2. network-interface
3. realm-config
4. sip-interface
5. steering-pool
6. session-agent
The importance of having a session-agent associated with the internal endpoints is due to the fact that the local-policy needs to be open to route to any realm (having the realm setting in the policy-attribute set to blank, will see this later).
Changes made up to this point have not included routing changes, lets start with that phase now creating the LRT that will take care of this:
After creating the xml file, the .gz file is created and uploaded, if need more details please visit the previous entry for the Basic LRT configuration. The proper configuration for the local-routing-config is as follows:
With the LRT setup and file loaded, entries can be verified:
Now, lets apply the LRT in the local policy and made some testing, all other local-policies will be removed and a new one is created to be specific for this testing:
Lets start testing… From a first view in the “Monitor and Trace” web menu, it can be see the correct routing when dialing the numbers:
But lets verify the traces and confirm the changes in the Request URI in the final INVITE sent…
Case 1
Case 2