Project

General

Profile

Actions

ADML (obsoletes ADL)

Introduction

ADML is acronym for ANNA Diameter Multirealm Launcher, that is to say, the diameter "launcher" based on ANNA suite, specifically its diameter module (A-Diameter). Anyway you could use the diameter API to create your own agents, but this is probably many work to achieve the same level of capabilities.

The name "launcher" may not do justice to its multifunctionality, but somehow no longer be an interface node that provides diameter connectivity and facilitates interaction and generation of messaging in that protocol, thus, the diameter launch and redirection messaging. You could use ADML to simulate nodes. For example emulating a GGSN node just by adding basic implementation of the functionality of that node. Are the scenarios and orchestration / coordination of messages, which brings us to the idea to emulate or simulate a GGSN or anything else. You can do everything with ADML.

The ADML provides capabilities for:

  • Test automation: component test (CT), function test or end to end (FT), load test or system test (ST)
  • Burst engine for performance tests: throttling like h2load for http2, but goes beyond because ADML could control amount of OTA messages to test congestion control easily
  • Advance balancing, redirection, and system failover for high availability tests in any environment with diameter interfaces.

ADML has a very large configuration flexibility to allow integration with any diameter system and ability to test complex or improbable settings which should be considered in certain functional testing scenarios. To give a closer view of their potential, we will start by describing deployment and configurability:

Quick installation

The easier way to get started with the process consists in execution of script example/diameter/launcher/deploy.sh from the git repository. With this procedure you could choose advanced or basic deployments (recommended for beginners) and also a function test client. Once installed, read the README file and follow the instructions. In few minutes you will launch clients, servers, or balancers, and connect them. You can also install the suite (sudo scons install, sudo scons install-example, etc.).

myuser@myhostname:~/ADML-basic$ example/diameter/launcher/deploy.sh 

---------------------------------------
Anna Diameter Launcher (ADML) deployment
---------------------------------------
 (--help or -h for more info)

Basic checkings ...
Variant: Release

Deploy one of these versions:

 (a)dvanced version:     includes burst management script and templates for different scenarios. Automatic configuration during start.
 (b)asic version:        4 types of launcher (client, server, balancer, dummy), lightly configured and managed through SIGURS2 method.
 (f)unction test client: special client with regexp scheduler script based on splitted traffic logs. Requires a server to perform the tests.
 (s)ystem test client:   special client for stress testing. Requires a server/s to perform the tests.

Input option [b]:

Basic deployment

Input deployment path [/home/myuser/ADML-basic]:

Copying to '/home/myuser/ADML-basic' ...
Default stack dynamic generation ...
Done !
(see README at '/home/myuser/ADML-basic')

myuser@myhostname:~/ADML-basic$ cd /home/myuser/ADML-basic

myuser@myhostname:~/ADML-basic$ ./configure.sh 

Configure a (c)lient, (s)erver, (b)alancer or (d)ummy [c]:
d

Enable debug traces ? (y/n) [n]:

Strict xml for decoded messages ? (y/n) [y]:

Created 'run.sh' script !

myuser@myhostname:~/ADML-basic$ ls
ADML        DTDs    clone.sh      counters        dynlibs       operation.sh  services      stack_examples  tinyTestcase.sh
ADML-basic  README  configure.sh  dictionary.xml  hex_examples  run.sh        services.xml  test-reports    xml_examples

