Monitoring dialogic boards


Developer Group

Developer Group
Connect with thousands of other developers to brainstorm ideas, share best practices and tips - or just chat about the latest emerging technologies making noise in the field. And of course, get the most up-to-date service and support news from Dialogic.
Dialogic SS7 and SIGTRAN Signalling

Monitoring dialogic boards

  • Hi all

    I want to develop a WELCOME SMS application that will monitor the ss7 link for any new subscriber and then send an SMS to that subscriber.

    im new at monitoring so can anyone please tell me , what boards can i use?what lisences will i need?

    can i use the same board for monitoring and signalling?

    on the application development side , what will i need to know ? any documentation?what are the messages that i will receive from the monitor?

    thx in advance
  • There is an appendix in the SS7HD Programmer's Manual that describes how to program the board for passive monitoring. There is a specific license to allow monitoring. The SS7HD can be a normal board or passive monitoring, but of course a port can only do one of these things at a time.

    In passive monitoring mode, you will get a flow of MTP packets, and it is up to your application to filter these in order to process the packets you are interested in. In your case you'll be looking for MAP packets, for example when the MSC sends a location update to the HLR.
  • Hi alaash,

    Here is an application note. FYR


  • Hi Martyn and MA527

    thx for ur reply , what i need to know is that can i use the ss7 protocol stack modules provided by dialogic to get the MAP message ?

    as i understood , the monitoring catches the packets , it is sent to the user's application through a API_MSG_RX_IND message. what i need to know , is that when receiving this message will i have to decode it to find the MAP message i need, or can i use the protocol stack used in MTU and MTR in order to decode this message to a MAP message (like in MTR)??

    if i cant use the stack , how can i decode this MTP2 message?are there any documentations?

  • alaash - 2008-08-12 06:00

    ... when receiving this message will i have to decode it to find the MAP message i need, or can i use the protocol stack used in MTU and MTR in order to decode this message to a MAP message (like in MTR) ...

    Yes, you have to decode it yourself. The higher-level modules (like our TCAP and MAP) won't decode packets received in monitoring mode.
  • are there any documentations about the decoding of such messages?

    is there any samle application?

  • There isn't a very relevant sample that you can follow I'm afraid. I haven't built this solution myself, but I imagine that the way to do this is to look at the SIO field in (in the MTP header) which will allow you to filter packets that are being sent to SCCP. Then you can locate the SSN field, for example this would be 8 for messages to/from the MSC, 6 for HLR etc. This should get you to the relevant messages.
  • Ok thank you Martyn , this gave me a start
  • Hi

    Is there any document that i can use in order to decode the MTP message when using monitoring mode?

    I want to decode the message in order to find the relevenat MAP message recevied, but i am finding a hard time finding any document about the format of such MTP messages.

    Are there any documents or sample codes that might help?

    Best Regards,


  • Hi Alaa

    1) Basically you need to open a thread that uses GCT_GRAB to get the messages

    2) Once a message is recieved , you need to check for the SIO if it is =3 or not , you can use the following  {if ((pBytes[3] & 0x0f )== 0x03) ' SCCP message }

    3) After that you decode the message cgPA , cdPA and Data , you have to decode each part , or at least move with your pointer index until you reach the dialogue-portion to check the opereation type .


    If you are building a welocme sms , you can not only depend on LU or CL , you have to have a statemachine to track if the operation of location update is sucessful or not -specially that SOR is now a typical practice .


    I can not share code here , but i am sure you can do it , it is a simple MSU decoding


    By the way . do not depend only on SSN  value to filteration of your messages ... at least do not depend only on 6,7 & 8 .





  • Thx for the reply khalid,

    I already done the part concerning the SIO Field, but my question is how to get the MAP message type and its parameters from the MSU, since i dont really know the format of a MTP message.

    Concerning the cgPA, cdPA , are they decoded normally as i would decode them in a MAP message?

    do you have any documents concerning the format of the MTP message so that i can decode them quicker?

    thx again Khalid

    Best Regards,

  • Will do send you a guideline that will be helpful for people facing the same problem , give me sometime . I am in a middle of an aggressive race with time here :)
  • Hello Alaa


    Acutally when I built a parser for the monitoring module , it was one of the good practices to understand MSUs of MAP

    You will start the decoding from index 3 (omitting the MTP Labels )


    You have to handle 3 parts

    1)      SCCP routing labels decoding

    a.       CdPA starts at index of value of byte[7] +7

                                                                   i.      Examine  byte[cdPA index ]  value  to see if the cdpa contains SSN , PC and GT .

    1.      If bit 6 =1 , then routing will use GT / SSN combination

    2.      bit 0 tells you if you have PC in address

    3.      bit 1 tells you if you have SSN in address

    4.      bits 2-5 tells you the  global title  indicator

    5.      GT can be deduced by using twisted nipples algorithm  and guidelines in Q713 document .

    6.      Don’t take into account only SSN values of 6 ,7 or 8 , some times you might recive INAP_ETSI not MAP_ETSI SSN codes ( usually this will happen from the same operator ) .  


    b.      CgPA starts at index of value of byte Music +8

                                                                   i.      Decoding is similar to CdPA above

    c.       Data  starts at index of value of byte [9] +9

    2)      TCAP decoding

    a.       The  byte [Dataindex ] byte tells you what is the Transaction type (BEGIN 0x62 , CONTINE 0x65 ,END 0x64 and abort 0x67  )

    b.      From now on everything goes in TLV scheme  (Tag ID or Type , Length & Value/parameter )

                                                                   i.      Dialogue TAG ID (0x6b)

                                                                 ii.      OTID TAG ID (0x48)

                                                                iii.      DTID TAG ID (ox49)

                                                               iv.      COMPONENT TAG ID ( 0x6c)

                                                                 v.      The application context-name can give you an indicator of the operation type if you do not want to go down to MAP

                                                               vi.      Application context name is not always present , so do not depend on it to get the operation type in case of INVOKES

    c.       The TCAP invoke type tells you if it is a

                                                                   i.      INVOKE 0xa1

                                                                 ii.      RETURN RESULT  0xa2

                                                                iii.      RETURN ERR  0xa3


    3)      MAP decoding

    a.       MAP decoding starts from the Component tag id

    b.      You might have multi-components

    c.       The operation type tells you what the is the operation (Location update , CL , SRI , SRISM , RESET , ALERT-SC, READY-FOR-SM , REGISTER-SS, etc )

    d.      Take care of extended length indicators 0x81 as per ASN 1 standards

    e. Based on the operation type , you start look for tags of parameters and decode them accordingly , you will have to refer the the MAP starndard and mandatory / optional parameters per operation type .

    If you built the parser function , and in can be built within 1 day if you understand the principles above , i can verify it to you , also once you can do TCAP decoding and understand the TLV scheme , it will become an easy task , it will be mainly to read bytes and memcpy ranges of parameter value , decoding / formatting them and filling the structure of the operation

    In General , LU cdPA comes  in E214 formats , sometimes it comes in E164 format .

    This is a generic description of how to decode MSUs specially of MAP ....

  • Thx Khalid

    Now its way more clear.


  • Hi Alaa,

    Have you developed your welcome SMS application ?

    i also have to developed this application.

    but i don't know how to monitor the traffic from the existing link ?

    i am not able to get the messages on my monitoring server from the existing link on which IS41 traffic is flowing.

    kindly tell me.


    Vishal Dhingra