Using wildcard translations
Symptom:
There may be a need to configure the Dialogic Integrated Media Gateways so that incoming calls with a specific Dialed Number and Nature of Address indicator can have a prefix added to the Calling Party Number.
{All screenshots in this article were taken using ClientView and an IMG 1010, but apply equally to the IMG 2020 when viewing the corresponding panes in the WebUI.}
Â
Reason for the issue:Â
In some international interworking scenarios, carriers must add a country code prefix to an originating number, based upon the Dialed Number and the Nature of Address.
Â
Solution:Â
With IMG 1010 software 10.5.3 and later, and in all IMG 2020 software 2.2 releases there is a new wildcard character: the dollar, $. Â
The dollar wildcard enables you to match on one parameter and at the same time translate a different parameter. Â
In addition, parameters can be swapped in order to preserve the original value of one parameter while manipulating another parameter. Â
So, in the above scenario, an incoming translation entry can use Dialed Number and NOA on 'String to Match' Â and store the Originating Number with an added prefix.Â
Â
Ideally, the Originating Number would replace itself - with the added prefix - but due to a limitation in this new feature, the Originating Number with the prefix has to be stored temporarily in the Generic Number field.Â
 Â
In order to replace the Originating Number two translation table entries are therefore required to operate in series using 're-run'.
 Â
The first translation table entry looks like this:
Â
Any Dialed Number starting with 8 will be selected for translation.Â
There is no NOA match in the screenshot, but there could be to further limit the matching properties.
After the Dialed Number is matched, the Originating Number is stored in the Generic Number field, which was null in the incoming call. Â
The $O represents the Originating Number as received from the network, the 49 adds the prefix. Â
The Originating Number is translated to the Generic Number, in this case null, so that on the second pass,the Generic Number can be 'restored' to what was received from the network. Â Â
Setting the Re-Run Option to Generic Number will force a second translation, using Generic Number as the 'String to Match'.
The second (re-run) entry looks like this:
Â
Only Generic Numbers with a 49 prefix will be selected for translation.Â
By setting the Originating Number Translation property to $G, the originating number will now contain the 49 prefix.Â
The Generic Number will revert to its original value.
 The complete Incoming translation will be displayed as follows in the call trace:
Â
19:51:50.716 CALL(GCL) (01:00018:00) DPE Input :DN=[8576] ANI=[3333] GN=[]
19:51:50.716 CALL(GCL) (01:00018:00) DPE input plus(+) sign mask 0x00000000
19:51:50.716 CALL(GCL) (01:00018:00) Invoke Incoming DPE 14; Channel Group 7
19:51:50.716 CALL(GCL) (01:00018:00) DPE response: Proc Complete
19:51:50.716 CALL(GCL) (01:00018:00) DPE Output:DN=[8576] ANI=[493333] GN=[]Â Â
 Â
To summarize the logic of the above sequence:
Â
1.  If DN starts with 8
a. ON gets GN
b. GN gets 49 and ON
c. If GN starts with 49
i. ON gets GN
ii. GN gets ON
Â
ON = Originating Number
GN = Generic NumberÂ
Â
Alternative solution:
In some scenarios it may be possible to use a combination of incoming and outgoing translation tables; however, this may lead to undesirable side effects and the technique described here may be preferred.Â
Product List
Dialogic IMG 1004 Integrated Media Gateway
Dialogic IMG 1010 Integrated Media Gateway
Dialogic IMG 2020 Integrated Media Gateway (IMG 2020), formerly referred to as Dialogic BorderNetâ„¢ 2020 Session Border Controller