myuser@myhostname:~/ADML-basic$ cat run.sh 
#!/bin/bash
cd `dirname $0`
STARTED=`pgrep ADML-basic$ 2>/dev/null`
[ $? -eq 0 ] && { echo "Already started!"; echo "$STARTED" ; exit 1 ; }
0> launcher.trace
rm -f counters/* test-reports/*
# Execution line:
export LD_LIBRARY_PATH=$PWD/dynlibs
./ADML-basic --cntDir counters --tmDir test-reports --services services.xml &
echo $! > .pid

You have also deploy-setups.sh (complete layouts) and an Agents-Oriented deployment by mean deploy-aots.sh. Anyway, you could execute deploy.sh as many times you need to deploy, for example, a server, then a client to connect to the former server.

Multistack configurations

As you can see in the basic deployment, we have a services.xml file where the stacks are defined:

myuser@myhostname:~/ADML-basic$ cat services.xml 
<services>
  <!-- Stacks -->
  <stack id="0" dictionary="dictionary.xml"/>

  <!-- Nodes -->
  <node originHost="ADML-dummy" applicationId="0"/>
</services>

myuser@myhostname:~/ADML-basic$ ls DTDs/
dictionary.dtd  message.dtd  services.dtd

In the basic deployment, only basic stack with basic dictionary is deployed, but you could add as many stacks as you need (Rx, Sy, Gx, etc.).
At DTDs directory you will find the schema files to follow the services definitions as well as the diameter dictionaries referenced.
The messages schema is for testing configuration and will be studied later.

Many of the configuration features are expressed at services.dtd and also self-explained inside:

myuser@myhostname:~/ADML-basic$ cat DTDs/services.dtd 
<?xml version="1.0" encoding="UTF-8"?>
<!-- Diameter services DTD -->

<!ELEMENT services (stack*, node*)>

<!ELEMENT stack EMPTY>
<!ATTLIST stack id CDATA #REQUIRED dictionary CDATA #REQUIRED validationMode (BeforeEncoding | AfterDecoding | Always | Never) #IMPLIED validationDepth (Complete | FirstError) #IMPLIED fixMode (BeforeEncoding | AfterDecoding | Always | Never) #IMPLIED ignoreFlagsOnValidation (yes | no) #IMPLIED>
<!--
   Stack record

   id:                      Normally the id corresponds to the Application-Id for which the dictionary provided is designed
                            (in multistack applications, it shall be mandatory respect such association to know the stack used
                            for processed messages).
   dictionary:              Path to the dictionary file.
   validationMode:          Sets the validation mode. Default is 'AfterDecoding'.
   validationDepth:         Sets the validation depth. Default is 'FirstError'.
   fixMode:                 Sets the fix mode. Default is 'BeforeEncoding'.
   ignoreFlagsOnValidation: Ignore flags during message validation. Default is 'no'.
-->

<!ELEMENT node EMPTY>
<!ATTLIST node originHost CDATA #REQUIRED applicationId CDATA #REQUIRED originRealm CDATA #IMPLIED cer CDATA #IMPLIED dwr CDATA #IMPLIED cea CDATA #IMPLIED allowedInactivityTime CDATA #IMPLIED tcpConnectDelay CDATA #IMPLIED answersTimeout CDATA #IMPLIED ceaTimeout CDATA #IMPLIED watchdogPeriod CDATA #IMPLIED entity CDATA #IMPLIED entityServerSessions CDATA #IMPLIED diameterServer CDATA #IMPLIED diameterServerSessions CDATA #IMPLIED balance (yes | no) #IMPLIED sessionBasedModelsClientSocketSelection (SessionIdLowPart | SessionIdHighPart | SessionIdOptionalPart | RoundRobin) #IMPLIED retries CDATA #IMPLIED log CDATA #IMPLIED splitLog (yes | no) #IMPLIED detailedLog (yes | no) #IMPLIED dumpLog (yes | no) #IMPLIED burstLog (yes | no) #IMPLIED>
<!--
   Node record

   originHost:                              Node identifier as diameter application host name.
   applicationId:                           The Application-Id provided must exists as a registered 'stack id'.
   originRealm:                             Origin-Realm (domain-name internally used by default).

   - Diameter clients:

   entity:                                  Target diameter entity (comma-separated '<address>:<port>' format).
                                            For example: 10.20.30.40:3868,10.20.30.41:3868. If missing, no entity will be enabled.
   entityServerSessions:                    Diameter entity server sessions (0: diameter entity disabled). Default value of 1.
   cer:                                     User defined CER path file to be encoded to establish diameter connections.
                                            If missing, will be harcoded.
   dwr:                                     User defined DWR path file to be encoded for diameter protocol keep alive.
                                            If missing, will be harcoded.
   tcpConnectDelay:                         Milliseconds to wait TCP connect to any server. If missing, default value of 200 will
                                            be assigned
   ceaTimeout:                              Milliseconds to wait CEA from diameter server. If missing, default value of 'answersTimeout'
                                            will be assigned.
   watchdogPeriod:                          Milliseconds for watchdog timer (Tw) for diameter keep-alive procedure. If missing, default
                                            value of 30000 will be assigned.
   balance:                                 Balance over entity servers instead of doing standard behaviour (first primary, secondary
                                            if fails, etc.). Default value 'no'.
   sessionBasedModelsClientSocketSelection: By default, round-robin will be applied for IEC model (SMS/MMS), and Session-Id Low Part
                                            will be analyzed for ECUR/SCUR model (data, voice and content). You could change ECUR/SCUR
                                            analysis behaviour providing 'SessionIdHighPart', 'SessionIdOptionalPart' (atoi applied;
                                            usually subscriber id data, i.e. MSISDN or IMSI) and 'RoundRobin' (also 'SessionIdLowPart').

   - Diameter servers:

   diameterServer:                          Diameter own server address in '<address>:<port>' format. For example: 10.20.30.40:3868.
                                            If missing, no local server will be enabled.
   diameterServerSessions:                  Diameter own server available connections (0: diameter server disabled). Default value of 1.
                                            Negative value implies no limit accepting incoming connections.
   cea:                                     User defined CEA path file to be encoded to answer client CERs.
                                            If missing, will be harcoded.
   allowedInactivityTime:                   Milliseconds for the maximum allowed inactivity time on server sessions born over the
                                            local server before being reset. If missing, default value of 90000 will be assigned.

   - General:

   answersTimeout:                          Milliseconds to wait pending application answers from diameter peers. If missing,
                                            default value of 10000 will be assigned.
   retries:                                 Expired responses will cause a number of request retransmissions. Disabled by default (0 retries).
   log:                                     Process log file (operations result, traffic log, etc.). By default '<originHost>.launcher.log'.
                                            Empty string or \"null\" name, to disable. Warning: there is no rotation for log files
                                            (use logrotate or whatever you consider).
   splitLog:                                Splits log file (appends to log filename, extensions with the type of event: see help on
                                            startup information-level traces). No log files for code/decode and load operations are created.
                                            Default value 'no'.
   detailedLog:                             Insert detailed information at log files (timestamps, communication resources, etc.). Useful
                                            to analyze the messages flow along the sockets (specially on 'balance' mode). Default 'no'.
   dumpLog:                                 Write to disk every incoming/outcoming message named as:
                                               '<unix ms timestamp>.<originHost>.<hop by hop>.<end to end>.<message code>.<request|answer>.<type of event>.xml'
                                            Default value 'no'.
   burstLog:                                Burst operations log file. By default '<originHost>.launcher.burst'. Empty string or \"null\" name, to disable.
                                            Warning: there is no rotation for log files (use logrotate or whatever). Output: dot (.) for each
                                            burst message sent/pushed, cross (x) for popped ones, and order number when multiple of 1% of burst
                                            list size, plus OTA requests when changed.

-->

Command line

Also, command-line help is self-explaining. Like any ANNA process, is enough to run without arguments to get a detailed help for each of the possible options. As ADML needs dynamic libraries, it is probably easier to modify the ADML execution line in run.sh script:

From

./ADML-basic --cntDir counters --tmDir test-reports --services services.xml &

to

#./ADML-basic --cntDir counters --tmDir test-reports --services services.xml &
./ADML-basic &

Thus, this is what we get in the shell:

myuser@myhostname:~/ADML-basic$ ./run.sh 
Traces file ..................................: /home/myuser/ADML-basic/launcher.trace
Backup copy  .................................: /home/myuser/ADML-basic/launcher.trace.old
Files size (Kbytes) ..........................: 2000
Traces level .................................: Warning

launcher - DiameterLauncher. Version 1.1/ST/O/Linux 4.15 (x86_64)
(c) Copyright 2001-2006 Eduardo Ramos Testillano & Francisco Antonio Ruiz Rayo
                        eduardo.ramos.testillano@gmail.com & cisco.tierra@gmail.com
                        (project site: http://redmine.teslayout.com/projects/anna-suite)

Variable: 'services' is not valid

Usage: ./ADML-basic --services <value> [ --trace <value> ] [ --cntDir <value> ] [ --tmDir <value> ] [ --cntRecordPeriod <value> ] [ --logStatisticSamples <value> ] [ --disableLogs ] [ --reconnectionPeriod <value> ] [ --httpServer <value> ] [ --httpServerShared ] [ --ignoreErrors ] 
Where: 
   --services: 
     Services xml path file. Shall be validated against dtd schema written on warning traces: 'Services DTD schema'. Empty string or "null" name, to start without services (see help for management operation 'services').
   --trace: 
     Trace level (emergency, alert, critical, error, warning, notice, information, debug, local0..local7)
   --cntDir: 
     Counters directory. By default is the current execution directory. Warning: a counter file will be dump per record period; take care about the possible accumulation of files
   --tmDir: 
     Test manager directory. By default is the current execution directory. Warning: report files could be dump during system testing (see help for management operation 'test|report|result'); take care about the possible accumulation of files
   --cntRecordPeriod: 
     Counters record procedure period in milliseconds. If missing, default value of 300000 (5 minutes) will be assigned. Value of 0 disables the record procedure.
   --logStatisticSamples: 
     Log statistics samples for the provided comma-separated concept id list, over './sample.<concept id>.csv' files. For example: "1,2" will log concepts 1 and 2. Reserved words "all"/"none" activates/deactivates all registered statistics concept identifiers. That ids are shown at context dump (see help to get it).
   --disableLogs: 
     Overrides every node configuration regarding traffic log in order to disable it and ease production or system test startup.
   --reconnectionPeriod: 
     Milliseconds to recover diameter client-session when server connection has been broken. If missing, default value of 10000 will be assigned
   --httpServer: 
     HTTP Management interface address (using i.e. curl tool) in '<address>:<port>' format. For example: 10.20.30.40:8080
   --httpServerShared: 
     Enables shared bind for HTTP Management interface address. It would be useful i.e. to allow a great amount of curl operations per second
   --ignoreErrors: 
     Local server skips requests errors analysis which would prepare automatic answers for them when a problem is found. If no answer is programmed and entity is configured, a failed request would be forwarded (delegates at the end point) even if this parameter is missing

To improve explanation above, we will add some hints here:

Parameter [ --logStatisticSamples <value> ]

The ANNA::diameter module, cornerstone of this process, incorporates a statistical engine that measures two main concepts: server processing time and size of messages processed. If the process is started in client mode and connects to N servers, there will be 2 * N statistical concepts, recorded dynamically and automatically. The information collected (average, maximum, minimum, variance, etc.) is managed independently in these 2 * N instances. When performing the dump process context (you can see this example), we can see the statistical data along the elements in the diameter system. For example, for a certain server, we could see processing time:

<Concept Id="1" Description="Diameter processing time (for requests) at servers on zape-ocs2dfed1:3868" Unit="ms">
   <Data Size="445" Average="19.82" StandardDeviation="30.33" BesselStandardDeviation="30.37" ProcessingRate="16.48 vps (values per second)">
      <Minimum Value="8" Date="21/04/2012" Time="05:24:20" TZContext="Europe/Madrid" Isdst="yes" UnixTimestamp="1334978660" NtpTimestamp="3543967460" LocalTZ="Europe/Madrid"/>
      <Maximum Value="328" Date="21/04/2012" Time="05:24:33" TZContext="Europe/Madrid" Isdst="yes" UnixTimestamp="1334978673" NtpTimestamp="3543967473" LocalTZ="Europe/Madrid"/>
      <LastResetTimestamp Date="21/04/2012" Time="05:24:18" TZContext="Europe/Madrid" Isdst="yes" UnixTimestamp="1334978658" NtpTimestamp="3543967458" LocalTZ="Europe/Madrid"/>
   </Data>
</Concept>

The 'Processing Rate' is the number of data events processed per second. If the contexts are completed (otherwise it can not compute the concept of processing time and therefore can not add the measure on the statistical sample) is considered a new data processing (transaction concept). Thus, in the example we could talk about a traffic rate of about 17 messages per second on that server.

We will talk now about the parameter '-logStatisticSamples':

At the end of the xml file of the context dump we can see general information from statistics engine, specially the concepts registered for analysis. For example, suppose a diameter client connected to two diameter entity servers:

<Concept Id="1" Description="Diameter processing time (for requests) at servers on zape-ocs2dfed1:3868" Unit="ms" IntegerNatureSample="yes"/>
<Concept Id="2" Description="Diameter message sizes received from servers on zape-ocs2dfed1:3868" Unit="bytes" IntegerNatureSample="yes"/>
<Concept Id="3" Description="Diameter processing time (for requests) at servers on zape-ocs2dfed2:3868" Unit="ms" IntegerNatureSample="yes"/>
<Concept Id="4" Description="Diameter message sizes received from servers on zape-ocs2dfed2:3868" Unit="bytes" IntegerNatureSample="yes"/>

In the case shown, the concepts 1 and 3 seem the most interesting, because they give a picture of the processing time to assess progress, bottlenecks, or impact of certain actions on a given interface connection. Concepts 3 and 4 can be interesting in the stages of preliminary analysis for sizing queues face to configure congestion thresholds on certain systems. Suppose we are only interested in concepts of "processing speed" and discard the statistical information on the size of messages processed. In that case, we might launch the process passing -logStatisticSamples 1,3 which means that the sample data concerning such concepts will be dump on disk. You can specify 'all' to activate the dump in all statistical concepts assigned to the process.

The statistical engine does not store the sample data, since this would have a great cost in memory and performance. Statistics are calculated cumulatively (including Bessel variance by a convenient development in the formula). However, by configuration, we could activate dumps for every processed data to disk. The destination dump files have a fixed name that includes the identifier of the concept: './sample.<concept id>.csv'. Its contents are comma-separated and contains the unix timestamp followed by the processed value. For example, we could have the time sample processed with this:

1355186310124,90
1355186310526,92
1355186310862,29
1355186311271,38
1355186312103,70
1355186312148,115
1355186312490,57
1355186312905,71
1355186313343,110

If we've just generated these nine transactions, statistical data show a maximum of 115 in the timestamp "1355186312148". But what is clear is that by activating the dump can access the actual test data. This is mainly used for the preparation of charts and trends. For example, in a test failover to two servers hosted on two front-ends, we note that when the service goes down into one of them, processing times on the front-end survivor increase slightly.

Parameter [ --cntDir <value> ]

Directory where the process counters are written (if cyclic dump is enabled).
The execution directory is taken as default when this optional parameter is not provided.
The files are automatically created in the form:

-rw------- 1 edu HOME 367 jul 25 04:37 Counters.Pid31061.Date20140725.Time043706
-rw------- 1 edu HOME   0 jul 25 04:38 Counters.Pid31061.Date20140725.Time043806
-rw------- 1 edu HOME   0 jul 25 04:39 Counters.Pid31061.Date20140725.Time043906
-rw------- 1 edu HOME   0 jul 25 04:40 Counters.Pid31061.Date20140725.Time044006

Parameter [ --cntRecordPeriod <value> ]

Time in milliseconds for the recording period of the counters information. The default is set to 5 minutes. A zero value disables writing to disk.
Recorded content includes the recording interval (not including seconds in range precission) and counter data (identifier, value and description):

eramedu@myhostname:~/ADML-basic/counters$ cat Counters.Pid31061.Date20140725.Time043706
2014-07-25 04:37|2014-07-25 04:37|002004|0000016|diameter::codec oam module::AvpDecode__UnknownAvpWithMandatoryBit
2014-07-25 04:37|2014-07-25 04:37|002015|0000004|diameter::codec oam module::LevelValidation__FailedRuleForCardinality
2014-07-25 04:37|2014-07-25 04:37|002016|0000004|diameter::codec oam module::LevelValidation__FailedRuleForCardinalityLessThanNeeded

Parameter [ --httpServer <value> ]

This is an optional parameter that indicates the management server via HTTP. It is a key management interface to leverage the process, although there is another mechanism by mean signals. Dynamic configuration, control and real time monitoring, are part of the offered possibilities. There is a wide range of operations offered on this interface which we will detail in the later section "HTTP Management". With tools for direct invocation on the linux shell, such as the client _ curl _, we can control any operation we want to apply. In addition, provides a variety of scripts that simplify and facilitate the use of the interface to perform operations in the simplest possible way for this process.

The value for the parameter has the format <address:port>. For the address you can specify the IP or delegate to /etc/hosts or DNS to resolve a given name. The port value is good to be 9000, 8000, etc.

Parameter [ --httpServerShared ]

By default, the HTTP interface listens exclusively, so that while a client is connected to send an operation, listening is not available for new connections. Enabling this parameter allows the shared interface and virtually unlimited operational use. Usually the operations are very fast in practice and non-exclusivity is not required. In performance tests with a single instance (which also must be aware that perhaps is not the most appropriate way) there is an operation called "burst sendXS" providing the number of messages per second that you want to generate. The script invokes the atomic operation "send" on a list of requests which ADML process loaded in memory, the number of times indicated per second. As we use the curl command, must take into account that makes the connection, sends the http message and then closes. That is done N times per second. When the number is very high for a single instance (and this depends on many factors), say 50 tps, it may happen that a customer enters a conflict with another (since it launched in background from script that would otherwise be slower). With the method of sharing listening (relay unix file descriptor of the connection) such a conflict will not occur. In any case, as we noted earlier, the most recommended way to inject charge is launching multiple instances of the process, for example a 10 tps each would be 5, and 10 transactions per second does not really offer any problems for the script or for the http client. The operation for traffic load at a given rate is based on a feedback cycle to recalculate in real time the number of milliseconds of delay between a shipment and the next. When the rate is very high, that period tends to zero and may even indicate reached in HTTP operation that sent more than one message no asynchronous manner, in order to "recover" delays and maintain the average rate for required shipment. All this complexity is determined on the scripts and through the operation interface.

Parameter [ --ignoreErrors ]

The ANNA::diameter stack optionally builds an automatic response to the case of anomalies in the analysis of a request. AVPs as the Result-Code, Failed-AVP, etc. are built transparently during decoding and/or validation of the request. The answer is completed in accordance with standard RFC 6733 Section 6.2.

The ADML process can be configured using this parameter to ignore this analysis and answer accordingly from the side of local server based on the programmed responses. Under normal conditions (absence of this parameter), when an ADML in server mode receives an incorrect request will automatically respond with the basic information indicating the detected error. This would happen even if there is scheduled responses, to avoid inconsistencies (correct programmed response to a request that could be wrong), but you can always set this parameter to prioritize responses map of internal programming. In the case of having a client side (entity configured), requests are forwarded regardless of quality, ie no protocol analysis is performed delegating this task to the remote end point:

[sent2e]
<message version="1" name="AA-Request" application-id="0" hop-by-hop-id="0" end-by-end-id="0">
   <avp name="Session-Id" data="ocs3;1332909618;0;1332909618"/>
   <avp name="Auth-Application-Id" data="16777236"/>
   <avp name="Origin-Realm" data="OCS3"/>
   <avp name="Destination-Realm" data="PCRF"/>
   <avp name="Subscription-Id">
      <avp name="Subscription-Id-Type" data="15"/>
      <avp name="Subscription-Id-Data" data="606024200"/>
   </avp>
</message>

[recvfe]
<message version="1" name="AA-Answer" application-id="0" hop-by-hop-id="0" end-by-end-id="0">
   <avp name="Session-Id" data="ocs3;1332909618;0;1332909618"/>
   <avp name="Origin-Host" data="ocs2dfed1"/>
   <avp name="Origin-Realm" data="(none)"/>
   <avp name="Result-Code" data="5005" alias="DIAMETER_MISSING_AVP"/>
   <avp name="Failed-AVP">
      <avp name="Origin-Host" data/>
      <avp name="Subscription-Id-Type" data="15"/>
   </avp>
</message>

This parameter is also very useful when it is not known a priori stack to implement, but you want to program behavior responses to certain requests according to a pcap of production, that is, when you want to mimic flow captured for a particular scenario. Normally the battery is fully configured to facilitate tracing and interpretation of traffic, but if not known, the simulator can work perfectly abstracting the meaning of the received message and relaying on the hexadecimal content that has been programmed. It is sufficient to obtain the raw messages and decode them to get the xml representation that is more or less understandable in terms of the completeness of the application part in the dictionary definition.

Traffic log example

This is an example of a traffic log for old ADML process configured as proxy balancer of SMS traffic:


---------------------------------------------------------------------------------------------------------------------------------------
[recvfc] 10/12/2012 10:46:45 Europe/Madrid, isdst = 0 [Unix Timestamp: 1355132805, Ntp Timestamp: 3564121605], Local TZ = Europe/Madrid
---------------------------------------------------------------------------------------------------------------------------------------
<message version="1" name="Credit-Control-Request" p-bit="yes" application-id="4" hop-by-hop-id="1" end-by-end-id="1">
   <avp name="Session-Id" data="gbg.acision.com;421411;1000"/>
   <avp name="Origin-Host" data="gbg.acision.com"/>
   <avp name="Origin-Realm" data="SMSC.orig.OCS2.o2online.de"/>
   <avp name="Destination-Realm" data="SMSC.dest.OCS1.o2online.de"/>
   <avp name="Auth-Application-Id" data="4"/>
   <avp name="Service-Context-Id" data="8.6.0.07.262.8.32274@3gpp.org"/>
   <avp name="CC-Request-Type" data="4" alias="EVENT_REQUEST"/>
   <avp name="CC-Request-Number" data="1"/>
   <avp name="Destination-Host" data="OCS1"/>
   <avp name="Event-Timestamp" data="1"/>
   <avp name="Subscription-Id">
      <avp name="Subscription-Id-Type" data="0" alias="END_USER_E164"/>
      <avp name="Subscription-Id-Data" data="5555100000"/>
   </avp>
   <avp name="Requested-Action" data="0" alias="DIRECT_DEBITING"/>
   <avp name="Multiple-Services-Indicator" data="0" alias="MULTIPLE_SERVICES_NOT_SUPPORTED"/>
   <avp name="Multiple-Services-Credit-Control">
      <avp name="Requested-Service-Unit">
         <avp name="CC-Service-Specific-Units" data="1"/>
      </avp>
      <avp name="Service-Identifier" data="1"/>
   </avp>
   <avp name="Service-Information">
      <avp name="MMS-Information">
         <avp name="Originator-Address">
            <avp name="Address-Type" data="1" alias="MSISDN"/>
            <avp name="Address-Data" data="5555100000"/>
            <avp name="Address-Domain">
               <avp name="3GPP-IMSI-MCC-MNC" data="26207"/>
            </avp>
         </avp>
         <avp name="Originator-Address">
            <avp name="Address-Type" data="6" alias="Other"/>
            <avp name="Address-Data" data="262075555100000"/>
         </avp>
         <avp name="Submission-Time" data="3486294858"/>
         <avp name="Message-Size" data="4"/>
      </avp>
      <avp name="SMS-Information">
         <avp name="SMS-Node" data="3" alias="SMS-SC"/>
         <avp name="Client-Address" data="8|541760000405"/>
         <avp name="Originator-SCCP-Address" data="8|541760000005"/>
         <avp name="Originator-Received-Address">
            <avp name="Address-Type" data="1" alias="MSISDN"/>
            <avp name="Address-Data" data="5555100000"/>
            <avp name="Address-Domain">
               <avp name="3GPP-IMSI-MCC-MNC" data="26207"/>
            </avp>
         </avp>
         <avp name="Recipient-Info">
            <avp name="Destination-Interface">
               <avp name="Interface-Id" data="5417607020601"/>
               <avp name="Interface-Type" data="2" alias="MOBILE_TERMINATING"/>
            </avp>
            <avp name="Recipient-Address">
               <avp name="Address-Type" data="1" alias="MSISDN"/>
               <avp name="Address-Data" data="5417607020601"/>
               <avp name="Address-Domain">
                  <avp name="3GPP-IMSI-MCC-MNC" data="26207"/>
               </avp>
            </avp>
            <avp name="Recipient-Address">
               <avp name="Address-Type" data="6" alias="Other"/>
               <avp name="Address-Data" data="262074900005771"/>
            </avp>
            <avp name="Recipient-Received-Address">
               <avp name="Address-Type" data="1" alias="MSISDN"/>
               <avp name="Address-Data" data="5417607020601"/>
               <avp name="Address-Domain">
                  <avp name="3GPP-IMSI-MCC-MNC" data="26207"/>
               </avp>
            </avp>
            <avp name="Recipient-SCCP-Address" data="8|541760000005"/>
         </avp>
         <avp name="SMSC-Address" data="8|541760000405"/>
         <avp name="Data-Coding-Scheme" data="0"/>
         <avp name="SM-Message-Type" data="0" alias="SUBMISSION"/>
         <avp name="Originator-Interface">
            <avp name="Interface-Id" data="262074900005771"/>
            <avp name="Interface-Type" data="1" alias="MOBILE_ORIGINATING"/>
         </avp>
         <avp name="Number-Of-Messages-Sent" data="1"/>
      </avp>
   </avp>
   <avp name="CC-Correlation-Id" hex-data="6762672e61636973696f6e2e636f6d3b3432313431313b31303030"/>
</message>

Used resource
-------------
diameter::comm::ServerSession { Timer { timex::TimeEvent { Id: 0x9b4ba40 | Reference: 0x9b4ba40 | Timeout: 90000 ms } | Name: Diameter Inactivity Detection Timer } | Socket Id: 4 | State: Bound | OnDisconnect: WaitPendings | Next Hop by hop: 1888494197 | Next End to end: 4138298175 | OTA requests: 0 (idle) | Last Incoming Activity Time: 1355132805247 ms | Last Outgoing Activity Time: 1355132778004 ms | Timeout for ClassCode 'Bind': 10000 ms | Timeout for ClassCode 'ApplicationMessage': 10000 ms | Parent Local Server: 192.168.1.55:3868 | Client Socket: comm::ClientSocket { comm::Socket { Domain: Inet | Type: Stream | comm::TransportFactory { Name: diameter::comm::Transport | OverQuotaSize: 0 bytes } | fd: 14 | LocalPoint: { comm::INetAddress { comm::Device { IP: 192.168.1.55 | Status: Up } | Port: 3868 }  } | Bound: true | Opened: true | Category: 1 | anna::comm::ReceiverFactory { Name: diameter.comm.ServerSessionReceiver } } | RcvBufferSize: 16384 bytes | Status: Connected Working | MaxConDelay: 200 ms | OverQuotaSize: 2048 | Reserved: 1220 | Pending: 0 | Offset: 1220 | ExpectedSize: -1 | Remote access point: { comm::INetAddress { comm::Device { IP: 192.168.1.50 | Status: Up } | Port: 7001 }  } } | Allowed inactivity time: 90000 ms }

--------------------------------------------------------------------------------------------------------------------------------------
[fwd2e] 10/12/2012 10:46:45 Europe/Madrid, isdst = 0 [Unix Timestamp: 1355132805, Ntp Timestamp: 3564121605], Local TZ = Europe/Madrid
--------------------------------------------------------------------------------------------------------------------------------------
<message version="1" name="Credit-Control-Request" p-bit="yes" application-id="4" hop-by-hop-id="1" end-by-end-id="1">
   <avp name="Session-Id" data="gbg.acision.com;421411;1000"/>
   <avp name="Origin-Host" data="gbg.acision.com"/>
   <avp name="Origin-Realm" data="SMSC.orig.OCS2.o2online.de"/>
   <avp name="Destination-Realm" data="SMSC.dest.OCS1.o2online.de"/>
   <avp name="Auth-Application-Id" data="4"/>
   <avp name="Service-Context-Id" data="8.6.0.07.262.8.32274@3gpp.org"/>
   <avp name="CC-Request-Type" data="4" alias="EVENT_REQUEST"/>
   <avp name="CC-Request-Number" data="1"/>
   <avp name="Destination-Host" data="OCS1"/>
   <avp name="Event-Timestamp" data="1"/>
   <avp name="Subscription-Id">
      <avp name="Subscription-Id-Type" data="0" alias="END_USER_E164"/>
      <avp name="Subscription-Id-Data" data="5555100000"/>
   </avp>
   <avp name="Requested-Action" data="0" alias="DIRECT_DEBITING"/>
   <avp name="Multiple-Services-Indicator" data="0" alias="MULTIPLE_SERVICES_NOT_SUPPORTED"/>
   <avp name="Multiple-Services-Credit-Control">
      <avp name="Requested-Service-Unit">
         <avp name="CC-Service-Specific-Units" data="1"/>
      </avp>
      <avp name="Service-Identifier" data="1"/>
   </avp>
   <avp name="Service-Information">
      <avp name="MMS-Information">
         <avp name="Originator-Address">
            <avp name="Address-Type" data="1" alias="MSISDN"/>
            <avp name="Address-Data" data="5555100000"/>
            <avp name="Address-Domain">
               <avp name="3GPP-IMSI-MCC-MNC" data="26207"/>
            </avp>
         </avp>
         <avp name="Originator-Address">
            <avp name="Address-Type" data="6" alias="Other"/>
            <avp name="Address-Data" data="262075555100000"/>
         </avp>
         <avp name="Submission-Time" data="3486294858"/>
         <avp name="Message-Size" data="4"/>
      </avp>
      <avp name="SMS-Information">
         <avp name="SMS-Node" data="3" alias="SMS-SC"/>
         <avp name="Client-Address" data="8|541760000405"/>
         <avp name="Originator-SCCP-Address" data="8|541760000005"/>
         <avp name="Originator-Received-Address">
            <avp name="Address-Type" data="1" alias="MSISDN"/>
            <avp name="Address-Data" data="5555100000"/>
            <avp name="Address-Domain">
               <avp name="3GPP-IMSI-MCC-MNC" data="26207"/>
            </avp>
         </avp>
         <avp name="Recipient-Info">
            <avp name="Destination-Interface">
               <avp name="Interface-Id" data="5417607020601"/>
               <avp name="Interface-Type" data="2" alias="MOBILE_TERMINATING"/>
            </avp>
            <avp name="Recipient-Address">
               <avp name="Address-Type" data="1" alias="MSISDN"/>
               <avp name="Address-Data" data="5417607020601"/>
               <avp name="Address-Domain">
                  <avp name="3GPP-IMSI-MCC-MNC" data="26207"/>
               </avp>
            </avp>
            <avp name="Recipient-Address">
               <avp name="Address-Type" data="6" alias="Other"/>
               <avp name="Address-Data" data="262074900005771"/>
            </avp>
            <avp name="Recipient-Received-Address">
               <avp name="Address-Type" data="1" alias="MSISDN"/>
               <avp name="Address-Data" data="5417607020601"/>
               <avp name="Address-Domain">
                  <avp name="3GPP-IMSI-MCC-MNC" data="26207"/>
               </avp>
            </avp>
            <avp name="Recipient-SCCP-Address" data="8|541760000005"/>
         </avp>
         <avp name="SMSC-Address" data="8|541760000405"/>
         <avp name="Data-Coding-Scheme" data="0"/>
         <avp name="SM-Message-Type" data="0" alias="SUBMISSION"/>
         <avp name="Originator-Interface">
            <avp name="Interface-Id" data="262074900005771"/>
            <avp name="Interface-Type" data="1" alias="MOBILE_ORIGINATING"/>
         </avp>
         <avp name="Number-Of-Messages-Sent" data="1"/>
      </avp>
   </avp>
   <avp name="CC-Correlation-Id" hex-data="6762672e61636973696f6e2e636f6d3b3432313431313b31303030"/>
</message>

Used resource
-------------
diameter::comm::ClientSession { Timer { timex::TimeEvent { Id: 0x9b43dc0 | Reference: 0x9b43dc0 | Timeout: 30000 ms } | Name: Diameter Keep-Alive Timer } | Socket Id: 0 | State: Bound | OnDisconnect: WaitPendings | Next Hop by hop: 1235658055 | Next End to end: 127353711 | OTA requests: 1 | Last Incoming Activity Time: 1355132784902 ms | Last Outgoing Activity Time: 1355132805252 ms | Timeout for ClassCode 'Bind': 25000 ms | Timeout for ClassCode 'ApplicationMessage': 25000 ms | Parent Server: 192.168.1.55:3989 | Auto-recovery: yes | WatchdogState: WaitingTimerExpiration | Watchdog Period: 30000 ms | MaxConnectionDelay: 200 ms }

---------------------------------------------------------------------------------------------------------------------------------------
[recvfe] 10/12/2012 10:46:45 Europe/Madrid, isdst = 0 [Unix Timestamp: 1355132805, Ntp Timestamp: 3564121605], Local TZ = Europe/Madrid
---------------------------------------------------------------------------------------------------------------------------------------
<message version="1" name="Credit-Control-Answer" p-bit="yes" application-id="4" hop-by-hop-id="1" end-by-end-id="1">
   <avp name="Session-Id" data="gbg.acision.com;421411;1000"/>
   <avp name="Result-Code" data="2001" alias="DIAMETER_SUCCESS"/>
   <avp name="Origin-Host" data="OCS1"/>
   <avp name="Origin-Realm" data="SMSC.orig.OCS2.o2online.de"/>
   <avp name="Auth-Application-Id" data="4"/>
   <avp name="CC-Request-Type" data="4" alias="EVENT_REQUEST"/>
   <avp name="CC-Request-Number" data="1"/>
   <avp name="Multiple-Services-Credit-Control">
      <avp name="Granted-Service-Unit">
         <avp name="CC-Service-Specific-Units" data="1"/>
      </avp>
      <avp name="Service-Identifier" data="1"/>
      <avp name="Result-Code" data="2001" alias="DIAMETER_SUCCESS"/>
   </avp>
   <avp name="Cost-Information">
      <avp name="Unit-Value">
         <avp name="Value-Digits" data="200"/>
         <avp name="Exponent" data="-2"/>
      </avp>
      <avp name="Currency-Code" data="1"/>
   </avp>
   <avp name="Remaining-Balance">
      <avp name="Unit-Value">
         <avp name="Value-Digits" data="999988399"/>
         <avp name="Exponent" data="-2"/>
      </avp>
      <avp name="Currency-Code" data="1"/>
   </avp>
</message>

Used resource
-------------
diameter::comm::ClientSession { Timer { timex::TimeEvent { Id: 0x9b43dc0 | Reference: 0x9b43dc0 | Timeout: 30000 ms } | Name: Diameter Keep-Alive Timer } | Socket Id: 0 | State: Bound | OnDisconnect: WaitPendings | Next Hop by hop: 1235658055 | Next End to end: 127353711 | OTA requests: 1 | Last Incoming Activity Time: 1355132805376 ms | Last Outgoing Activity Time: 1355132805252 ms | Timeout for ClassCode 'Bind': 25000 ms | Timeout for ClassCode 'ApplicationMessage': 25000 ms | Parent Server: 192.168.1.55:3989 | Auto-recovery: yes | WatchdogState: WaitingTimerExpiration | Watchdog Period: 30000 ms | MaxConnectionDelay: 200 ms }

------------------------------------------------------------------------------------------------------------------------------------------
[fwd2c] 10/12/2012 10:46:45 Europe/Madrid, isdst = 0 [Unix Timestamp: 1355132805, Ntp Timestamp: 3564121605], Local TZ = Europe/Madrid
------------------------------------------------------------------------------------------------------------------------------------------
<message version="1" name="Credit-Control-Answer" p-bit="yes" application-id="4" hop-by-hop-id="1" end-by-end-id="1">
   <avp name="Session-Id" data="gbg.acision.com;421411;1000"/>
   <avp name="Result-Code" data="2001" alias="DIAMETER_SUCCESS"/>
   <avp name="Origin-Host" data="OCS1"/>
   <avp name="Origin-Realm" data="SMSC.orig.OCS2.o2online.de"/>
   <avp name="Auth-Application-Id" data="4"/>
   <avp name="CC-Request-Type" data="4" alias="EVENT_REQUEST"/>
   <avp name="CC-Request-Number" data="1"/>
   <avp name="Multiple-Services-Credit-Control">
      <avp name="Granted-Service-Unit">
         <avp name="CC-Service-Specific-Units" data="1"/>
      </avp>
      <avp name="Service-Identifier" data="1"/>
      <avp name="Result-Code" data="2001" alias="DIAMETER_SUCCESS"/>
   </avp>
   <avp name="Cost-Information">
      <avp name="Unit-Value">
         <avp name="Value-Digits" data="200"/>
         <avp name="Exponent" data="-2"/>
      </avp>
      <avp name="Currency-Code" data="1"/>
   </avp>
   <avp name="Remaining-Balance">
      <avp name="Unit-Value">
         <avp name="Value-Digits" data="999988399"/>
         <avp name="Exponent" data="-2"/>
      </avp>
      <avp name="Currency-Code" data="1"/>
   </avp>
</message>

Used resource
-------------
diameter::comm::ServerSession { Timer { timex::TimeEvent { Id: 0x9b4ba40 | Reference: 0x9b4ba40 | Timeout: 90000 ms } | Name: Diameter Inactivity Detection Timer } | Socket Id: 4 | State: Bound | OnDisconnect: WaitPendings | Next Hop by hop: 1888494197 | Next End to end: 4138298175 | OTA requests: 0 (idle) | Last Incoming Activity Time: 1355132805247 ms | Last Outgoing Activity Time: 1355132805377 ms | Timeout for ClassCode 'Bind': 10000 ms | Timeout for ClassCode 'ApplicationMessage': 10000 ms | Parent Local Server: 192.168.1.55:3868 | Client Socket: comm::ClientSocket { comm::Socket { Domain: Inet | Type: Stream | comm::TransportFactory { Name: diameter::comm::Transport | OverQuotaSize: 0 bytes } | fd: 14 | LocalPoint: { comm::INetAddress { comm::Device { IP: 192.168.1.55 | Status: Up } | Port: 3868 }  } | Bound: true | Opened: true | Category: 1 | anna::comm::ReceiverFactory { Name: diameter.comm.ServerSessionReceiver } } | RcvBufferSize: 16384 bytes | Status: Connected | MaxConDelay: 200 ms | OverQuotaSize: 2048 | Reserved: 0 | Pending: 0 | Offset: 0 | ExpectedSize: -1 | Remote access point: { comm::INetAddress { comm::Device { IP: 192.168.1.50 | Status: Up } | Port: 7001 }  } } | Allowed inactivity time: 90000 ms }

We can see three "multiplexors" or "loading docks", labeled with these key words:

   [recvfc] (received from client)
   [fwd2e]  (forwarded to entity)
   [recvfe] (received from entity)
   [fwd2c]  (forwarded to client)

We have kept these four in the example, since they represent the normal cycle in the proxy function, but there are many more that will appear depending on the setting and circumstances of the event:

   [sent2e/send2eError]   Send to entity (success/error)
   [sent2c/send2cError]   Send to client (success/error)
   [fwd2e/fwd2eError]     Forward to entity a reception from client (success/error)
   [fwd2c/fwd2cError]     Forward to client a reception from entity (success/error)
   [recvfc]               Reception from client
   [recvfe]               Reception from entity
   [req2c-expired]        A request sent to client has been expired
   [req2e-expired]        A request sent to entity has been expired
   [recvfc-ans-unknown]   Reception from client of an unknown answer (probably former [req2c-expired] has been logged)
   [recvfe-ans-unknown]   Reception from entity of an unknown answer (probably former [req2e-expired] has been logged)
   [retry]                Request retransmission

Some service parameters

ignoreFlagsOnValidation

When representing a message in xml, as you can see in the template there is a "compact" option and an "open" alternative. Both for operation (can put your name instead of your code) and for some AVP (can put your name instead of the code, vendor id and flags). Where the idea is clearer to see compact/open mode meaning, is in the case of the AVP. Suppose the Session-Id AVP, whose definition in the dictionary is:

<avp name="Session-Id" code="263" may-encrypt="yes" v-bit="mustnot" m-bit="must" p-bit="may"><single format-name="UTF8String"/></avp>

Its definition follows the standard, which sets the following flags:

                                               AVP  |       Must  |        May  | Should Not  |   Must Not  | May Encrypt
-------------------------------------------------------------------------------------------------------------------------
                                        Session-Id  |          M  |          P  |          -  |          V  |          Y

If we send a message like following:

<message version="1" name="AA-Request" application-id="0" hop-by-hop-id="10" end-by-end-id="2">
   <avp name="Session-Id" data="ocs3;1332909618;0;1332909618"/>
   <avp name="Auth-Application-Id" data="16777236"/>
   <avp name="Origin-Host" data="OCS3"/>
   <avp name="Origin-Realm" data="OCS3"/>
   <avp name="Destination-Realm" data="PCRF"/>
   <avp name="Subscription-Id">
      <avp name="Subscription-Id-Type" data="0" alias="END_USER_E164"/>
      <avp name="Subscription-Id-Data" data="4851"/>
   </avp>
</message>

What we are saying is that the Session-Id AVP is encoded as dictionary says (corresponding to dictated by the standard), which is active M bit and inactive V bit (the concepts 'May', 'Should not' and 'May Encrypt' are indicative but not determinative, important are 'Must' and 'Must not').

This message could be defined with Session-Id equal to what the dictionary defines, but with the "non-compact" format as dtd allows:

   <avp code="263" vendor-code="0" flags="64" data="ocs3;1332909618;0;1332909618"/>

where value 64 corresponds to byte 01000000b [VMPr rrrr], ie active M bit.

Suppose now that we define AA-Request operation with this one Session-Id:

   <avp code="263" vendor-code="0" flags="0" data="ocs3;1332909618;0;1332909618"/>

Such AVP has now inactive M bit, what probably has no logic implications (very few nodes are exhaustive analyzing the flags), but it is clear that in this case, we're breaching the specification.

When the ANNA::diameter module analyzes and represents a diameter message processed (either debug traces or traffic logs dumps), it is in xml format because it is easier to understand than hexadecimal buffer. In this case, the message of the previous example with the Session-Id "non-standard" would appear as:

<message version="1" name="AA-Request" application-id="0" hop-by-hop-id="10" end-by-end-id="2">
   <avp code="263" vendor-code="0" flags="0" data="ocs3;1332909618;0;1332909618"/>
   <avp name="Auth-Application-Id" data="16777236"/>
   <avp name="Origin-Host" data="OCS3"/>
   <avp name="Origin-Realm" data="OCS3"/>
   <avp name="Destination-Realm" data="PCRF"/>
   <avp name="Subscription-Id">
      <avp name="Subscription-Id-Type" data="0" alias="END_USER_E164"/>
      <avp name="Subscription-Id-Data" data="4851"/>
   </avp>
</message>

And this is because the Session-Id is not exactly the same as defined in the dictionary, but a Session-Id AVP and specific flags that do not match 100%.

Here comes in the service parameter whose presence means that even with no matching flags with the dictionary, the xml representation ignore such "capricious" definition of flags leading to the first representatin we set, ie which has the "simplified" Session-Id:

   <avp name="Session-Id" data="ocs3;1332909618;0;1332909618"/>

What is really happening is that the message processed (hexadecimal) does not fully coincide with the encoding (using the dictionary) for the xml represented, while the first will have the M flag off for the Session-Id, and the represented will have the specified flag at dictionary conform the specification: M bit active.

The recommendation is to start the ADML process without this optional parameter, since it does not guarantee 100% that what we see, for the purposes of flags, is exactly what we received, and this discrepancy, although too detailed, could confuse sometime when perform deeper analysis.

The service parameter internally prevents verification of M and P flags of AVPs, which involves having a compact XML representation, but mainly ignores validation errors messages generated by nodes that do not comply with the standard regarding the flags.

detailedLog

Each log record in the file contains a header with the event type within brackets and then the message corresponding to the diameter message traced in xml format. There is also detailed information (which is optionally added by mean the service parameter 'detailedLog') consisting of the temporal event information in the header, and the data associated with the resource used for message transport (connection by which it is received or sends data associated with the session, etc.) right after the message.

splitLog

The log file can be divided into N files for each event type. Each file name is formed by concatenating the 'log filename' with an extension that is the type of event (list of types within brackets shown above). For example, the traffic from the previous example, usually would generate 4 files:

./launcher.log.recvfc
./launcher.log.fwd2e
./launcher.log.recvfe
./launcher.log.fwd2c

dumpLog

Dumps to disk every incoming/outcoming message named as '<unix ms timestamp>.<originHost>.<hop by hop>.<end to end>.<message code>.<request|answer>.<type of event>.xml'. This could be useful in function test environment in order to detect traffic, analyze it and adapt the reaction to the tested system. Anyway, don't think this is the normal way to do it. Later we will see the scenario configuration which is built-in and no need to externalize procedures to orchestrate the flow.

burstLog

Log file for burst mode operations. This mode will be explained later, but basically it is a set of related operations to load launch for capacity tests of a diameter server system (eg OCS). By default, the program will dump the related information over '<originHost>.launcher.burst' file. It can also disable the generation of such logs simply by providing 'null'. The log consists in a set of symbols for each type of event: (.) for each message sent, (x) for each event-reception discarded for sending, information for on-the-air messages, message order in the burst list, etc.:

.............. 540................... 560[OTA 2]................... 580[OTA 3]................... 600[OTA 1]................... 620................... 640................... 660................... 680[OTA 2]................... 700[OTA 1]................... 720................... 740................... 760................... 780[OTA 2]................... 800[OTA 1]................... 820[OTA 2]................... 840................... 860[OTA 1]................... 880................... 900................... 920................... 940................... 960................... 980................... 1000................... 1020................... 1040[OTA 2]................... 1060[OTA 1]................... 1080................... 1100[OTA 2]................... 1120[OTA 1]................... 1140................... 1160[OTA 2]................... 1180[OTA 1]................... 1200................... 1220................... 1240................... 1260................... 1280[OTA 2]................... 1300[OTA 8]................... 1320.........xxxxxx.... 1340[OTA 2]................... 1360[OTA 1]

etc.

Context dump

As in any ANNA process, we can cause a dump context sending the signal '-10' (SIGUSR1) to the process.
The context will be dumped to the file '/var/tmp/anna.context.<PID>' in xml format which greatly facilitates the understanding and classification of the information displayed.
Press here for an example of context dump of ADML configured as a client towards two diameter servers.
As we will see later, a context dump operation over the management interface is also supported, which allows to specify the target file where the information is dumped.

Hexadecimal content

By default, ANNA suite works with an hexadecimal readable format which consists in hexadecimal octets one behind the other without separators. For example: 6762672e61636973696f6e2e636f6d3b3432313431313b31303030. This applies to xml fields which are not being deeply decoded, and it also shall be used in the hex files used to be decoded as we will see in the following explanations. Anyway, hex files (with such hex readable content) as an input, could have the colon separator: 67:62:67:2e:61:63:69:73:69:6f:6e:2e:63:6f:6d:3b:34:32:31:34:31:31:3b:31:30:30:30. Both representations are well interpreted by the process. However, the xml fields containing hex data, will shown the colon-free format, which is more compact.

HTTP management operations

The typical stuff in a test directory of an ADML process, are scripts to launch requests, responses programming support, help & support, operations, etc. Virtually all scripts look because they rely on curl linux command to make a connection to the process http interface in order to perform a certain operation. These scripts help you to use this interface and abstract the user to the specific syntax of the content (body) for http message. In any case, we will start with a detailed explanation of such operations to understand the magnitude and operational capacity of the ADML. The scripts are provided in the full deployment (see deployment scripts on the './examples/diameter/launcher' directory) and are based on dynamic hidden data that are configured according to the model (data routing, ports, launch options, etc.).

HTTP REST API will be described in another document (ToDo).

HELP

Operations via SIGUSR2 signal

Requires the creation of the task(s) file which will be read at
signal event:
echo "<<operation>" > /home/eramedu/ADML-basic/sigusr2.in
then
kill -12 <pid>
or
kill -s SIGUSR2 <pid>
and then see the results:
cat /home/eramedu/ADML-basic/sigusr2.out

(this file is ended with EOF final line, useful managing huge batch files to ensure the job completion)

You could place more than one line (task) in the input file. Output reports will be appended in that
case over the output file. Take into account that all the content of the task file will be executed
sinchronously by the process. If you are planning traffic load, better use the asynchronous http
interface.

As we have seen before, there is an alternative to the management via HTTP (which is actually optional): management by mean SIGUSR2 signal capture. Here are one by one, all available operations that can be applied to any of the two methods. Each of the sections will refer to an operation, so that for a section called "Operation xxxx", the way they would be thrown is: curl -m 1 --data "xxxx" localhost: 9000 or echo "xxxx"> sigusr2.tasks.input; SIGUSR2 kill -s <pid>.

Now we will see some operations in more detail:

Operation code|<source_file>|<target_file>

Operation of parsing category, encoding a source file on a file destination. Generally the source file has xml extension (which is its format) and the result is an readable representation of the hexadecimal content. The extension .hex is recommended for the target file. That extension is asummed to the content in coded form:

An encoded cer.xml could be:

myuser@myhostname:~/ADML-basic$ cat dwr.xml
<message version="1" name="Device-Watchdog-Request" application-id="0">
   <avp name="Origin-Host" data="pstelbe1.telefonica.mbbi.com.ar"/>
   <avp name="Origin-Realm" data="telefonica.mbbi.com.ar"/>
</message>

myuser@myhostname:~/ADML-basic$ code.sh dwr.xml

Operation processed; File 'dwr.xml.hex' created.
myuser@myhostname:~/ADML-basic$ cat dwr.xml.hex
0100005c800001180000000000000000000000000000010840000027707374656c6265312e74656c65666f6e6963612e6d6262692e636f6d2e617200000001284000001e74656c65666f6e6963612e6d6262692e636f6d2e61720000

Operation decode|<source_file>|<target_file>

Operation inverse to the encoding. Again, the script for decoding an encoded file to be transformed into xml format, is provided.

myuser@myhostname:~/ADML-basic$ decode.sh dwr.xml.hex

Operation processed; File 'dwr.xml.hex.xml' created.
myuser@myhostname:~/ADML-basic$ cat dwr.xml.hex.xml
<message version="1" name="Device-Watchdog-Request" application-id="0" hop-by-hop-id="0" end-by-end-id="0">
   <avp name="Origin-Host" data="pstelbe1.telefonica.mbbi.com.ar"/>
   <avp name="Origin-Realm" data="telefonica.mbbi.com.ar"/>
</message>

Operation loadxml|<source_file>

It may seem not useful, but becomes important when we want to know how to interpret by our stack a given xml when there are inconsistencies in the flags. Suppose you have started the ADML process in xml compact mode (remember the service parameter):

myuser@myhostname:~/ADML-basic$ cat dwr2.xml
<message version="1" name="Device-Watchdog-Request" application-id="0">
   <avp code="264" flags="0" vendor-code="0" data="pstelbe1.telefonica.mbbi.com.ar"/>
   <avp name="Origin-Realm" data="telefonica.mbbi.com.ar"/>
</message>

myuser@myhostname:~/ADML-basic$ loadXml.sh  dwr2.xml

<message version="1" name="Device-Watchdog-Request" application-id="0" hop-by-hop-id="0" end-by-end-id="0">
   <avp name="Origin-Host" data="pstelbe1.telefonica.mbbi.com.ar"/>
   <avp name="Origin-Realm" data="telefonica.mbbi.com.ar"/>
</message>

Operation processed; Message 'dwr2.xml' loaded.

If instead we started in strict mode:

myuser@myhostname:~/ADML-basic$ loadXml.sh  dwr2.xml

<message version="1" name="Device-Watchdog-Request" application-id="0" hop-by-hop-id="0" end-by-end-id="0">
   <avp code="264" vendor-code="0" flags="0" data="pstelbe1.telefonica.mbbi.com.ar"/>
   <avp name="Origin-Realm" data="telefonica.mbbi.com.ar"/>
</message>

Operation processed; Message 'dwr2.xml' loaded.

This Operation just be worth testing to validate xml (although this can be done using a generic XML editor, or xmllint, etc.):

myuser@myhostname:~/ADML-basic$ cat dwrBad.xml
<message version="1" name="Device-Watchdog-Request" application-id="0">
   <avp NNNName="Origin-Host" data="pstelbe1.telefonica.mbbi.com.ar"/>
   <avp name="Origin-Realm" data="telefonica.mbbi.com.ar"/>
</message>

myuser@myhostname:~/ADML-basic$ loadXml.sh dwrBad.xml

Operation processed with exception. See traces
myuser@myhostname:~/ADML-basic$ grep Exception launcher.trace
[10/05/2012 23:19:08] Error | xml.DTD.cc (85) | RuntimeException | XML Document: dwrBad.xml | Does not comply the DTD especification

Operation diameterServerSessions|<integer>

Regardless of the number of accepted connections by the process on the server side, that are configured on command line, we can change this information on the air. Obviously, the operation will fail if we set a smaller number to the number of current connections, since this dynamic configurability will never cause accidental socket disconnections if already established. In the context of a testing process, perhaps not a very attractive feature, since it is unlikely needed to scale such resources in this context (the process would stop and start reconfigured with the necessary data), but attests an inherent capacity in diameter::ANNA::comm communications engine, which is interesting in a process deployed in production (scalability could be applied without changing the number of instances of the process and therefore without touching the service configuration).
This command can even be used to "wake up" an ADML process server started without diameter (-diameterServer <server> -diameterServerSessions 0), no more than provide a positive factor for the number of connections.

Operation collect

This operation resets the statistical and process counters. It is useful to establish a new control point for data collection. In this sense, it would have been more appropriate to call it "reset" or "reset_stats" but his name rather is due to the fact that it is mainly used when coordinating data collection stages (for example, high availability: before/during/after a certain contingency).

This command can be combined with a context dump, trace cleaning, and data collection, in a series of steps for analyzing a test phase.
Using a collect.sh script (containing something like curl -m 1 --data "collect" localhost: 9000), we could have:

Start of data collection (stage):

# Restart
rm /var/tmp/anna.context.* *.csv *.log *.trace 2>/dev/null
./collect.sh
date > ./RESULT/fecha_ini.txt

Ending data collection (stage):

#!/bin/ksh
date > ./RESULT/fecha_fin.txt

# Context:
PID=`ps -fea|grep ADML-PROCESS | grep -v grep | awk '{ print $2 }'`
kill -10 $PID
sleep 1
mv /var/tmp/anna.context.* ./RESULT
mv *.csv ./RESULT 2>/dev/null
mv *.log ./RESULT 2>/dev/null
mv *.trace ./RESULT 2>/dev/null

The context dump is the most useful, and thanks to performing the reset collect.sh, reliable measures will not be marred with data from adjacent stages, both counters (accumulated that appear with the keyword accumulated), such as the rate of statistical values (shown as vps). For example:

myuser@myhostname:~/ADML-basic$ grep Accumulated /var/tmp/anna.context.08713
               <Counter Type="0" Description="RequestReceived" ScopeId="1" Offset="0" RealId="1000" AccumulatedAmount="427"/>
               <Counter Type="1" Description="AnswerReceived" ScopeId="1" Offset="1" RealId="1001" AccumulatedAmount="430"/>
               <Counter Type="3" Description="AnswerReceivedOnClientSession" ScopeId="1" Offset="3" RealId="1003" AccumulatedAmount="430"/>
               <Counter Type="4" Description="RequestReceivedOnServerSession" ScopeId="1" Offset="4" RealId="1004" AccumulatedAmount="427"/>
               <Counter Type="6" Description="RequestSentOK" ScopeId="1" Offset="6" RealId="1006" AccumulatedAmount="430"/>
               <Counter Type="8" Description="AnswerSentOK" ScopeId="1" Offset="7" RealId="1007" AccumulatedAmount="427"/>
               <Counter Type="10" Description="RequestSentOnClientSessionOK" ScopeId="1" Offset="10" RealId="1010" AccumulatedAmount="430"/>
               <Counter Type="12" Description="AnswerSentOnClientSessionOK" ScopeId="1" Offset="12" RealId="1012" AccumulatedAmount="427"/>
               <Counter Type="27" Description="CERReceived" ScopeId="1" Offset="27" RealId="1027" AccumulatedAmount="1"/>
               <Counter Type="28" Description="CEASentOK" ScopeId="1" Offset="28" RealId="1028" AccumulatedAmount="1"/>
               <Counter Type="30" Description="DWRSentOK" ScopeId="1" Offset="21" RealId="1021" AccumulatedAmount="7"/>
               <Counter Type="32" Description="DWAReceived" ScopeId="1" Offset="23" RealId="1023" AccumulatedAmount="7"/>
               <Counter Type="33" Description="DWRReceived" ScopeId="1" Offset="30" RealId="1030" AccumulatedAmount="3"/>
               <Counter Type="34" Description="DWASentOK" ScopeId="1" Offset="31" RealId="1031" AccumulatedAmount="3"/>
               <Counter Type="42" Description="ServerSocketsOpened" ScopeId="1" Offset="36" RealId="1036" AccumulatedAmount="1"/>
               <Counter Type="43" Description="ServerSocketsClosed" ScopeId="1" Offset="37" RealId="1037" AccumulatedAmount="1"/>

myuser@myhostname:~/ADML-basic$ grep vps /var/tmp/anna.context.08713
                                 <Data Size="211" Average="73.13" StandardDeviation="46.00" BesselStandardDeviation="46.11" ProcessingRate="1.55 vps (values per second)">
                                 <Data Size="214" Average="320.36" StandardDeviation="30.57" BesselStandardDeviation="30.64" ProcessingRate="1.57 vps (values per second)">
                                 <Data Size="212" Average="70.44" StandardDeviation="49.14" BesselStandardDeviation="49.25" ProcessingRate="1.56 vps (values per second)">
                                 <Data Size="216" Average="319.19" StandardDeviation="35.05" BesselStandardDeviation="35.13" ProcessingRate="1.59 vps (values per second)">
                           <Data Size="427" Average="1209.47" StandardDeviation="108.31" BesselStandardDeviation="108.44" ProcessingRate="3.14 vps (values per second)">

Operación forceCountersRecord

This operation forces the counters dump although no counter period has expired. It is useful if you don't want to wait such counters dump period. If the process was started and we are going to execute a controlled test case, it would be convenient to reset the counters at the test beginning by mean the former commented operation collect.

Operation <visibility action>|[<address>:<port>]|[socket id]

The ADML process client mode allow to configure the visibility of sockets for delivery. This means that although the sockets are always available online to keep alive when appropriate, or establishment protocol by CER/CEA when they reconnect or connect for the first time, there is a logic state of activation/deactivation for application messages. This feature allows you to filter in real time, the delivery routes from a traffic load for testing to certain instances or front-ends.

Scenarios could be prepared with specific Session-Id to make something like that through the mechanism of selective delivery (remember sessionBasedModelsClientSocketSelection) but are much simpler disable sockets that do not want to use.

Visualization operations are divided into two types: the query (shown/hidden) and update (show/hide), consisting respectively of querying and updating the active/inactive state of an element.

As an argument (target element), we have two optional parts, the server and the socket identifier within that server. If the latter is not provided, all server sockets will be affected by the operation. If not specified the server then affected all servers in the destination entity (the only) configured on the ADML process.

When you start the process, all sockets are active (even if we have not activated balancing, delivery will, under normal conditions, only the primary server).

Operation sendxml2e|<source_file>

This Operation is used to send to the entity and xml format diameter message. The process should be client a to use it, and delivery resources will be selected based on established algorithms and the availability of remote elements.

For sending a request, it will automatically become part of the context of the process until the corresponding response or an expiration of the pending context it is received.

The ADML process also supports natively (in ANNA::diameter module) automatically managing the DPR/DPA procedure, whereby the DPR (Disconnect-Peer-Request) is a message that can also be sent through this Operation to initiate a disconnection procedure.

Example of use through a script:

myuser@myhostname:~/ADML-basic$ sendXml.sh  aar.xml

Operation processed; Message 'aar.xml' sent to entity.
myuser@myhostname:~/ADML-basic$ cat launcher.log
[send2e]
<message version="1" name="AA-Request" application-id="0" hop-by-hop-id="10" end-by-end-id="2">
   <avp name="Session-Id" data="ocs3;1332909618;0;1332909618"/>
   <avp name="Auth-Application-Id" data="16777236"/>
   <avp name="Origin-Host" data="OCS3"/>
   <avp name="Origin-Realm" data="OCS3"/>
   <avp name="Destination-Realm" data="PCRF"/>
   <avp name="Subscription-Id">
      <avp name="Subscription-Id-Type" data="0" alias="END_USER_E164"/>
      <avp name="Subscription-Id-Data" data="616279266"/>
   </avp>
</message>

Operation sendxml2c|<source_file>

Like 'sendxml2e' is a delivery operation. The difference is that the message is sent to the client, not to the entity (server). If more than one socket is set, round-robin will take place between sockets (server sessions).

Requests sent to a client also have their own control context, and similarly to the case of transmission to servers, can also initiate a disconnection procedure by a DPR.

The script for the delivery is the same, but a second optional parameter to '2c' (to client) is added: sendXml.sh <message> 2c

Operation sendxml|<source_file>

Same as sendxml2e. The script could also be invoked thus: sendXml.sh <message> 2e. Although actually the second parameter '2e' (to entity) can be omitted, since the default is for sendings to servers, which is the normal thing.

Operation answerxml2c|[source_file]

The process can be programmed to respond to certain requests.
There are internal FIFO queues for the different message codes programed, that is to say, if we program two AA-Anwers (code=265) and one CC-Answer (code=272), then there will be one FIFO queue for code 265 and another one for code 272. The first one will have two messages, and the second, one. When the process receives a request with certain code, it will pop the next answer from the corresponding FIFO queue. Then, if we receive a CC-Request, its FIFO queue will be empty after sending the answer, and if we receive a AA-Request, then its FIFO queue will keep still one answer of this type because it had two AA-Answers programmed.

The process only reacts to requests (if answer comes, nothing is done). You can program in any moment if you need to coordinate or have a better control, but in general this feature is used to replay previously recorded diameter flows and then, we know the answers first of all. The FIFO differenciation is enough to give full control of the interactivity.

The hop-by-hop and end-to-end, are automatically transferred from the request received to the answer delivered. The session-id is also automatically propagated, and if any Subscription-Id AVPs, also move.

Operation answerxml2e|[source_file]

This Operation is similar to above. The difference is that the answers are scheduled to possible requests from the entity (server).

Operation answerxml|[source_file]

Equivalent to answerxml2c.

Operation answerxml without arguments

When no arguments are provided, a list of programmed answers will be shown on stdout.

myuser@myhostname:~/ADML-basic$ cat sigusr2.tasks.input 
answerxml2e
myuser@myhostname:~/ADML-basic$ kill -s SIGUSR2 <pid>

          ------------- CURRENT PROGRAMMED ANSWERS TO ENTITY -------------

================================================================================
                                 Answer code 265                                
================================================================================
<message version="1" name="AA-Answer" application-id="16777236" hop-by-hop-id="202475" end-by-end-id="509476">
   <avp name="Auth-Application-Id" data="16777236"/>
   <avp name="Session-Id" data="test1;afNodeHostname.afNodeHostRealm.com;1;8033450"/>
   <avp name="Origin-Host" data="sapcOwnHostId.operatorRealm.com"/>
   <avp name="Origin-State-Id" data="11111"/>
   <avp name="Origin-Realm" data="operatorRealm.com"/>
   <avp name="Experimental-Result">
      <avp name="Vendor-Id" data="10415"/>
      <avp name="Experimental-Result-Code" data="5063"/>
   </avp>
</message>

<message version="1" name="AA-Answer" application-id="16777236" hop-by-hop-id="202475" end-by-end-id="509476">
   <avp name="Auth-Application-Id" data="16777236"/>
   <avp name="Session-Id" data="test1;afNodeHostname.afNodeHostRealm.com;1;8033450"/>
   <avp name="Origin-Host" data="sapcOwnHostId.operatorRealm.com"/>
   <avp name="Origin-State-Id" data="22222"/>
   <avp name="Origin-Realm" data="operatorRealm.com"/>
   <avp name="Experimental-Result">
      <avp name="Vendor-Id" data="10415"/>
      <avp name="Experimental-Result-Code" data="5063"/>
   </avp>
</message>

Operation answerxml(2e|2c)|dump

With this operation, all the programmed answers are written to disk in xml format:

myuser@myhostname:~/ADML-basic$ echo "answerxml2e|dump" sigusr2.tasks.input 
myuser@myhostname:~/ADML-basic$ kill -s SIGUSR2 <pid>
myuser@myhostname:~/ADML-basic$ ls programmed_answer.*
programmed_answer.265.1.xml  programmed_answer.265.2.xml

Operation answerxml(2e|2c)|clear

This command will flush all the programmed answers for all the different code-FIFO queues programmed, regardless if they are queues to react against entities or clients when proceed (if the process is configured as client and server it will have both types).

Operation answerxml(2e|2c)|exhaust

The queue is by default exhausted when all the corresponding requests has been received. You could configure the queue to automatically rotate, but by default this rotation is disabled.

Operation answerxml(2e|2c)|rotate

When queue rotation is enabled, each answer which reacts a incoming requets, is added again to the queue in a infinite loop of answering. This could be useful on performance testing.

Send operations based on hexadecimal content

Similarly to sendxml2e|<source_file> (= sendxml|<source_file>) and sendxml2c|<source_file>, we have:

sendhex2e|<source_file>
sendhex2c|<source_file>
sendhex|<source_file> (same as sendhex2e)

All of them allow a higher flexibility than xml versions, because you could write a bad message to test protocol errors and other unexpected situations.

Operation burst|<action>|[parameter]

The Operation "burst" is specially designed for performance and stress testing, but also useful to sequence a set of scenarios with a rate controlled load. The different actions (first parameter) of operation burst offer a wide range of possibilities from a preprogrammed list (burst list). The idea is to load into memory requests to be launched, and then perform an action on the list. We can position ourselves and see what is in a point from the list, send N active requests (we'll see what this is) or N passive requests, etc.

The burst mode only works in client mode, as is the normal way to launch traffic from a diameter agent:

Action clear

Remove all the request loaded in the list.

Action load|<source_file>

Loads the file provided at the next position in the list. The burst.sh script, has an option of loading N elements, which below is done is to generate a message and load, N times. The order number is used to parameterize how the message is constructed. This depends on the type of billing, for example to generate SMS scenarios, being IEC is simple. An auxiliary sms.sh generates an SMS based on a template, for the given order. Then burst.sh script invokes the HTTP load operation. This is done N times, with N consecutive commands that form the list of messages for burst mode.
There is also a helper script called data.sh used to build data scenarios, more complex parameterized with a serial number, but quite possible. In general, sample scenarios of a real system and take one reference to be increasing as the subscriber data, sequence numbers, Session-Id, etc., is a prerequisite for the generation of these auxiliary scripts step. Parameterized through the load which can play back any environment of performance tests.

Action start|<initial load>

Start (or restart if already in progress) sending messages (provided load) of the burst list in order and in active mode. The active mode is that when the ADML process receives a response to a request or receive an expiration (which is a "virtual" response) gets the next item in the list and sends it. The active mode keeps constant the number of requests in the air (OTA request, this is over-the-air requets). If the initial charge is conveniently sized (assuming a fair distribution to the target servers, these will have a size of the receive queues based on the ratio between the number of servers and the initial charge launched) can calculate the number of messages in the air it will from the beginning, since the initial charge is sent to the principle of asynchronous manner, that is, without returning control to the communications module dealing activity of receive queues (that is, all sent at once when process operation). An initial load, "awakes" burst mode with an OTA equal to that load. This way, you get to "press" the server system to the maximum possible if the initial charge (OTA request) is sufficient to have no idleness on any destination server. As a new request is sent until a response (or expiration) is received, the queues are never increase as to increase levels of congestion (remains constant).

Requests in the air can be varied in real time, through the actions push and pop. The log for burst (remember burstLog parameter) displays each request sent with a symbol (.), and order within the burst list in each 1% of the total, with the current number of in-the-air requests when it changes. Messages for pop events are shown with a (x).

Action push|<load amount>

Injects a number of messages from the list, for no asynchronous delivery, increasing the number of requests in the air.
If we have a number of requests in the air equal to N, and make a push of P messages, behind the operation will have N+P in the air requests.

Action pop|<release amount>

Omit to make new requests for a number of responses received, reducing the number of requests in the air.
If we have a number of requests in the air equal to N, and make a pop of P messages, behind the operation we will have N-P in the air requests.
Perform a pop of all requests in the air (P greater than or equal to N) implies a cessation of deliveries, as they will not get more answers. Will be needed to make a start or a push to reactivate the steadily mode. The burst log shows the symbol x the pop messages (reception of events without sending the following request).

Operations push and pop allow fixing very easily, the congestion level of a receiving process. Suppose 30000 bytes queued for a level of congestion 3. If we have an average of 300 byes per request (this can be seen in the context dump in statistical calculations) means that when we have 100 messages in the receive queue for each server instance, will have reached that level. If the OCS awaits diameter servers with 4 instances, means that we inject charge to have OTA = 400 messages (assuming an equal distribution to each of the servers, then each will have 100 and therefore level 3 of congestion). We can launch an initial load of 400, or do it more gently, performing successive push operations to reach OTA = 400. The same applies to any other level of congestion, simply by calculating the number of messages that must let on the air on the side of OCS.

Action stop

Stop the process of sending in active mode. Answers may keep coming but will not cause new deliveries. You can resume doing a push.

Action repeat|[[yes]|no]

The burst list is finite. Suppose we have scheduled 2000 messages (500 data contexts of 4 requests: initial, update1, update2, termination). When the list is empty, the process ceases actively transmitting (equivalent to make a stop).

We can activate cycle mode, for the system to keep delivery cycle again and again. When the list is finished, it returns to the beginning, repeating again all scenarios. This can be useful to have maintained high load for a long period of time, unless we are willing to sacrifice some memory with a bigger list.

If we have not active the cyclic mode, and executes a push of N elements, lacking to the end of the list a number less than N, the push will be limited in the remaining margin. If we had repeated, would not be limited.

Action send|<amount>

Sends a number of messages from the list in passive mode, ie, unlike start or push, this delivery will not "wake up" automatic transmission at responses reception. We can externally control shipments from the list of scenarios and indeed, as we shall see, there is a script called burst.sh used to manage all the possible actions of this burst and especially using "sendXS" parameter that takes send N requests per second using a feedback control to stabilize and align the rate of loading.

Action goto|<order>

With this action we are positioned at a certain point in the list, providing the order number of message we want to prepare.

Action look|<order>

With this action we could look the xml message programmed at a certain point in the list, providing the order number of message.

Script burst.sh

One burst.sh script that facilitates the use of management commands of burst functionality.
When we launch this script without arguments, we obtain the following help:

Load tests configuration script

Use: ./burst.sh <action: clear | load | start | push | pop | stop | resume | repeat | send | goto | look> [action parameters]

     clear:
        Clears all loaded burst messages.

     load <amount> <traffic type: mms | sms | voice | data | content>:
        Loads 'amount' messages for the provided traffic type. For example:
           ./burst.sh load 2000 sms

     start [initial launch: default 1]:
        Starts the message sending from the begining of the burst list loaded,
        with a certain initial load. For example:
           ./burst.sh start 200

     push [amount: default 1]:
        Launch 'amount' messages as initial load does (non-asynchronous mode).
        It works even if burst launch is stopped. Useful to achieve congestion
        conditions. For example:
           ./burst.sh push 300

     pop [amount: default 1]:
        Skip send burst messages in order to reduce over-the-air requests.

     stop:
        Stops the burst cycle at the current position. It could affect sessions
        on the air (i.e. data contexts). Totally safe for IEC scenaries as SMS.

     resume:
        Resume an stopped burst launch from the same point (start will reset
        the work pointer to the first burst list position). This is equivalent
        to one-message-push operation.

     repeat [[yes] | no]:
        Restarts the burst launch cycle when finished.

     send [amount: default 1]:
        send messages from burst list. The main difference with start/push operations
        is that burst won't be awaken. Externally we could control sending time (no
        request will be sent for answers). When reach the last position, starts again.

     sendXS <requests per second> [amount: default -1 (no limit)]:
        send messages from burst list with the TPS provided. User could hot change
        speed by mean 'echo <TPS> > .tps' at another shell. You can stop the load
        removing that hidden file or using CTRL+C from the shell where you launched
        the burst command. Real tps is dumped on '.real_tps' file during testing.
        You could limit the amount of messages sent by mean the second parameter.
        No limit is established by default (-1 or negative value).

     goto <order>:
        Updates current burst pointer position.

     look <order>:
        Show programmed burst message for order provided.

Counters and alarms

In the context dump we can see the counters and alarms for each sub-module of the ADML process. There are two main modules: the encoding engine and communications engine. Each has a number of counters and alarms that generate the corresponding event when appropriate. The ADML process records no alarm, since it is not something that has an interest, or rather, no system (management element) expects these events to facilitate its evolution/display to the user. The alarms can be generated in the logging warning level of ADML process traces. Also counters, but also they increase the amount of memory in order to display it in the dump context when requested. The counters are very useful because they give a true and fair view of the program flow. There are many counters managed by ANNA::diameter, so the information is very detailed.

Generally, to see the counters quickly, usually make a grep Accumulated over context dump at the time of data collection. Thus only the counters that have increased at least once seen (since for them, the xml statistical section shows an "Accumulated" field in each event managed by the process, and that field does not appear (equals to zero) when there has never increased.

The communication engine, have also a counters module for application messages which are dynamically created/managed. If, for example, our process detects an application message with code 272 registered as "Credit-Control-Request / Credit-Control-Answer", automatically the following counters will be registered in the corresponding counter scope associated to the stack given by the message application-id:

      Credit-Control-Request_SentOK_AsClient
      Credit-Control-Request_SentNOK_AsClient
      Credit-Control-Answer_SentOK_AsClient
      Credit-Control-Answer_SentNOK_AsClient
      Credit-Control-Request_Received_AsClient
      Credit-Control-Answer_Received_AsClient
      Credit-Control-Answer_UnknownReceived_AsClient
      Credit-Control-Request_SentOK_AsServer
      Credit-Control-Request_SentNOK_AsServer
      Credit-Control-Answer_SentOK_AsServer
      Credit-Control-Answer_SentNOK_AsServer
      Credit-Control-Request_Received_AsServer
      Credit-Control-Answer_Received_AsServer
      Credit-Control-Answer_UnknownReceived_AsServer

If the request/answer description for the message code is unknown, the counter names would be something like:

      ApplicationMessageCode_272-Request_SentOK_AsClient
      ApplicationMessageCode_272-Request_SentNOK_AsClient
      ...

The capacity to register new dynamic counters, depends on the scope size (1000 at the moment) and the number of counter types implemented (14 at the moment).

Regarding static counters, this is the list of counters that under certain circumstances, the ADML process could increase:

   <oam.Module Name="diameter::comm oam module" Counters="Enabled" Alarms="Enabled" PreffixAlarmComponents="Shown" SuffixAlarmComponents="Shown">
      <RegisteredCounterScopes>
         <Scope Id="1" Description="diameter::comm oam module">
            <RegisteredCounters>
               <Counter Type="0" Description="RequestReceived" ScopeId="1" Offset="0" RealId="1000"/>
               <Counter Type="1" Description="AnswerReceived" ScopeId="1" Offset="1" RealId="1001"/>
               <Counter Type="2" Description="RequestReceivedOnClientSession" ScopeId="1" Offset="2" RealId="1002"/>
               <Counter Type="3" Description="AnswerReceivedOnClientSession" ScopeId="1" Offset="3" RealId="1003"/>
               <Counter Type="4" Description="RequestReceivedOnServerSession" ScopeId="1" Offset="4" RealId="1004"/>
               <Counter Type="5" Description="AnswerReceivedOnServerSession" ScopeId="1" Offset="5" RealId="1005"/>
               <Counter Type="6" Description="RequestSentOK" ScopeId="1" Offset="6" RealId="1006"/>
               <Counter Type="7" Description="RequestSentNOK" ScopeId="1" Offset="7" RealId="1007"/>
               <Counter Type="8" Description="AnswerSentOK" ScopeId="1" Offset="8" RealId="1008"/>
               <Counter Type="9" Description="AnswerSentNOK" ScopeId="1" Offset="9" RealId="1009"/>
               <Counter Type="10" Description="RequestSentOnClientSessionOK" ScopeId="1" Offset="10" RealId="1010"/>
               <Counter Type="11" Description="RequestSentOnClientSessionNOK" ScopeId="1" Offset="11" RealId="1011"/>
               <Counter Type="12" Description="AnswerSentOnClientSessionOK" ScopeId="1" Offset="12" RealId="1012"/>
               <Counter Type="13" Description="AnswerSentOnClientSessionNOK" ScopeId="1" Offset="13" RealId="1013"/>
               <Counter Type="14" Description="RequestSentOnServerSessionOK" ScopeId="1" Offset="14" RealId="1014"/>
               <Counter Type="15" Description="RequestSentOnServerSessionNOK" ScopeId="1" Offset="15" RealId="1015"/>
               <Counter Type="16" Description="AnswerSentOnServerSessionOK" ScopeId="1" Offset="16" RealId="1016"/>
               <Counter Type="17" Description="AnswerSentOnServerSessionNOK" ScopeId="1" Offset="17" RealId="1017"/>
               <Counter Type="18" Description="RequestSentExpired" ScopeId="1" Offset="55" RealId="1055"/>
               <Counter Type="19" Description="RequestSentOnClientSessionExpired" ScopeId="1" Offset="56" RealId="1056"/>
               <Counter Type="20" Description="RequestSentOnServerSessionExpired" ScopeId="1" Offset="57" RealId="1057"/>
               <Counter Type="21" Description="AnswerReceivedUnknown" ScopeId="1" Offset="58" RealId="1058"/>
               <Counter Type="22" Description="AnswerReceivedOnClientSessionUnknown" ScopeId="1" Offset="59" RealId="1059"/>
               <Counter Type="23" Description="AnswerReceivedOnServerSessionUnknown" ScopeId="1" Offset="60" RealId="1060"/>
               <Counter Type="24" Description="CERSentOK" ScopeId="1" Offset="18" RealId="1018"/>
               <Counter Type="25" Description="CERSentNOK" ScopeId="1" Offset="19" RealId="1019"/>
               <Counter Type="26" Description="CEAReceived" ScopeId="1" Offset="20" RealId="1020"/>
               <Counter Type="27" Description="CERReceived" ScopeId="1" Offset="27" RealId="1027"/>
               <Counter Type="28" Description="CEASentOK" ScopeId="1" Offset="28" RealId="1028"/>
               <Counter Type="29" Description="CEASentNOK" ScopeId="1" Offset="29" RealId="1029"/>
               <Counter Type="30" Description="DWRSentOK" ScopeId="1" Offset="21" RealId="1021"/>
               <Counter Type="31" Description="DWRSentNOK" ScopeId="1" Offset="22" RealId="1022"/>
               <Counter Type="32" Description="DWAReceived" ScopeId="1" Offset="23" RealId="1023"/>
               <Counter Type="33" Description="DWRReceived" ScopeId="1" Offset="30" RealId="1030"/>
               <Counter Type="34" Description="DWASentOK" ScopeId="1" Offset="31" RealId="1031"/>
               <Counter Type="35" Description="DWASentNOK" ScopeId="1" Offset="32" RealId="1032"/>
               <Counter Type="36" Description="DPRSentOK" ScopeId="1" Offset="24" RealId="1024"/>
               <Counter Type="37" Description="DPRSentNOK" ScopeId="1" Offset="25" RealId="1025"/>
               <Counter Type="38" Description="DPAReceived" ScopeId="1" Offset="26" RealId="1026"/>
               <Counter Type="39" Description="DPRReceived" ScopeId="1" Offset="33" RealId="1033"/>
               <Counter Type="40" Description="DPASentOK" ScopeId="1" Offset="34" RealId="1034"/>
               <Counter Type="41" Description="DPASentNOK" ScopeId="1" Offset="35" RealId="1035"/>
               <Counter Type="42" Description="ServerSocketsOpened" ScopeId="1" Offset="36" RealId="1036"/>
               <Counter Type="43" Description="ServerSocketsClosed" ScopeId="1" Offset="37" RealId="1037"/>
               <Counter Type="44" Description="UnableToDeliverOverEntity" ScopeId="1" Offset="38" RealId="1038"/>
               <Counter Type="45" Description="LostAvailabilityOverClientSession" ScopeId="1" Offset="39" RealId="1039"/>
               <Counter Type="46" Description="RecoveredAvailabilityOverClientSession" ScopeId="1" Offset="40" RealId="1040"/>
               <Counter Type="47" Description="LostAvailabilityOverServer" ScopeId="1" Offset="41" RealId="1041"/>
               <Counter Type="48" Description="RecoveredAvailabilityOverServer" ScopeId="1" Offset="42" RealId="1042"/>
               <Counter Type="49" Description="LostAvailabilityOverEntity" ScopeId="1" Offset="43" RealId="1043"/>
               <Counter Type="50" Description="RecoveredAvailabilityOverEntity" ScopeId="1" Offset="44" RealId="1044"/>
               <Counter Type="51" Description="LostAvailabilityOverEngineForEntities" ScopeId="1" Offset="45" RealId="1045"/>
               <Counter Type="52" Description="RecoveredAvailabilityOverEngineForEntities" ScopeId="1" Offset="46" RealId="1046"/>
               <Counter Type="53" Description="UnableToDeliverToClient" ScopeId="1" Offset="47" RealId="1047"/>
               <Counter Type="54" Description="LostConnectionForServerSession" ScopeId="1" Offset="48" RealId="1048"/>
               <Counter Type="55" Description="UnbindConnectionForServerSessionDueToInactivityTimeAnomaly" ScopeId="1" Offset="49" RealId="1049"/>
               <Counter Type="56" Description="CreatedConnectionForServerSession" ScopeId="1" Offset="50" RealId="1050"/>
               <Counter Type="57" Description="LostAvailabilityOverLocalServer" ScopeId="1" Offset="51" RealId="1051"/>
               <Counter Type="58" Description="RecoveredAvailabilityOverLocalServer" ScopeId="1" Offset="52" RealId="1052"/>
               <Counter Type="59" Description="LostAvailabilityOverEngineForLocalServers" ScopeId="1" Offset="53" RealId="1053"/>
               <Counter Type="60" Description="RecoveredAvailabilityOverEngineForLocalServers" ScopeId="1" Offset="54" RealId="1054"/>
            </RegisteredCounters>
         </Scope>
      </RegisteredCounterScopes>
      <RegisteredAlarms/>
   </oam.Module>
   <oam.Module Name="diameter::codec oam module" Counters="Enabled" Alarms="Enabled" PreffixAlarmComponents="Shown" SuffixAlarmComponents="Shown">
      <RegisteredCounterScopes>
         <Scope Id="2" Description="diameter::codec oam module">
            <RegisteredCounters>
               <Counter Type="0" Description="AvpDecode__NotEnoughBytesToCoverAvpHeaderLength" ScopeId="2" Offset="0" RealId="2000"/>
               <Counter Type="1" Description="AvpDecode__IncoherenceBetweenActivatedVBitAndZeroedVendorIDValueReceived" ScopeId="2" Offset="1" RealId="2001"/>
               <Counter Type="2" Description="AvpDecode__IncorrectLength" ScopeId="2" Offset="2" RealId="2002"/>
               <Counter Type="3" Description="AvpDecode__DataPartInconsistence" ScopeId="2" Offset="3" RealId="2003"/>
               <Counter Type="4" Description="AvpDecode__UnknownAvpWithMandatoryBit" ScopeId="2" Offset="4" RealId="2004"/>
               <Counter Type="5" Description="MessageDecode__NotEnoughBytesToCoverMessageHeaderLength" ScopeId="2" Offset="5" RealId="2005"/>
               <Counter Type="6" Description="MessageDecode__NotEnoughBytesToCoverMessageLength" ScopeId="2" Offset="6" RealId="2006"/>
               <Counter Type="7" Description="AvpValidation__EnumeratedAvpWithValueDoesNotComplyRestriction" ScopeId="2" Offset="10" RealId="2010"/>
               <Counter Type="8" Description="AvpValidation__AvpFlagsDoesNotFulfillTheDefinedFlagRules" ScopeId="2" Offset="11" RealId="2011"/>
               <Counter Type="9" Description="MessageValidation__UnknownOperationUnableToValidate" ScopeId="2" Offset="12" RealId="2012"/>
               <Counter Type="10" Description="MessageValidation__OperationHaveIncoherentFlags" ScopeId="2" Offset="13" RealId="2013"/>
               <Counter Type="11" Description="LevelValidation__MissingFixedRule" ScopeId="2" Offset="14" RealId="2014"/>
               <Counter Type="12" Description="LevelValidation__FailedRuleForCardinality" ScopeId="2" Offset="15" RealId="2015"/>
               <Counter Type="13" Description="LevelValidation__FailedRuleForCardinalityLessThanNeeded" ScopeId="2" Offset="16" RealId="2016"/>
               <Counter Type="14" Description="LevelValidation__FailedRuleForCardinalityMoreThanNeeded" ScopeId="2" Offset="17" RealId="2017"/>
               <Counter Type="15" Description="LevelValidation__FailedGenericAvpRuleForCardinalityFoundDisregardedItem" ScopeId="2" Offset="18" RealId="2018"/>
               <Counter Type="16" Description="LevelValidation__FoundDisregardedItemsAndGenericAVPWasNotSpecified" ScopeId="2" Offset="19" RealId="2019"/>
            </RegisteredCounters>
         </Scope>
      </RegisteredCounterScopes>

Communication system counters

Counter 'RequestReceived'

Total requests received by the process. They are received at the server access point (RequestReceivedOnServerSession) and, less frequently, from the server nodes through the client connection (RequestReceivedOnClientSession).
Depending on the type of process (client mode, server, mixed mode) This counter may contain one or both (mixed).

Counter 'AnswerReceived'

Total responses received by the process. Received from the server nodes through the client connection (AnswerReceivedOnClientSession) and, less frequently, at the point of access server (AnswerReceivedOnServerSession).
Depending on the type of process (client mode, server, mixed mode) This counter may contain one or both (mixed).

Counter 'RequestReceivedOnClientSession'

Petitions received in a client socket (requests from a server).

Counter 'AnswerReceivedOnClientSession'

Replies received in a client socket (responses from a server).

Counter 'RequestReceivedOnServerSession'

Petitions received in a server socket (requests from a client).

Counter 'AnswerReceivedOnServerSession'

Replies received in a server socket (responses from a client).

Counter 'RequestSentOK'

Correct requests submissions, either by a client socket (RequestSentOnClientSessionOK) or server (RequestSentOnServerSessionOK).

Counter 'RequestSentNOK'

Delivery failed requests, either by a socket (RequestSentOnClientSessionNOK) or server (RequestSentOnServerSessionNOK).

Counter 'AnswerSentOK'

Correct answer delivery, either a client socket (AnswerSentOnClientSessionOK) or server (AnswerSentOnServerSessionOK).

Counter 'AnswerSentNOK'

Same for failed responses, either a client socket (AnswerSentOnClientSessionNOK) or server (AnswerSentOnServerSessionNOK).

Counter 'RequestSentOnClientSessionOK'

Correct requests submissions on client socket.

Counter 'RequestSentOnClientSessionNOK'

Failed requests submissions on client socket.

Counter 'AnswerSentOnClientSessionOK'

Correct answers submissions on client socket.

Counter 'AnswerSentOnClientSessionNOK'

Failed responses submissions on client socket.

Counter 'RequestSentOnServerSessionOK'

Correct requests submissions on server socket.

Counter 'RequestSentOnServerSessionNOK'

Failed requests submissions on server socket.

Counter 'AnswerSentOnServerSessionOK'

Correct answers submissions on server socket.

Counter 'AnswerSentOnServerSessionNOK'

Failed answers submissions on server socket.

Counter 'RequestSentExpired'

Expirations of requests that were sent, whether by a client socket (RequestSentOnClientSessionExpired) or server (RequestSentOnServerSessionExpired).

Counter 'RequestSentOnClientSessionExpired'

Expirations of requests that were sent by a client socket.

Counter 'RequestSentOnServerSessionExpired'

Expirations of requests that were sent by a socket server.

Counter 'AnswerReceivedUnknown'

Receptions of unknown responses (there is no request in the context for the data transported sequence), either by a client socket (AnswerReceivedOnClientSessionUnknown) or server (AnswerReceivedOnServerSessionUnknown).

Counter 'AnswerReceivedOnClientSessionUnknown'

Receptions of unknown responses through a client socket (there is no request in the context for sequence data transported).

Counter 'AnswerReceivedOnServerSessionUnknown'

Receptions of unknown responses through a server socket (there is no request in the context for sequence data transported).

Counter 'CERSentOK'

Correct Capabilities-Exchange-Request submissions from the application. Although not usual, the server may also send this, but this process does not. Just send a CER in client mode from each client socket.

Counter 'CERSentNOK'

Failed Capabilities-Exchange-Request submissions from the application.

Counter 'CEAReceived'

Receptions of Capabilities-Exchange-Answer. Although not usual, the server may also receive, but not send CER process for socket server.

Counter 'CERReceived'

Receptions of Capabilities-Exchange-Request.

Counter 'CEASentOK'

Correct Capabilities-Exchange-Answer submissions from the application. Although it is unusual, a client may also respond to a CER, but this process does not. Just answer in server mode from a server socket.

Counter 'CEASentNOK'

Failed Capabilities-Exchange-Answer submissions from the application.

Counter 'DWRSentOK'

Correct Device-Watchdog-Request submissions from the application. Although not usual, the server may also send, but this process does not. Just send a DWR client mode from a client socket.

Counter 'DWRSentNOK'

Failed Device-Watchdog-Request submissions from the application.

Counter 'DWAReceived'

Receptions of Device-Watchdog-Answer. Although not usual, the server may also receive, but this process does not send DWR from socket server.

Counter 'DWRReceived'

Receptions of Device-Watchdog-Request.

Counter 'DWASentOK'

Correct Device-Watchdog-Answer submissions from the application. Although it is unusual, a client may also respond to a DWR, but this process does not. Just answer in server mode from a server socket.

Counter 'DWASentNOK'

Failed Device-Watchdog-Answer submissions from the application.

Counter 'DPRSentOK'

Correct Disconnect-Peer-Request submissions from the application.

Counter 'DPRSentNOK'

Failed Disconnect-Peer-Request submissions from the application.

Counter 'DPAReceived'

Receptions of Disconnect-Peer-Answer.

Counter 'DPRReceived'

Receptions of Disconnect-Peer-Request.

Counter 'DPASentOK'

Correct Disconnect-Peer-Answer submissions from the application.

Counter 'DPASentNOK'

Failed Disconnect-Peer-Answer submissions from the application.

Counter 'ServerSocketsOpened'

Opening a socket server.

Counter 'ServerSocketsClosed'

Closing a socket server.

Counter 'UnableToDeliverOverEntity'

Failure sending to an entity (Server). Failure occurs when sending to all his servers, and within each of them, all sockets.
Keep in mind that until all client sockets to a server are tested, it does not means unable to delivery to that server.

Counter 'LostAvailabilityOverClientSession'

Loss of availability in a client session. It occurs when a client connection is closed.

Counter 'RecoveredAvailabilityOverClientSession'

Recovery of availability in a client session. It occurs when reconnecting (or connecting for the first time) a client connection.

Counter 'LostAvailabilityOverServer'

Loss of availability in the connection to the server, and therefore, with all sockets.

Counter 'RecoveredAvailabilityOverServer'

Availability recovery from the server, and therefore, in any of their sockets.

Counter 'LostAvailabilityOverEntity'

Loss of connection availability to an entity, and therefore, with all its servers.

Counter 'RecoveredAvailabilityOverEntity'

Recovery of connection availability to an entity, and therefore, in any of its servers.

Counter 'LostAvailabilityOverEngineForEntities'

Loss of availability in the all the motor entities, and therefore, with all its servers.
The ADML process only configures an entity which, this counter is synchronized with 'LostAvailabilityOverEntity'.

Counter 'RecoveredAvailabilityOverEngineForEntities'

Recovery of availability in some of the motor entities, and therefore, in some of its servers.
The ADML process only configures an entity which, this counter is synchronized with 'RecoveredAvailabilityOverEntity'.

Counter 'UnableToDeliverToClient'

Failure sending to a client (through the local server). Occurs when sending through the socket used fails.
The sum of 'RequestSentOnServerSessionNOK' and 'AnswerSentOnServerSessionNOK'.

Counter 'LostConnectionForServerSession'

Loss of availability in a server session. Occurs when a server connection is closed.

Counter 'UnbindConnectionForServerSessionDueToInactivityTimeAnomaly'

Local closing due to inactivity on the transport session.

Counter 'CreatedConnectionForServerSession'

Creating a server connection (accept) initiated from a client.

Counter 'LostAvailabilityOverLocalServer'

Loss of availability of the local server. It happens when you close all your server connections.

Counter 'RecoveredAvailabilityOverLocalServer'

Recovery of availability of the local server. It occurs when one of its servers connections is established.

Counter 'LostAvailabilityOverEngineForLocalServers'

Loss of availability to the connections of all local servers.
The ADML process only configures a server access point, which, this counter is synchronized with 'LostAvailabilityOverLocalServer'.

Counter 'RecoveredAvailabilityOverEngineForLocalServers'

Recovery availability in connection to the local servers of the engine and therefore, in any of them.
The ADML process only configures a server access point, which, this counter is synchronized with 'RecoveredAvailabilityOverLocalServer'.

Counters for the encoding/decoding system

Counter 'AvpDecode__NotEnoughBytesToCoverAvpHeaderLength'

An AVP whose length fails to meet even the minimum length of the header of an AVP.

Counter 'AvpDecode__IncoherenceBetweenActivatedVBitAndZeroedVendorIDValueReceived'

An inconsistency between the flags and the value of the vendor-id is detected. It may be because the V bit is set but the transported value for the vendor-id is invalid, or that being the bit off, the vendor-id however have non-zero indicating that it is vendor-specific.

Counter 'AvpDecode__IncorrectLength'

Failed length of an AVP. Inconsistent length information (eg a grouped does not have a multiple of 4 as length, etc.).

Counter 'AvpDecode__DataPartInconsistence'

Fault in the data portion of an AVP. It is easily detected when it comes to data formats known and fixed length, or address types that do not meet your specification (it is not IPv4, IPv6, etc.).

Counter 'AvpDecode__UnknownAvpWithMandatoryBit'

When decoding an AVP with the M bit (mandatory) on, and nothing is known about it (not defined in the dictionary), the application should reject the message. There is a handler for this event that increases this counter and triggers an alarm.

Counter 'MessageDecode__NotEnoughBytesToCoverMessageHeaderLength'

The message which length fails to meet even the minimum length of the diameter of a message header.

Counter 'MessageDecode__NotEnoughBytesToCoverMessageLength'

Failed length of a message. Inconsistent length information internally.

Counter 'AvpValidation__EnumeratedAvpWithValueDoesNotComplyRestriction'

A validation failure for a enumerated AVP whose value is outside the range defined in the dictionary.

Counter 'AvpValidation__AvpFlagsDoesNotFulfillTheDefinedFlagRules'

Failure of flags validation of an AVP with respect to the constraints defined in the dictionary.

Counter 'MessageValidation__UnknownOperationUnableToValidate'

Inability to validate a message because ignored its structure (not defined in the dictionary).

Counter 'MessageValidation__OperationHaveIncoherentFlags'

Inconsistent message flags. In practice it is impossible because it is shielded by the dtd message.

Counter 'LevelValidation__MissingFixedRule'

Missing fixed AVP in the message or within a grouped AVP.

Counter 'LevelValidation__FailedRuleForCardinality'

Failed cardinality rule for AVP within a message or a grouped AVP.
It is the sum of the following two:

Counter 'LevelValidation__FailedRuleForCardinalityLessThanNeeded'

Failed cardinality rule for AVP within a message or a grouped AVP, for lack of items.

Counter 'LevelValidation__FailedRuleForCardinalityMoreThanNeeded'

Failed cardinality rule for AVP within a message or a grouped AVP, due to excess of items.

Counter 'LevelValidation__FailedGenericAvpRuleForCardinalityFoundDisregardedItem'

Failed cardinality rule of AVP due to find generic elements outside the structure that do not meet the cardinality constraint.

Counter 'LevelValidation__FoundDisregardedItemsAndGenericAVPWasNotSpecified'

There are Elements outside the structure and generic AVP has not been defined.

Updated by Eduardo Ramos (Edu1770) 9 months ago · 16 revisions