Dialogic Service Center

Service Contracts

Technical Helpweb

Downloads

Contact Support

Developer Forums

Training

Service Center Logon

Downloads

Product pages

For Developers

Resources

Contact Dialogic Support

Other downloads

Useful links

 

Technical Helpweb

Dialogic® Distributed Signaling Interface (DSI) - Signaling and SS7 Products

Global Title Translation with Masks

The Dialogic® DSI SCCP Programmer's Manual describes two modes of operation for Global Title (GT) translation, the Base Algorithm and the Extended Algorithm.  The former is used by many customers; the latter is very powerful but complex.   

This article includes a revised version of the Extended Algorithm sample in the DSI SCCP Programmer’s Manual and provides a working configuration that users can try.

This is the example that we will work with:
Address to translate:         1234567
Target (SCPPN_TARGET_ADDR):   123E00E51
Primary (SCPPN_PRIMARY_ADDR): 56EE89
Mask (SCPPN_GTT_MASK):        0E2E1

The 'E' is a marker that is used to subdivide the number into parts; in this case the addresses (and mask) have been split into three sections so that different rules can be applied to each section.  This example allows us to match numbers by comparing part 1 with the target, extract interesting digits from part 2 of the incoming number, and then combine parts 1 and 3 of the primary number with part 2 of the incoming number.  The 'E' In the string is represented as a 4-bit number 1110, or 'E' in hexadecimal.

Q.713

In the Dialogic® DSI SCCP API, addresses are encoded in the format defined in the ITU-T document Q.713.   The Q.713 document may be downloaded from www.itu.int (note: Dialogic is not responsible for the content of third party web-sites);  the relevant section 3.4 can be found by searching for 'Called Party'.  Q.713 allows not just the encoding of the dialed digits themselves (in nibble-swapped packed decimal format), but also other parameters like Nature of Address (National/International), Numbering Plan, Pointcode and Subsystem.

Overview

To configure the GT table, we need to send the "Add Translation Request" message to SCCP, SCP_MSG_GTT_ADD.  This message has up to four parameters:
   SCPPN_TARGET_ADDR, i.e. the 'input' for the translation
   SCPPN_PRIMARY_ADDR, the 'output' after the translation
   SCPPN_BACKUP_ADDR, an optional second output
   SCPPN_GTT_MASK, an optional mask, to allow wildcard processing

Simple 'A to B' translations can be achieved by specifying only the target and primary parameters.  However, if there are a number of similar translations required, the number of separate rules can be reduced by using the mask parameter.  For example, if you wanted all numbers that started 90nnn to be translated to equivalent geographic numbers +441628641nnn, then this can be achieved using a mask.

Once we have successfully sent the SCP_MSG_GTT_ADD, and our translation entry is in the GT table, we can test that the translation is working by sending in numbers using the "Test Translation Request" message, SCP_MSG_GTT_TEST.  This message has only one parameter, a number in Q.713 format (coded as a parameter SCPPN_CALLED_ADDR), and the result that comes back from SCCP will contain the translated number.  (Note: if the number cannot be translated by the current translate table, you get a status of 0xFF, or 'sff' in the s7_log trace).

In the current example, we send 1234567 in the SCP_MSG_GTT_TEST, and this will match the 123* of the target.  The mask then selects the central part of the 1234567 and inserts it into the primary (56*89) number, so that we get 564589 as the output.


Coding the Parameters

1. SCPPN_TARGET_ADDRESS

So the target address is 123E00E51 and we can encode this using the SCPPN_TARGET_ADDRESS parameter:

The number itself is in packed decimal (BCD) and will be 21 E3 00 5E 01 (9 digits, and therefore odd). Encoding this using Q.713 gives: 
  06 08 83 21 E3 00 5E 01
 
  06 = Address Indicator -> RI=0, Routing on GT
  GTI=1, Nature of Address (NAI) field only
  SSNI=1, SSN field follows
  08 = Subsystem Number (SSN)
  83 = NAI field. top bit set means an odd number of digits to follow
          lowest 7 bits = NAI, 3 for 'national significant'
   21 E3 00 5E 01 = address digits, as already shown
 

The address field is 8 bytes in total, so to express it as a parameter (for the GTT add) we prefix 08 (for SCPPN_TARGET_ADDRESS) followed by length 8:
 08 08 46 08 83 21 E3 00 5E 01

2. SCPPN_PRIMARY_ADDRESS

The primary address is also encoded in Q.713, so we start with 56 EE 89 and give it the same treatment as above:

07 02 01 08 03 65 EE 98

  07 = AI (RI=1, GTI=1, SSNI=1)
  02 01 = pointcode (258)
  08 = SSN
  03 = NAI (national significant), top bit is zero for even no. of digits to follow
  65 EE 98 = digits 56 EE 89

To turn this into a parameter, we add 09 (SCPPN_PRIMARY_ADDRESS) and length field (8):
09 08 07 02 01 08 03 65 EE 98

3. SCPPN_GTT_MASK

Finally, we need the mask, which is coded as 0E2E1 in this case. We simply need to swap the pairs of digits to turn this into packed decimal: E0E201, then prefix with1C (SCPPN_GTT_MASK) and length 3:
 1C 03 E0 E2 01

The meaning of the mask is quite complex, and readers should refer to the section about this in the Dialogic® DSI SCCP Programmer's Manual.  In this case, the mask says that there are three parts to the number.  The first part (coded 0) means that we want an exact digit match with the target.  The second part (coded 2) is a wildcard, where we don't care what the digits are but want them copied to the result.  Finally the third part (coded 1) is again a wildcard, but in this case we want to copy digits from the primary to the result.


Building the Add Translation Request Script

Now we're ready to build a script (for s7_play) to do the GTT add, using SCP_MSG_GTT_ADD (0x7745).

The parameter field consists of the three parameters defined above, concatenated with a final '00' added to mark the end of the parameter list:

08 08 46 08 83 21 E3 00 5E 01 -> target
09 08 07 02 01 08 03 65 EE 98 -> primary
1C 03 E0 E2 01 -> mask
00 -> end of parameter list

This becomes: 
 p080846088321E3005E010908070201080365EE981C03E0E20100

So we can now build the '7745' message that we can send with s7_play:
M-t7745-i0000-fef-d33-r8000-p080846088321E3005E010908070201080365EE981C03E0E20100 

When we play this with s7_play, we should see something like this in the s7_log (or on the gctload screen):
S7L:I0000 M t3745 i0000 f33 def s00 p080846088321e3005e010908070201080365ee981c03e0e20100

So the 's00' tells us that the command was accepted and the translation is now active.  If you get 's06', this is because you have formatted the parameter string incorrectly in some way.  The '3745' message type is because it is a confirmation to '7745', i.e. the confirmation messages have the 0x4000 bit zeroed.

If this has worked correctly, you can then go on to test the translation.


Testing the Translation

To test whether the translation is working, we can also create a GTT test message, using SCP_MSG_GTT_TEST (0x774c).     

The parameter field for the 774c is a test address that we want to send in to SCCP;  in this case the test address is 1234567, which, in packed decimal, codes as 21 43 65 07.  Once again, it needs to be coded using Q.713:

  46 08 83 21 43 65 07
 
     46 = AI, RI=route on SSN, GTI=1 (NAI only), SSNI=1
     08 = SSN
     83 = NAI (odd no. of digits, national significant)
     21 43 ... address digits
 

This needs to be coded as SCPPN_CALLED_ADDR (05) with a length of 7:
 
    05 07 46 08 83 21 43 65 07
    00  -> extra zero to end parameter list
   
So the test script becomes:
M-t774c-i0000-fef-d33-r8000-p05074608832143650700


When we run this script, we should see this on the s7_log (gctload) screen: 
S7L:I0000 M t374c i0000 f33 def s00 p0508070201080365549800

Message type is '374c', as this is a confirmation to '774c' (0x4000 bit is flipped), and the status is zero (s00), which means success.  We can decode this as follows:

  05 = SCPPN_CALLED_ADDR
  08 = length 8
  data = 0702010803655498 (Q.713 address string)
  00 = end of parameters

Decoding the address string (using Q.713) we get:
   Address Indicator = 07  (route on SSN, GTI=NAI only, SSN and PC present)
   02 01 = pointcode 0x102 (258)
   08      = SSN 8
   03      = NAI (national significant number)
   65 54 98 = address digits -> 564589

So this is the expected translation.  The 56*89 is the primary, and the '45' has been extracted from the input number and inserted into the result.

To show the wildcard in operation, we can change the number to 1230067, which gives the result:
S7L:I0000 M t374c i0000 f33 def s00 p0508070201080365009800

The translated digits (650098) come out as 560098, i.e. the central '00' digits have been taken from the input address.

If we change the number to 1239999, we get this:
S7L:I0000 M t374c i0000 f33 def s00 p0508070201080365999800

The translated digits (659998) become 569989.


Failure Codes

If the status is not zero, then the operation has failed.  Status 06 (s06) means that there is a formatting (syntax) error in your command.  More interestingly, status 0xFF (sff) means that the translation failed; that is: after looking through all the targets in the table, no match was found for your number.  For example if we change the test number to 9234567 and send the message again, we get this:
S7L:I0000 M t374c i0000 f33 def sff p05074608832943650700

There's no match for '923*' numbers in the table, so the lookup fails.






Feedback

Please rate the usefulness of this page:  
0 - not useful at all
1 - potentially useful
2 - quite useful
3 - very useful
4 - exactly the information I needed     

Please enter a comment about this page: