Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Eclipse Titan » Executing ETSI Diameter Rx test cases
Executing ETSI Diameter Rx test cases [message #1721582] Thu, 28 January 2016 13:42 Go to next message
uttam hoode is currently offline uttam hoodeFriend
Messages: 4
Registered: January 2016
Junior Member
I downloaded Diameter Rx test cases from ETSI svn. I would like to know how to generate cc/hh files and run the test cases. When I ran makefilegen command, it only generated a Makefile.
Any help is greatly appreciated.

Regards,
hoode



Re: Executing ETSI Diameter Rx test cases [message #1721672 is a reply to message #1721582] Fri, 29 January 2016 06:17 Go to previous messageGo to next message
Muhammad Uzair is currently offline Muhammad UzairFriend
Messages: 35
Registered: November 2015
Member
Hi,

I am assuming you have completed the setup as present in titan documentation. You have to compile your code using make command. If the test suit you downloaded is complete and is not using TTCN3 features which are unsupported by titan, compilation will succeed. Pleas follow instructions in Eclipse_Executor_userguide to execute the required test cases.

Regards,
Uzair
Re: Executing ETSI Diameter Rx test cases [message #1721681 is a reply to message #1721672] Fri, 29 January 2016 07:53 Go to previous messageGo to next message
Elemer Lelik is currently offline Elemer LelikFriend
Messages: 807
Registered: January 2015
Senior Member
Hi Uttam,

I will assume you are referring to this test suite:

http://www.etsi.org/deliver/etsi_ts/101500_101599/10158003/02.01.01_60/ts_10158003v020101p0.zip

I will also assume that you are familiar with TTCN-3 and Titan, you have a working installation of Titan and you have already run smaller tests with it.

What I would first do is to chart the importation dependencies between libraries and then start compiling them from the bottom up: first LibCommon, then LibCommon+LibDiameter, then LibCommon+LIbSip etc. and finally all of them together.
This will simplify correcting any issues encountered.

(one hint here :
port type declarations will have to be appended with a 'with {extension "internal"}' clause so Titan will not look for the C++ code of the test ports. Later on their code will have to be added of course)


Once the whole suite is compileable, we will have to look into adapting it to Titan in the two non-standardized areas: encoding and test ports.

I suggest you start working with this on your own; whenever you have questions we'll try to help.


Best regards

Elemer




Re: Executing ETSI Diameter Rx test cases [message #1721887 is a reply to message #1721681] Mon, 01 February 2016 10:50 Go to previous messageGo to next message
Elemer Lelik is currently offline Elemer LelikFriend
Messages: 807
Registered: January 2015
Senior Member
Hi Uttam,


I looked closer into this and I see now parts where adaptations are needed; if you want, I can walk you through it; however your active participation will be needed, especially
in the three areas that are not standardized, that is 1) external functions 2) test ports 3) encoding.

If you are interested in this, please let me know.

Best regards

Elemer






Re: Executing ETSI Diameter Rx test cases [message #1722158 is a reply to message #1721887] Wed, 03 February 2016 07:16 Go to previous messageGo to next message
uttam hoode is currently offline uttam hoodeFriend
Messages: 4
Registered: January 2016
Junior Member
Hi Elemer/Uzair,

Thanks a lot for the response.

Elemer: Kindly share the details.

Regards,
Uttam
Re: Executing ETSI Diameter Rx test cases [message #1722164 is a reply to message #1722158] Wed, 03 February 2016 08:11 Go to previous messageGo to next message
Elemer Lelik is currently offline Elemer LelikFriend
Messages: 807
Registered: January 2015
Senior Member
Hi Uttam,

I'm thinking more along the line of a step-by-step walk-through ;

but first things first : I'd recommend you to download the latest source code of Titan - currently is at revision 5.4.0 - and build Titan for your platform. If you encounter problems, please let me know you platform of choice -preferably a mainstream Linux - and I'll see if I can help.

Once you have Titan installed, we can proceed: I mentioned that we should work ourselves up the direction of imports, so let's start with LibCommon:

go to the directory LibCommon and create a Makefile

makefilegen *.ttcn


(don't worry about options of makefilegen right now, our first target is to make everything compile-able)

Let's concentrate on errors first so lets switch off warning in the generated Makefile:
change:

COMPILER_FLAGS = -L 

to:
COMPILER_FLAGS = -L  -w



and compile:

make


at first, Titan will complain about something like:
 undefined reference to `LibCommon__Sync::SyncPort::~SyncPort()'


and the reason for this is that there is a port type declaration in LibCommon_Sync.ttcn

type port SyncPort message { inout SyncCmd }


and Titan expects to find the code of the test port.


However , the Sync port will be used as an internal port
(see DiameterRx_TestConfiguration.ttcn line 69:

           connect(p_diameterComponent_ims:syncPort, self:syncPort) ;


so we can declare it as such:

        type port SyncPort message { inout SyncCmd }
        with { extension "internal"}



and this will settle Titan.

So LIbCommon should be OK Now.

Please let me know if you reached this and we'll continue from here.


Best regards

Elemer
Re: Executing ETSI Diameter Rx test cases [message #1723836 is a reply to message #1721582] Thu, 18 February 2016 11:05 Go to previous messageGo to next message
uttam hoode is currently offline uttam hoodeFriend
Messages: 4
Registered: January 2016
Junior Member
After installing TTCN3 tool I tried to compile LibCommon.
I am getting below error

[root@localhost LibCommon]# makefilegen -v
Makefile Generator for the TTCN-3 Test Executor
Product number: CRL 113 200/5 R4A
Build date: Nov 13 2015 14:22:11
Compiled with: GCC 4.8.2

Copyright (c) 2000-2015 Ericsson Telecom AB

$cd LibCommon
$makefilegen *.ttcn
Generating Makefile skeleton...
Makefile skeleton was generated.


added -w option to COMPILER_FLAGS

$ make
/home/kodiak/TTCN3/bin/compiler -L -w \
LibCommon_AbstractData.ttcn LibCommon_BasicTypesAndValues.ttcn LibCommon_DataStrings.ttcn LibCommon_Sync.ttcn LibCommon_TextStrings.ttcn LibCommon_Time.ttcn LibCommon_VerdictControl.ttcn  - LibCommon_AbstractData.ttcn LibCommon_BasicTypesAndValues.ttcn LibCommon_DataStrings.ttcn LibCommon_Sync.ttcn LibCommon_TextStrings.ttcn LibCommon_Time.ttcn LibCommon_VerdictControl.ttcn
Notify: Parsing TTCN-3 module `LibCommon_AbstractData.ttcn'...
Notify: Parsing TTCN-3 module `LibCommon_BasicTypesAndValues.ttcn'...
Notify: Parsing TTCN-3 module `LibCommon_DataStrings.ttcn'...
Notify: Parsing TTCN-3 module `LibCommon_Sync.ttcn'...
Notify: Parsing TTCN-3 module `LibCommon_TextStrings.ttcn'...
Notify: Parsing TTCN-3 module `LibCommon_Time.ttcn'...
Notify: Parsing TTCN-3 module `LibCommon_VerdictControl.ttcn'...
Notify: Checking modules...
LibCommon_BasicTypesAndValues.ttcn: In TTCN-3 module `LibCommon_BasicTypesAndValues':
 LibCommon_BasicTypesAndValues.ttcn:58.5-41: In type definition `UInt1':
  LibCommon_BasicTypesAndValues.ttcn:58.58-65: error: in variant attribute, at or before token `unsigned': syntax error, unexpected XIdentifier, expecting $end
 LibCommon_BasicTypesAndValues.ttcn:59.5-41: In type definition `UInt2':
  LibCommon_BasicTypesAndValues.ttcn:59.58-65: error: in variant attribute, at or before token `unsigned': syntax error, unexpected XIdentifier, expecting $end
 LibCommon_BasicTypesAndValues.ttcn:60.5-41: In type definition `UInt3':
  LibCommon_BasicTypesAndValues.ttcn:60.58-65: error: in variant attribute, at or before token `unsigned': syntax error, unexpected XIdentifier, expecting $end
 LibCommon_BasicTypesAndValues.ttcn:61.5-41: In type definition `UInt4':
  LibCommon_BasicTypesAndValues.ttcn:61.58-65: error: in variant attribute, at or before token `unsigned': syntax error, unexpected XIdentifier, expecting $end
 LibCommon_BasicTypesAndValues.ttcn:62.5-41: In type definition `UInt5':



Regards,
Uttam
Re: Executing ETSI Diameter Rx test cases [message #1723842 is a reply to message #1723836] Thu, 18 February 2016 12:17 Go to previous messageGo to next message
Elemer Lelik is currently offline Elemer LelikFriend
Messages: 807
Registered: January 2015
Senior Member
Hi Uttam,

the difference between you results and mine are due to the fact that I'm using the latest version and you are using R4A.

Anyhow, what you experienced is exactly what I wanted to talk about next.


The errors you see, e.g.:
LibCommon_BasicTypesAndValues.ttcn: In TTCN-3 module `LibCommon_BasicTypesAndValues':
 LibCommon_BasicTypesAndValues.ttcn:58.5-41: In type definition `UInt1':
  LibCommon_BasicTypesAndValues.ttcn:58.58-65: error: in variant attribute, at or before token `unsigned': syntax error, unexpected XIdentifier, expecting $end

  etc.


are due to the fact that , as Diameter is a binary protocol, the compiler has to be instructed about how the structures have to be encoded into binary data.
This is done with decorating the types with encoding instructions;

for instance in LibCommon_BasicTypesAndValues

   type integer  UInt32 (0 .. c_uInt32Max) with {variant "unsigned 32 bit"};


means that an integer UInt32 has to be encoded on 32 bits; the codec will take care of this automatically.

Problem is , as this suite was not compiled with Titan, but with another tool, these instructions make no sense from Titan's perspective so it throws an error.
( in the latest build of Titan this can be switched off, so Titan disregards these errors , offering the possibility to the user to fix structures first).

Titan has a very similar concept of codecs that can be controlled with "variant" instructions, but of course the implementation details are different.
(If you wish please check the four -part series about the RAW codec published in this forum).

If you remove the with {variant "xxxxxx"}; instructions , the compilation errors will disappear, but Titan will be none the wiser about how to encode these structures
(to be accurate, Titan will apply default encoding instructions everywhere, which is probably not pertinent).
So besides removing the alien instructions, the code has to be redecorated with the ones Titan understands.
This is fairly straightforward for simple types, it becomes trickier later for structures.


I have attached the three files that are relevant from this perspective, and which I have made compatible with Titan.
Please observe the differences.

Now your compilation should be successful.

Let's continue from here.

BR

Elemer
Re: Executing ETSI Diameter Rx test cases [message #1725038 is a reply to message #1723842] Mon, 29 February 2016 09:49 Go to previous messageGo to next message
Elemer Lelik is currently offline Elemer LelikFriend
Messages: 807
Registered: January 2015
Senior Member
OK, let's resume from the point we left it..
We'll continue with LibDiameter which imports from LibCommon.


If you extract the attached file into a directory say Diam_RX_ETSI, two directories LibCommon and LibDiameter will result.

The protocol description for Diameter is contained in LibDiameter/LibDiameter_TypesAndValues.ttcn. Diameter being a binary encoded protocol , the type descriptions are decorated with encoding variants, but not intelligible for Titan (see the previous discussion). We are facing two options: either we replace the protocol description entirely with one that is Titan friendly (see https://github.com/eclipse/titan.ProtocolModules.DIAMETER_ProtocolModule_Generator) or we keep the same structures and change only the encoding instructions to ones Titan understands.
As the Titan-friendly solution uses structures that are quite far from the ones declared in LibDiameter_TypesAndValue, changing the encoding instructions promises to be a lot less painful. If the structures at the foundation of test cases change, this will propagate through templates , functions etc. through the whole suite, so we should try to keep as close to the original structures as possible.

so let's check first LibCommon

cd LibCommon
make


should throw no errors

Let's move to LibDiameter:

 cd ../LibDiameter/


create simlinks:

./ install.script


where install.script looks like this:
#!/bin/sh

 ln -s ../LibCommon/LibCommon_AbstractData.ttcn     .
ln -s ../LibCommon/LibCommon_BasicTypesAndValues.ttcn     .
ln -s ../LibCommon/LibCommon_DataStrings.ttcn     .
ln -s ../LibCommon/LibCommon_Sync.ttcn     .
ln -s ../LibCommon/LibCommon_TextStrings.ttcn     .
ln -s ../LibCommon/LibCommon_Time.ttcn     .
ln -s ../LibCommon/LibCommon_VerdictControl.ttcn     .


generate the Makefile

makefilegen -f   *.ttcn


disable warnings in the Makefile:

# Flags for the TTCN-3 and ASN.1 compiler:
COMPILER_FLAGS = -L  -w


and run make

As the files are already corrected, the compilation should succeed.

However , if you run diff between these files and the modified ones, a heap of differences will show. I will explain them , not in detail, but in categories.


1. Runs-on compatibility of components

If we compile the original files, errors as below are thrown:

 LibDiameter_Steps.ttcn:1057.15-1059.15: In if statement:
   LibDiameter_Steps.ttcn:1058.19-64: In function instance:
    LibDiameter_Steps.ttcn:1058.19-64: error: Runs on clause mismatch: A definition that runs on component type `@LibDiameter_Interface.DiameterComponent' cannot call function `@LibCommon_Sync.f_selfOrClientSyncAndVerdict', which runs on `@LibCommon_Sync.SelfSyncComp'


Indeed in LibDiameter_Steps.ttcn , line nr. 1058

a function f_selfOrClientSyncAndVerdict is invoked on DiameterComponent:

              if (vc_serverStop==false) {
                  f_selfOrClientSyncAndVerdict("error", e_error);
              }
			  


in LibCommon_Sync this function is declared as running on
SelfSyncComp:

	      function f_selfOrClientSyncAndVerdict( in charstring p_syncPoint,
                           in FncRetCode p_ret)
      runs on SelfSyncComp {	


According to the TTCN-3 core language standard part1,
par. 6.3.3 Compatibility of component types


Runs on compatibility: a function or altsteps referring to component type "A" in its runs on clause may be
called or started on a component instance of type 'B' if all the definitions of "A" have identical definitions in
"B".


so running a function declared on one component type on a compatible component type should not present a problem. Titan does not acknowledge compatibility implicitly, this has to be indicated explicitly by extending the base component:

in LibDiameter_Interface

type component DiameterComponent  --->type component DiameterComponent extends SelfSyncComp


Thus , the following declarations will become redundant

type component DiameterComponent extends SelfSyncComp
    {
  :
  

      // parts needed for Client/SelfSyncComp type compatibility
      var 	StringStack v_stateStack := c_initStringStack;
      port 	SyncPort 	syncSendPort;
      port 	SyncPort 	syncPort;
      timer tc_sync 	:= PX_TSYNC_TIME_LIMIT;
:  
  }
  


and will have to be removed:
 type component DiameterComponent extends SelfSyncComp
    {
  :
  
        // parts needed for Client/SelfSyncComp type compatibility
 /*     var 	StringStack v_stateStack := c_initStringStack;
      port 	SyncPort 	syncSendPort;
      port 	SyncPort 	syncPort;
      timer tc_sync 	:= PX_TSYNC_TIME_LIMIT;
  */


  
  :  
  }



2. Test ports

in LibDiameter_Interface

test port declarations have been made internal:

 type port LowerLayerPPort message {
          inout Lower_Layer_Primitive}; //LLP

    type port DiameterPort message {
          inout DIAMETER_MSG}; //DIAMETER_MSG


changed to
 type port LowerLayerPPort message {
          inout Lower_Layer_Primitive} with { extension "internal"}; //LLP

    type port DiameterPort message {
          inout DIAMETER_MSG} with { extension "internal"}; //DIAMETER_MSG


We'll come back to this later.


3. Other issues

The order of fields in some templates had to be re-arranged to match the
types, as indicated by such errors:

 LibDiameter_Templates.ttcn:2270.40-74: In template for record field `supported_Vendor_Id':
   LibDiameter_Templates.ttcn:2270.41-73: In component 1:
    LibDiameter_Templates.ttcn:2270.41-73: error: Type mismatch: a value or template of type `@LibDiameter_TypesAndValues.Supported_Vendor_Id_AVP' was expected instead of `@LibDiameter_TypesAndValues.Vendor_Id_AVP'


4. Binary encoding


At start , no type has encoding declared:

 LibDiameter_Steps.ttcn:657.17-662.17: In if statement:
       LibDiameter_Steps.ttcn:658.21-102: In variable assignment:
        LibDiameter_Steps.ttcn:658.60-102: In the first operand of operation `/':
         LibDiameter_Steps.ttcn:658.60-100: In the operand of operation `lengthof()':
          LibDiameter_Steps.ttcn:658.69-99: In the parameter of encvalue():
           LibDiameter_TypesAndValues.ttcn:6212.22-6262.17: error: No coding rule specified for type '@LibDiameter_TypesAndValues.CCA_MSG'


to add it, we need :

a) a final with { encode "RAW" } instruction at the end of the module

b) encoding instructions on the top-level structure:

type union DIAMETER_MSG {

} with { variant "......."}


c) external function declarations

external function f_DIAMETER_Enc(in DIAMETER_MSG pl_pdu) return octetstring
 with { extension "prototype(convert) encode(RAW)" };

external function f_DIAMETER_Dec(in octetstring pl_oct) return DIAMETER_MSG
 with { extension "prototype(convert) decode(RAW)" };


d) and most importantly , all encoding variants changed to their equivalents in Titan.


Another small issue that had to be corrected: the enumerated type command codes are listed twice , once for receiving, once for sending , but they have the same value in both directions, so instead of AAR_E and AAA_E, only one code AAR_AAA_E has to be used.


Next , we will test this new Diameter type declaration.

Best regards

Elemer

[Updated on: Mon, 29 February 2016 15:50]

Report message to a moderator

Re: Executing ETSI Diameter Rx test cases [message #1725140 is a reply to message #1725038] Tue, 01 March 2016 08:52 Go to previous messageGo to next message
Elemer Lelik is currently offline Elemer LelikFriend
Messages: 807
Registered: January 2015
Senior Member
Hi,

As there is no one-to-one translation between encoding variants of the "other" tool and of Titan , the new version of LibDiameter_TypesAndValues has to be considered untested. By the way, my intention is not to produce a fully functional and ready to be deployed code, but to show a migration path to Titan. As part of this migration , I will also point out ways to test the new, "Titanized" code wherever feasible.

First , let's have a glimpse int the workings of the binary (RAW) codec:




type union DIAMETER_MSG {
      CER_MSG    cER_MSG,   
      CEA_MSG    cEA_MSG,   
     :
      AAA_MSG    aAA_MSG,   
      UNKNOWN_MSG    uNKNOWN_MSG
    }  with { variant "TAG (
      cER_MSG,  header.cmdcode =        CER_CEA_E;
      cEA_MSG,  header.cmdcode =        CER_CEA_E;
     :
      aAA_MSG,  header.cmdcode =        AAR_AAA_E; 
      uNKNOWN_MSG,  OTHERWISE       ; 
      )"}




The attribute TAG will identify messages based on the command code. To distinguish between sending and receiving direction(which can have the same command code for e.g. CER and CEA), the value of header.cmdflags.r_bit is checked via the PRESENCE attribute:



   type record  CER_MSG{
        //Ref: RFC3588 5.3.1.  Capabilities-Exchange-Request
        DiameterHeader                         header,//<CER> ::= < Diameter Header: 257, REQ >
        Origin_Host_AVP                     origin_Host,//required
        Origin_Realm_AVP                     origin_Realm,
        set length (1..infinity) of Host_IP_Address_AVP host_IP_Address,
        Vendor_Id_AVP                         vendor_Id,
        Product_Name_AVP                     product_Name,//required
        set of Origin_State_Id_AVP            origin_State_Id optional,
        set of Supported_Vendor_Id_AVP        supported_Vendor_Id optional,
        set of Auth_Application_Id_AVP        auth_Application_Id optional,
        set of Inband_Security_Id_AVP        inband_Security_Id optional,
        set of Acct_Application_Id_AVP        acct_Application_Id optional,
        set of Vendor_Specific_Appl_Id_AVP    vendor_Specific_Application_Id optional,
        Firmware_Revision_AVP                firmware_Revision optional,
        set of AVP_Type                     aVP_Type optional
      }
      with {
        variant  "PRESENCE( header.cmdflags.r_bit = '1'B)" ;
        variant (header) "LENGTHTO(header,origin_Host,origin_Realm,host_IP_Address,vendor_Id,product_Name,origin_State_Id ,supported_Vendor_Id ,auth_Application_Id ,inband_Security_Id ,acct_Application_Id ,vendor_Specific_Application_Id ,firmware_Revision ,aVP_Type
        )";
        variant (header) "LENGTHINDEX(msglen)"; 

      }  

      type record  CEA_MSG{
        //Ref: RFC3588 5.3.2.  Capabilities-Exchange-Answer
        DiameterHeader                         header,//<CEA> ::= < Diameter Header: 257 >
        Result_Code_AVP                        result_Code,//required
        Origin_Host_AVP                     origin_Host,
        Origin_Realm_AVP                     origin_Realm,
        set length (1..infinity) of Host_IP_Address_AVP             host_IP_Address,
        Vendor_Id_AVP                         vendor_Id,
        Product_Name_AVP                     product_Name,//required
        Origin_State_Id_AVP                    origin_State_Id optional,
        Error_Message_AVP                    error_Message optional,
        set of Failed_AVP                    failed optional,
        set of Supported_Vendor_Id_AVP        supported_Vendor_Id optional,
        set of Auth_Application_Id_AVP        auth_Application_Id optional,
        set of Inband_Security_Id_AVP        inband_Security_Id optional,
        set of Acct_Application_Id_AVP        acct_Application_Id optional,
        set of Vendor_Specific_Appl_Id_AVP     vendor_Specific_Application_Id optional,
        Firmware_Revision_AVP                firmware_Revision optional,
        set of AVP_Type                     aVP_Type optional
      }  with {
        variant  "PRESENCE( header.cmdflags.r_bit = '0'B)" ;
        variant (header) "LENGTHTO(header,result_Code,origin_Host,origin_Realm,host_IP_Address,vendor_Id,product_Name,origin_State_Id ,error_Message ,               failed ,supported_Vendor_Id ,auth_Application_Id ,inband_Security_Id ,acct_Application_Id ,vendor_Specific_Application_Id ,firmware_Revision ,aVP_Type)";
        variant (header) "LENGTHINDEX(msglen)";
      } 	  
          


The header.msglen value is automatically calculated by the codec in the encoding direction to be the sum of partial lengths, so in the templates it can be set to any arbitrary value, usually 0.


For a full analysis of the RAW codec, see the reference guide and my previous articles on the subject. Until not tested, the encoding variants can contain errors not obvious at the first glance; recommendation is that it should be comprehensively tested with a wide variety of templates.

The tests I have applied are the following:

A) first, an encoding-decoding loop

module RAWTest3

{
    //LibDiameter
    import from LibDiameter_TypesAndValues all;
    import from LibDiameter_Templates all;



function f_diam(in DIAMETER_MSG p_diam)

{


log("......................................................................")
log("Message ", p_diam)

log("Encode ", f_DIAMETER_Enc(p_diam))
log("Decode",  f_DIAMETER_Dec(f_DIAMETER_Enc(p_diam)))



log (">>>>>>>>>>>>>>>>>>>>>>>",match(p_diam,f_DIAMETER_Dec(f_DIAMETER_Enc(p_diam))))

}

control

{


f_diam({aAR_MSG:=valueof(m_AAR_dummy)})
f_diam({aCR_MSG:=valueof(m_ACR_dummy)})
f_diam({aSR_MSG:=valueof(m_ASR_dummy)})
f_diam({cCR_MSG:=valueof(m_CCR_dummy)})
f_diam({cER_MSG:=valueof(m_CER_dummy)})
f_diam({dWR_MSG:=valueof(m_DWR_dummy)})
f_diam({dPR_MSG:=valueof(m_DPR_dummy)})
f_diam({lIR_MSG:=valueof(m_LIR_dummy)})
f_diam({mAR_MSG:=valueof(m_MAR_dummy)})
f_diam({pPR_MSG:=valueof(m_PPR_dummy)})
f_diam({pUR_MSG:=valueof(m_PUR_dummy)})
f_diam({rAR_MSG:=valueof(m_RAR_dummy)})
f_diam({rTR_MSG:=valueof(m_RTR_dummy)})
f_diam({sAR_MSG:=valueof(m_SAR_dummy)})
f_diam({sTR_MSG:=valueof(m_STR_dummy)})
f_diam({uAR_MSG:=valueof(m_UAR_dummy)})
f_diam({uDR_MSG:=valueof(m_UDR_dummy)})


f_diam({aAA_MSG:=valueof(m_AAA_dummy)})
f_diam({aCA_MSG:=valueof(m_ACA_dummy)})
f_diam({aSA_MSG:=valueof(m_ASA_dummy)})
f_diam({cCA_MSG:=valueof(m_CCA_dummy)})
f_diam({cEA_MSG:=valueof(m_CEA_dummy)})
f_diam({dWA_MSG:=valueof(m_DWA_dummy)})
f_diam({dPA_MSG:=valueof(m_DPA_dummy)})
f_diam({lIA_MSG:=valueof(m_LIA_dummy)})
f_diam({mAA_MSG:=valueof(m_MAA_dummy)})
f_diam({pPA_MSG:=valueof(m_PPA_dummy)})
f_diam({pUA_MSG:=valueof(m_PUA_dummy)})
f_diam({rAA_MSG:=valueof(m_RAA_dummy)})
f_diam({rTA_MSG:=valueof(m_RTA_dummy)})
f_diam({sAA_MSG:=valueof(m_SAA_dummy)})
f_diam({sTA_MSG:=valueof(m_STA_dummy)})
f_diam({uAA_MSG:=valueof(m_UAA_dummy)})
f_diam({uDA_MSG:=valueof(m_UDA_dummy)})


} //endcontrol


               
           
}



which results in MyExample.log (attached)

The match will return an "unmatched" indication as the message length in the original template is set to 0, but the decoded template already contains the correct value calculated by the codec.

17:06:24.849785 RAWTest3.ttcn:27 >>>>>>>>>>>>>>>>>>>>>>>.aAR_MSG.header.msglen := 0 with 92 unmatched



B) second, testing the codec against an independent implementation

for this I have used the "Titan-friendly" Diameter Protocol Module Generator (see https://github.com/eclipse/titan.ProtocolModules.DIAMETER_ProtocolModule_Generator);

I have collected encoded message samples from the previous log file, and decoded them :

module RAWTest

{


   
    import from DIAMETER_Types all;




control

{

                                                                                                          
 
log(f_DIAMETER_Dec( '0100005C01000109000000000000000000000000000001070200000B61626300000001080200000B61626300000001280200000B616263000000011B0200000B61626300000001250200000B61626300000001020200000C00000000'O                                                                                                                                                              
));                                                                                                             
log(f_DIAMETER_Dec( '0100005C0100010F000000000000000000000000000001070200000B61626300000001080200000B61626300000001280200000B616263000000011B0200000B61626300000001E00200000C00000001000001E50200000C00000000'O                                                                                                                                                              
));                                                                                                             
log(f_DIAMETER_Dec( '0100005C01000112000000000000000000000000000001070200000B61626300000001080200000B61626300000001280200000B616263000000011B0200000B61626300000001250200000B61626300000001020200000C00000000'O                                                                                                                                                              
));                                                                                                             
log(f_DIAMETER_Dec( '0100006801000110000000000000000000000000000001070200000B61626300000001080200000B61626300000001280200000B616263000000011B0200000B61626300000001020200000C00000000000001A00200000C000000010000019F0200000C00000000'O                                                                                                                                      
));                                                                                                             
log(f_DIAMETER_Dec( '0100005401000101000000000000000000000000000001080200000B61626300000001280200000B61626300000001010200000E00017F00000100000000010A0200000C000000000000010D0000000B61626300'O                                                                                                                                                                              
));                                                                                                             
log(f_DIAMETER_Dec( '0100002C01000118000000000000000000000000000001080200000B61626300000001280200000B61626300'O                                                                              
));                                                                                                             
log(f_DIAMETER_Dec( '010000380100011A000000000000000000000000000001080200000B61626300000001280200000B61626300000001110200000C00000000'O                                                      
));                                                                                                             
log(f_DIAMETER_Dec( '010000780100011D010000000000000000000000000001070200000B61626300000001020200000C00000000000001150200000C00000000000001080200000B61626300000001280200000B616263000000011B0200000B616263000000007A0200001A6161613A2F2F7777772E657473692E6F72670000'O                                                                                                      
));                                                                                                             
log(f_DIAMETER_Dec( '010000840100011E010000000000000000000000000001070200000B61626300000001020200000C00000000000001150200000C00000000000001080200000B61626300000001280200000B616263000000011B0200000B616263000000007A0200001A6161613A2F2F7777772E657473692E6F72670000000001890200000B73697000'O                                                                              
));                                                                                                             
log(f_DIAMETER_Dec( '0100007001000120010000000000000000000000000001070200000B61626300000001020200000C00000000000001150200000C00000000000001080200000B61626300000001280200000B616263000000011B0200000B61626300000000010200000B64626F000000017002000008'O                                                                                                                      
));                                                                                                             
log(f_DIAMETER_Dec( '0100008401000133010000010000000000000000000001070200000B616263000000010402000008000001150200000C00000000000001080200000B61626300000001280200000B616263000000011B0200000B61626300000002BC0300000CAF280000000002BF03000010AF280000000000000000025E0300000DAF28000000000000'O                                                                              
));                                                                                                             
log(f_DIAMETER_Dec( '0100006801000102000000000000000000000000000001070200000B61626300000001080200000B61626300000001280200000B616263000000011B0200000B61626300000001250200000B61626300000001020200000C000000000000011D0200000C00000000'O                                                                                                                                      
));                                                                                                             
log(f_DIAMETER_Dec( '0100007C0100011F010000000000000000000000000001070200000B61626300000001020200000C00000000000001150200000C00000000000001080200000B61626300000001280200000B61626300000001250200000B616263000000017F02000014000001800200000C000000000000011B0200000B61626300'O                                                                                              
));                                                                                                             
log(f_DIAMETER_Dec( '010000740100011C010000000000000000000000000001070200000B61626300000001020200000C00000000000001150200000C00000000000001080200000B61626300000001280200000B616263000000011B0200000B61626300000001770200000C00000000000001880200000C00000000'O                                                                                                              
));                                                                                                             
log(f_DIAMETER_Dec( '0100005C01000113000000000000000000000000000001070200000B61626300000001080200000B61626300000001280200000B616263000000011B0200000B61626300000001020200000C00000000000001270200000C00000001'O                                                                                                                                                              
));                                                                                                             
log(f_DIAMETER_Dec( '010000940100011B010000000000000000000000000001070200000B61626300000001020200000C00000000000001150200000C00000000000001080200000B61626300000001280200000B616263000000011B0200000B616263000000007A0200001A6161613A2F2F7777772E657473692E6F72670000000001820200000E6162636162630000000001830200000C00000000'O                                              
));                                                                                                             
log(f_DIAMETER_Dec( '0100006C01000132010000010000000000000000000001070200000B61626300000001150200000C00000000000001080200000B61626300000001280200000B616263000000011B0200000B61626300000002BC0300000CAF280000000002BF03000010AF28000000000000'O                                                                                                                              
));                                                                                                             
log(f_DIAMETER_Dec( '0100004400000109000000000000000000000000000001070200000B61626300000001080200000B61626300000001280200000B61626300000001020200000C00000000'O                              
));                                                                                                             
log(f_DIAMETER_Dec( '0100005C0000010F000000000000000000000000000001070200000B616263000000010C0200000C00000000000001080200000B61626300000001280200000B61626300000001E00200000C00000001000001E50200000C00000000'O
));   
log(f_DIAMETER_Dec( '0100004400000112000000000000000000000000000001070200000B616263000000010C0200000C00000000000001080200000B61626300000001280200000B61626300'O
));   
log(f_DIAMETER_Dec( '0100006800000110000000000000000000000000000001070200000B616263000000010C0200000C00000000000001080200000B61626300000001280200000B61626300000001020200000C00000000000001A00200000C000000010000019F0200000C00000000'O
));   
log(f_DIAMETER_Dec( '01000060000001010000000000000000000000000000010C0200000C00000000000001080200000B61626300000001280200000B61626300000001010200000E00017F00000100000000010A0200000C000000000000010D0000000B61626300'O
));   
log(f_DIAMETER_Dec( '01000038000001180000000000000000000000000000010C0200000C00000000000001080200000B61626300000001280200000B61626300'O
));   
log(f_DIAMETER_Dec( '010000380000011A0000000000000000000000000000010C0200000C00000000000001080200000B61626300000001280200000B61626300'O
));   
log(f_DIAMETER_Dec( '0100005C0000011D010000000000000000000000000001070200000B61626300000001020200000C000000000000010C0200000C00000000000001150200000C00000000000001080200000B61626300000001280200000B61626300'O
));   
log(f_DIAMETER_Dec( '0100005C0000011E010000000000000000000000000001070200000B61626300000001020200000C000000000000010C0200000C00000000000001150200000C00000000000001080200000B61626300000001280200000B61626300'O
));   
log(f_DIAMETER_Dec( '0100005C00000120010000000000000000000000000001070200000B61626300000001020200000C000000000000010C0200000C00000000000001150200000C00000000000001080200000B61626300000001280200000B61626300'O
));   
log(f_DIAMETER_Dec( '0100004C00000133010000010000000000000000000001070200000B616263000000010402000008000001150200000C00000000000001080200000B61626300000001280200000B61626300'O
));   
log(f_DIAMETER_Dec( '0100003800000102000000000000000000000000000001070200000B61626300000001080200000B61626300000001280200000B61626300'O
));   
log(f_DIAMETER_Dec( '0100005C0000011F010000000000000000000000000001070200000B61626300000001020200000C000000000000010C0200000C00000000000001150200000C00000000000001080200000B61626300000001280200000B61626300'O
));   
log(f_DIAMETER_Dec( '010000840000011C010000000000000000000000000001070200000B61626300000001020200000C000000000000010C0200000C00000000000001150200000C00000000000001080200000B61626300000001280200000B616263000000018502000020000001860200000B616263000000018702000009000000000000017002000008'O
));   
log(f_DIAMETER_Dec( '0100004400000113000000000000000000000000000001070200000B616263000000010C0200000C00000000000001080200000B61626300000001280200000B61626300'O
));   
log(f_DIAMETER_Dec( '0100005C0000011B010000000000000000000000000001070200000B61626300000001020200000C00000000000001150200000C000000000000010C0200000C00000000000001080200000B61626300000001280200000B61626300'O
));   
log(f_DIAMETER_Dec( '0100005800000132010000010000000000000000000001070200000B6162630000000104020000080000010C0200000C00000000000001150200000C00000000000001080200000B61626300000001280200000B61626300'O
));  


} //endcontrol



               
           
}


which , after formatting , resulted in the attached fMyExample.log,

from which it can be seen that the messages encoded with the new instructions are successfully decoded by an independent implementation.



Next , we will add a test port to Diameter.

Best regards

Elemer
Re: Executing ETSI Diameter Rx test cases [message #1725390 is a reply to message #1725140] Thu, 03 March 2016 08:53 Go to previous messageGo to next message
Elemer Lelik is currently offline Elemer LelikFriend
Messages: 807
Registered: January 2015
Senior Member
Hi all,

we are facing the following situation: we have a Diameter component with a southern port capable to receive and send Diameter messages:
    type port DiameterPort message {
          inout DIAMETER_MSG}  with { extension "internal"}


and we have to connect this port somehow to the SUT. Two options have been frequently used in our practice: one is the dual-faced test port , with many examples posted in this forum, and the other- in case a more complex logic has to be implemented-the use of a mapping component.
For a change, I will discuss the latter here, although the former would probably be sufficient for simple cases.
I have taken a Diameter mapping component from the /demo of https://github.com/eclipse/titan.ProtocolModules.DIAMETER_ProtocolModule_Generator, and modified it to suit our purposes: removed the parts relevant to the server functionality only (as we intend to connect as a client to our Diameter server) and I have also added a mapping functionality between the old structures, based on which this code was written, and the slightly different new structures. I have retained some parts (external functions) from DIAMETER_Types.ttcn and DIAMETER_EncDec.cc
while keeping the file names for easier identification.
The mapping component presents two options : it can either use SCTP or TCP as transport, so I have added both test ports from:

https://github.com/eclipse/titan.TestPorts.TCPasp and
https://github.com/eclipse/titan.TestPorts.SCTPasp


Let's see how mapping works ( function f_DIA_TCP_Mapping_Client() runs on DIAMETER_Mapping_CT):

- a TCP message is received from the TCP test port:

[] TCP_PCO.receive(ASP_TCP:?) -> value vl_TCP_msg
    {
      log("TCP Packet received");
      vl_DIA_msg := f_DIAMETER_Dec(vl_TCP_msg.data);
      vl_header:=f_xtractHeader(vl_DIA_msg);
      vl_DIA_comp := f_findInRT(
        v_RoutingTable, 
        vl_header.hop_by_hop_id, 
        vl_header.end_to_end_id
      );
      if (vl_DIA_comp != null) {
        DIA_PCO.send(vl_DIA_msg) to vl_DIA_comp;
        f_delFromRT(
          v_RoutingTable, 
          vl_header.hop_by_hop_id, 
          vl_header.end_to_end_id
        );
        log("Diameter message sent to the corresponding component");
      }




The Diameter message is extracted from the data section and decoded; headers are checked versus a routing table and then the Diameter message is sent on the upper port which connects to the Diameter component

-a Diameter message is received from the Diameter component

 [] DIA_PCO.receive(DIAMETER_MSG:?) -> value vl_DIA_msg sender vl_DIA_comp
    {
      log("DIA message received")
      vl_header:=f_xtractHeader(vl_DIA_msg);
      if (v_State == true) {
        if (vl_header.hop_by_hop_id == cl_zero and 
          vl_header.end_to_end_id == cl_zero) {
          vl_header.hop_by_hop_id := f_DIAMETER_genHopByHop();
          vl_header.end_to_end_id := f_DIAMETER_genEndToEnd();
        }
        vl_TCP_msg.data := f_DIAMETER_Enc(vl_DIA_msg);
        vl_TCP_msg.client_id := omit;
        TCP_PCO.send(vl_TCP_msg);
        v_RoutingTable[sizeof(v_RoutingTable)] := { 
          vl_header.hop_by_hop_id, 
          vl_header.end_to_end_id,
          vl_DIA_comp
        }
        log("Message sent via TCP");
      }
	  

The message is encoded and sent via TCP


A module parameter

 Transport   tsp_transport:=TCP;
type enumerated Transport { TCP(0), SCTP(1) }


was introduced to select TCP or SCTP.

For the configuration of ports , pls. check the client config files in /demo.


To check code consistency, uncompress the attached file into say Diam_RX_ETSI and then:

cd Diam_RX_ETSI/LibDiameter
./install.script
make

should return no error

So now we have a full Diameter stack consisting of a Diameter component , a mapping component and a TCP(or SCTP test port).

Next , we will move to the LibSIP folder.


Best regards
Elemer

[Updated on: Thu, 03 March 2016 09:00]

Report message to a moderator

Re: Executing ETSI Diameter Rx test cases [message #1725528 is a reply to message #1725390] Fri, 04 March 2016 08:06 Go to previous messageGo to next message
Elemer Lelik is currently offline Elemer LelikFriend
Messages: 807
Registered: January 2015
Senior Member
Hi all,
In case of LibSip , we are facing a similar dilemma as for LibDiameter, with a twist: LibSip has it's own custom codec , so we could not just simply rewrite the encoding instructions.
Luckily, the structures in LibSip_SIPTypesAndValues are quite similar to structures in the protocol description part of the SIPmsg test port, so we will substitute LibSip_SIPTypesAndValues with SIPmsg_Types, thus killing two birds with one stone: not only we have a protocol module, but also an attached test port as well.

If we look into LibSip_SIPTypesAndValues, which plays a central role in LibSip, we can see that the structure of e.g. a Request changes from

  type record Request
      {
      RequestLine		requestLine,
      MessageHeader 	msgHeader,
      MessageBody		messageBody optional,
      Payload			payload	    optional
      }


to

    type record PDU_SIP_Request
    {
      RequestLine               requestLine,
      MessageHeader             msgHeader,
      charstring                messageBody optional,
      Payload                   payload     optional
    }


in SIPmsg_Types.


Message Body is a structure in LibSip_SIPTypesAndValues and a characterstring in SIPmsg_Types.

The MesageBody structure looks like this:
   type union Message_Body{
        SDP_Message sdpMessageBody, 	// if there is only SDP part
        XmlBody xmlBody,				// if there is XML body
        MIME_Message mimeMessageBody, 	// if there is SDP and encapsulated ISUP part
        charstring sipfrag, 			// if content-Type is message/sipfrag (cp. NOTIFY, cp TS124147 A.4.3.1.2)
        charstring textplain,			// if content type is text/plain (for testing long messages)
        SimpleMsgSummary simpleMsgSummary, // RFC 3842
        octetstring smsMessage          // encoded SMS message 3GPP 23.040, 24.011
      };



and is a union of all possible content , mainly imported from adjacent files.
We will have to replace all these imported structures with their Titan-friendly equivalents.

Encoding-decoding of the message body is based on the Content-Type indication in message headers;
possible values are declared as constants:
 // SDP name application
    const charstring c_sdpAplication := "application/sdp";
     // XML name application
    const charstring c_xmlAplication := "application/xml";
     // XML name application
    const charstring c_xmlreginfoAplication := "application/reginfo+xml";
     // MIME name application
    const charstring c_mimeMultipart := "multipart/mixed";
     // IMS 3GPP name application
    const charstring c_ims3gppAplication := "application/3gpp-ims+xml";
      // IMS 3GPP name CW application
    const charstring c_ims3gppCwApplication := "application/vnd.3gpp.cw+xml";
      // IMS ETSI name MCID application
    const charstring c_imsEtsiMcidApplication := "application/vnd.etsi.mcid+xml";
      // IMS ETSI name CUG application
    const charstring c_imsEtsiCugApplication := "application/vnd.etsi.cug+xml";
      // IMS ETSI name Simservs application(TIP/TIR, ACR, CDIV, OIP/OIR, CUG)
    const charstring c_imsEtsiSimservsApplication := "application/vnd.etsi.simservs+xml";
      // OCTET-STREAM name application
    const charstring c_octetAplication := "application/octet-stream";
      // PLAIN-TEXT name application
    const charstring c_plainText := "text/plain";


Notice that for XML there are several alternatives; if we look into LibSip_XMLTypes, we can see that XmlBody is a union in itself:

 type union XmlBody {
    Mcid mcid,							// if there is XML Mcid
    Comm_div_info_type cdivn,			// if there is XML cdivn
    Simservs simservs,					// if there is XML simservs (Oip/r, Tip/r, Call Diversion, ICB, OCB ...)
    Conference_type conference,	        // if there is XML conf
    Ims_cw cw,							// if there is XML cw (defined in X_3gpp_ns_cw_1_0.ttcn3view) 
    Cug cug,							// if there is XML cug (defined in org_etsi_uri__ngn_params_xml_simservs_xcap.ttcn3view) 
    TIMS3GPP ims3gpp,					// if there is XML IMS 3GPP
    PSTN_transit pstnTransit,			// if there is XML PSTN_transit
    Resource_lists resourceLists,		// if there is XML Resource List data
    Reginfo regInfo,                    // if it is a registration event
    Geopriv geopriv                     // if it is  a Presence Information Data Format Location Object
  }


with referred structures imported from XSD files in /xsd:


module LibSip_XMLTypes {

import from http_www_w3_org_XML_1998_namespace language "XSD" all
with {
  extension "File:../xsd/xml.xsd"
}

:

// RFC 4119 Presence Information Data Format, Location Object extension 
import from urn_ietf_params_xml_ns_pidf_geopriv10 language "XSD" all
with {
  extension "File:../xsd/pidf_lo.xsd" 
}


Titan does not suport implicit mapping of XML schemas ( see ch 5 Mapping XML Schemas of Part 9 of the standard): Using XML schema with TTCN-3,
so this import will not work.
Instead , Titan assumes an explicit mapping, meaning that XML schemas will have to be converted to TTCN-3 files.
Before attempting the conversion, we have to notice that in simserv.xsd an artifact has been intoduced to counter the former tools inability to deal with substitution groups:


	<!-- ETSI substitutionGroup workaround, because TTCN-3 does not support mapping of substitutionGroup -->
	<xs:group name="absServiceGroup">
		<xs:choice>
		 <!-- default -->
		 <xs:element ref="ss:absService"/>
		 <!-- TIP-TRI -->
		 <xs:element ref="ss:terminating-identity-presentation-restriction"/>
		 <xs:element ref="ss:terminating-identity-presentation"/>
		  <!-- OIP-OIR -->
		 <xs:element ref="ss:originating--identity--presentation--restriction"/>
		 <xs:element ref="ss:originating--identity--presentation"/>
		  <!-- CDIV -->
		 <xs:element ref="ss:communication-diversion"/>
		  <!-- ACR-CB -->
		 <xs:element ref="ss:incoming-communication-barring"/>
		 <xs:element ref="ss:outgoing-communication-barring"/>
		  <!-- CUG -->
		 <!-- <xs:element ref="cug"/> -->
		</xs:choice>
	</xs:group>


This will have to be removed, as Titan understands substitution grops and considers this artifact redundant.


Now , after changing directories to /xsd, we can convert schemas:

xsd2ttcn -h *.xsd


(Note that during conversion, the converter utility also generates additional files UsefulTtcn3Types.ttcn and XSD.ttcn containing default types)

generate a Makefile:

makefilegen *.ttcn 


and build to verify the result:

make


Next let's move to ../ttcn and add XML encoding-decoding to LibSip_XMLTypes:


external function enc_XmlBody(in XmlBody pdu) return octetstring
with { extension "prototype (convert) encode(XER:XER_EXTENDED)" }

external function dec_XmlBody(in octetstring stream) return XmlBody
with { extension "prototype (convert) decode(XER:XER_EXTENDED)" }




group XmlTypes {
  type union XmlBody {
    Mcid mcid,							// if there is XML Mcid
    Comm_div_info_type cdivn,			// if there is XML cdivn
    Simservs simservs,					// if there is XML simservs (Oip/r, Tip/r, Call Diversion, ICB, OCB ...)
    Conference_type conference,	        // if there is XML conf
    Ims_cw cw,							// if there is XML cw (defined in X_3gpp_ns_cw_1_0.ttcn3view) 
    Cug cug,							// if there is XML cug (defined in org_etsi_uri__ngn_params_xml_simservs_xcap.ttcn3view) 
    TIMS3GPP ims3gpp,					// if there is XML IMS 3GPP
    PSTN_transit pstnTransit,			// if there is XML PSTN_transit
    Resource_lists resourceLists,		// if there is XML Resource List data
    Reginfo regInfo,                    // if it is a registration event
    Geopriv geopriv                     // if it is  a Presence Information Data Format Location Object
  }
}
}
with {
encode "XML";
variant "elementFormQualified";
variant "controlNamespace 'http://www.w3.org/2001/XMLSchema-instance' prefix 'xsi'";



Let's also add an install.script file containing symlinks:
#!/bin/sh

ln -s ../xsd/http_uri_etsi_org_ngn_params_xml_comm_div_info.ttcn     .
ln -s ../xsd/http_uri_etsi_org_ngn_params_xml_simservs_mcid.ttcn     .
ln -s ../xsd/http_uri_etsi_org_ngn_params_xml_simservs_pstn.ttcn     .
ln -s ../xsd/http_uri_etsi_org_ngn_params_xml_simservs_xcap.ttcn     .
ln -s ../xsd/http_www_w3_org_XML_1998_namespace.ttcn     .
ln -s ../xsd/NoTargetNamespace.ttcn     .
ln -s ../xsd/urn_3gpp_ns_cw_1_0.ttcn     .
ln -s ../xsd/urn_ietf_params_xml_ns_common_policy.ttcn     .
ln -s ../xsd/urn_ietf_params_xml_ns_conference_info.ttcn     .
ln -s ../xsd/urn_ietf_params_xml_ns_pidf_geopriv10_basicPolicy.ttcn     .
ln -s ../xsd/urn_ietf_params_xml_ns_pidf_geopriv10.ttcn     .
ln -s ../xsd/urn_ietf_params_xml_ns_pidf.ttcn     .
ln -s ../xsd/urn_ietf_params_xml_ns_reginfo.ttcn     .
ln -s ../xsd/urn_ietf_params_xml_ns_resource_lists.ttcn     .
ln -s ../xsd/urn_oma_xml_xdm_common_policy.ttcn     .
ln -s ../xsd/UsefulTtcn3Types.ttcn     .
ln -s ../xsd/XSD.ttcn     .





and we are good to go:

chmod +x install.script
./install.script
makefilegen *.ttcn 
make


should return no error.


Next, we will continue with the rest of components that are imported into LibSip_SIPTypesAndValues: SDP, SMS and SimpleMessageSummary.


Best regards
Elemer

[Updated on: Fri, 04 March 2016 08:10]

Report message to a moderator

Re: Executing ETSI Diameter Rx test cases [message #1725620 is a reply to message #1725528] Sat, 05 March 2016 06:53 Go to previous messageGo to next message
Elemer Lelik is currently offline Elemer LelikFriend
Messages: 807
Registered: January 2015
Senior Member
Hi all,

I have added all components that will be used by LibSip:

-LibCommon (cleared in the first step)
-SDP (a TEXT-coded protocol module which will replace LibSip_SDPTypes)
-MIME (a flex/bison-based TEXT coded protocol module which will replace Mime declarations at the end of LibSip_SIPTypesAndValues)
-SIPmsg (a flex/bison-based TEXT coded protocol module -and associated test port- which will replace the bulk of the content in LibSip_SIPTypesAndValues)

plus files covering SMS and SimpleMessageSummary, these two with encoding-related small adaptations to Titan:



module LibSip_SimpleMsgSummaryTypes { // RFC 3842


//1. External function declaration   
external function enc_SMS(in SimpleMsgSummary pdu) return charstring
with { extension "prototype(convert) encode(TEXT)" };
external function dec_SMS(in charstring stream) return SimpleMsgSummary
with { extension "prototype(convert) decode(TEXT)" };
:
:
  type record Msg_summary_line {
    charstring msg_context_class,
    charstring msgs,
    charstring urgent_msgs optional
  }
  //2.  with {variant""}  on top level type
  with {variant ""}

}//3. final with {encode "TEXT"} 
with { encode "TEXT"}



Note: With this , the TEXT encoding is not complete, variants will have to be added to all types; this will be your homework, please check the RFC 3842 for details.


module LibSip_SMSTypesAndValues {
    import from LibCommon_DataStrings all;
//1. External function declaration    
    external function f_enc_SMS(in TP_PDU_Type pl_pdu) return octetstring
 with { extension "prototype(convert) encode(RAW)" };

external function f_dec_SMS(in octetstring pl_oct) return TP_PDU_Type
 with { extension "prototype(convert) decode(RAW)" };
 
 :
 :
       
        type union TP_PDU_Type {
          SMS_DELIVER_Type           SMS_DELIVER,
          SMS_DELIVER_REPORT_Type    SMS_DELIVER_REPORT,
          SMS_SUBMIT_Type            SMS_SUBMIT,
          SMS_SUBMIT_REPORT_Type     SMS_SUBMIT_REPORT,
          SMS_STATUS_REPORT_Type     SMS_STATUS_REPORT,
          SMS_COMMAND_Type           SMS_COMMAND
        } 
		//2.  with {variant""}  on top level type
		with {variant ""}
        
        /* End SM-TP PDU Declarations */
        
    } //with { encode "SMS Types"}  // group SMS_Declarations

} 
//3. final with {encode "RAW"}
with { encode "RAW"} 



Note: With this, the RAW encoding is yet incomplete, variants will have to be added to all types; this will be your homework, please check 3GPP 24.011 and 3GPP 23.040 Rel 8 and 9. for details.



The install.script now has the following content:

#!/bin/sh

ln -s ../xsd/http_uri_etsi_org_ngn_params_xml_comm_div_info.ttcn     .
ln -s ../xsd/http_uri_etsi_org_ngn_params_xml_simservs_mcid.ttcn     .
ln -s ../xsd/http_uri_etsi_org_ngn_params_xml_simservs_pstn.ttcn     .
ln -s ../xsd/http_uri_etsi_org_ngn_params_xml_simservs_xcap.ttcn     .
ln -s ../xsd/http_www_w3_org_XML_1998_namespace.ttcn     .
ln -s ../xsd/NoTargetNamespace.ttcn     .
ln -s ../xsd/urn_3gpp_ns_cw_1_0.ttcn     .
ln -s ../xsd/urn_ietf_params_xml_ns_common_policy.ttcn     .
ln -s ../xsd/urn_ietf_params_xml_ns_conference_info.ttcn     .
ln -s ../xsd/urn_ietf_params_xml_ns_pidf_geopriv10_basicPolicy.ttcn     .
ln -s ../xsd/urn_ietf_params_xml_ns_pidf_geopriv10.ttcn     .
ln -s ../xsd/urn_ietf_params_xml_ns_pidf.ttcn     .
ln -s ../xsd/urn_ietf_params_xml_ns_reginfo.ttcn     .
ln -s ../xsd/urn_ietf_params_xml_ns_resource_lists.ttcn     .
ln -s ../xsd/urn_oma_xml_xdm_common_policy.ttcn     .
ln -s ../xsd/UsefulTtcn3Types.ttcn     .
ln -s ../xsd/XSD.ttcn     .



ln -s ../../LibCommon/LibCommon_AbstractData.ttcn     .
ln -s ../../LibCommon/LibCommon_BasicTypesAndValues.ttcn     .
ln -s ../../LibCommon/LibCommon_DataStrings.ttcn     .
ln -s ../../LibCommon/LibCommon_Sync.ttcn     .
ln -s ../../LibCommon/LibCommon_TextStrings.ttcn     .
ln -s ../../LibCommon/LibCommon_Time.ttcn     .
ln -s ../../LibCommon/LibCommon_VerdictControl.ttcn     .

ln -s ../../titan.ProtocolModules.SDP/src/lex.SDP_parse_.c .
ln -s ../../titan.ProtocolModules.SDP/src/SDP_EncDec.cc    .
ln -s ../../titan.ProtocolModules.SDP/src/SDP_parse_parser.h .
ln -s ../../titan.ProtocolModules.SDP/src/SDP_parse_.tab.c  .
ln -s ../../titan.ProtocolModules.SDP/src/SDP_parse_.tab.h  .
ln -s ../../titan.ProtocolModules.SDP/src/SDP_Types.ttcn  .


ln -s ../../titan.ProtocolModules.MIME/src/MIME_EncDec.cc  .
ln -s ../../titan.ProtocolModules.MIME/src/MIME_Types.ttcn  .
ln -s ../../titan.ProtocolModules.MIME/src/MIME_parse.h  .
ln -s ../../titan.ProtocolModules.MIME/src/MIME_parse.l  .
ln -s ../../titan.ProtocolModules.MIME/src/MIME_parse.y  .
ln -s ../../titan.ProtocolModules.MIME/src/MIME_parse_.tab.c  .
ln -s ../../titan.ProtocolModules.MIME/src/MIME_parse_.tab.h  .
ln -s ../../titan.ProtocolModules.MIME/src/lex.MIME_parse_.c  .


ln -s ../../titan.TestPorts.SIPmsg/src/lex.SIP_parse_.c .
ln -s ../../titan.TestPorts.SIPmsg/src/SIPmsg_PortType.ttcn .
ln -s ../../titan.TestPorts.SIPmsg/src/SIPmsg_PT.cc    .
ln -s ../../titan.TestPorts.SIPmsg/src/SIPmsg_PT.hh    .
ln -s ../../titan.TestPorts.SIPmsg/src/SIPmsg_Types.ttcn  .
ln -s ../../titan.TestPorts.SIPmsg/src/SIP_parse.h  .
ln -s ../../titan.TestPorts.SIPmsg/src/SIP_parse_.tab.h  .
ln -s ../../titan.TestPorts.SIPmsg/src/SIP_parse_.tab.c  .





and (after downloading the attached file and uncompressing it into Diam_Rx_ETSI)

cd Diam_Rx_ETSI/LibSip/ttcn
./install.script
make 

should terminate without error.


Next , we will (finally) add the SIP-related part of LibSip.

Best regards
Elemer




Re: Executing ETSI Diameter Rx test cases [message #1725738 is a reply to message #1725620] Mon, 07 March 2016 11:10 Go to previous messageGo to next message
uttam hoode is currently offline uttam hoodeFriend
Messages: 4
Registered: January 2016
Junior Member
Dear Elemer,

When I tried to compile titan.TestPorts.SCTPasp and LibDiameter, I am getting linker error.

Also if I use -U type flag and run make clean, many of the files are not getting deleted.



DIAMETER_Mapping.o: In function `DIAMETER__Mapping::t__ASP__SCTP__Connect(CHARSTRING_template const&, INTEGER_template const&)':
DIAMETER_Mapping.cc:(.text+0x5d8f): undefined reference to `SCTPasp__Types::ASP__SCTP__Connect_template::ASP__SCTP__Connect_template()'
DIAMETER_Mapping.cc:(.text+0x5d9b): undefined reference to `SCTPasp__Types::ASP__SCTP__Connect_template::peer__hostname()'
DIAMETER_Mapping.cc:(.text+0x5db6): undefined reference to `SCTPasp__Types::ASP__SCTP__Connect_template::peer__portnumber()'
DIAMETER_Mapping.cc:(.text+0x5de3): undefined reference to `SCTPasp__Types::ASP__SCTP__Connect_template::~ASP__SCTP__Connect_template()'
DIAMETER_Mapping.o: In function `DIAMETER__Mapping::t__ASP__TCP__Connect(CHARSTRING_template const&, INTEGER_template const&)':
DIAMETER_Mapping.cc:(.text+0x5e4c): undefined reference to `TCPasp__Types::ASP__TCP__Connect_template::ASP__TCP__Connect_template()'
DIAMETER_Mapping.cc:(.text+0x5e58): undefined reference to `TCPasp__Types::ASP__TCP__Connect_template::hostname()'
DIAMETER_Mapping.cc:(.text+0x5e73): undefined reference to `TCPasp__Types::ASP__TCP__Connect_template::portnumber()'
DIAMETER_Mapping.cc:(.text+0x5e8e): undefined reference to `TCPasp__Types::ASP__TCP__Connect_template::local__hostname()'
DIAMETER_Mapping.cc:(.text+0x5ea7): undefined reference to `TCPasp__Types::ASP__TCP__Connect_template::local__portnumber()'
DIAMETER_Mapping.cc:(.text+0x5ed2): undefined reference to `TCPasp__Types::ASP__TCP__Connect_template::~ASP__TCP__Connect_template()'


Regards,
Uttam
Re: Executing ETSI Diameter Rx test cases [message #1725751 is a reply to message #1725738] Mon, 07 March 2016 12:22 Go to previous messageGo to next message
Elemer Lelik is currently offline Elemer LelikFriend
Messages: 807
Registered: January 2015
Senior Member
Hi Uttam,

my guess is you have added manually the "-U type" option to compiler flags. This may work for some flags, but not for -U, as
this means that Titan will split the files , but Makefile will be unaware of them.

If you want i use the -U option in LibDiameter pls. regenerate the Makefile as below:

makefilegen -f -U type *.ttcn *.cc *.hh



followed by make etc.


Best regards

Elemer


Re: Executing ETSI Diameter Rx test cases [message #1725771 is a reply to message #1725751] Mon, 07 March 2016 14:41 Go to previous messageGo to next message
Elemer Lelik is currently offline Elemer LelikFriend
Messages: 807
Registered: January 2015
Senior Member
Hi all,

in this step I added the remaining files from LibSip:

LibSip_Interface.ttcn                                                                                                               
LibSip_PIXITS.ttcn                                                                                                                  
LibSip_SDPTypes.ttcn                                                                                                                
LibSip_SIPTypesAndValues.ttcn                                                                                                       
LibSip_Steps.ttcn                                                                                                                   
LibSip_Templates.ttcn                                                                                                               
  

and the following library:


titan.Libraries.TCCUsefulFunctions


so the content of install.script in LibSip/ttcn becomes:

#!/bin/sh

ln -s ../xsd/http_uri_etsi_org_ngn_params_xml_comm_div_info.ttcn     .
ln -s ../xsd/http_uri_etsi_org_ngn_params_xml_simservs_mcid.ttcn     .
ln -s ../xsd/http_uri_etsi_org_ngn_params_xml_simservs_pstn.ttcn     .
ln -s ../xsd/http_uri_etsi_org_ngn_params_xml_simservs_xcap.ttcn     .
ln -s ../xsd/http_www_w3_org_XML_1998_namespace.ttcn     .
ln -s ../xsd/NoTargetNamespace.ttcn     .
ln -s ../xsd/urn_3gpp_ns_cw_1_0.ttcn     .
ln -s ../xsd/urn_ietf_params_xml_ns_common_policy.ttcn     .
ln -s ../xsd/urn_ietf_params_xml_ns_conference_info.ttcn     .
ln -s ../xsd/urn_ietf_params_xml_ns_pidf_geopriv10_basicPolicy.ttcn     .
ln -s ../xsd/urn_ietf_params_xml_ns_pidf_geopriv10.ttcn     .
ln -s ../xsd/urn_ietf_params_xml_ns_pidf.ttcn     .
ln -s ../xsd/urn_ietf_params_xml_ns_reginfo.ttcn     .
ln -s ../xsd/urn_ietf_params_xml_ns_resource_lists.ttcn     .
ln -s ../xsd/urn_oma_xml_xdm_common_policy.ttcn     .
ln -s ../xsd/UsefulTtcn3Types.ttcn     .
ln -s ../xsd/XSD.ttcn     .



ln -s ../../LibCommon/LibCommon_AbstractData.ttcn     .
ln -s ../../LibCommon/LibCommon_BasicTypesAndValues.ttcn     .
ln -s ../../LibCommon/LibCommon_DataStrings.ttcn     .
ln -s ../../LibCommon/LibCommon_Sync.ttcn     .
ln -s ../../LibCommon/LibCommon_TextStrings.ttcn     .
ln -s ../../LibCommon/LibCommon_Time.ttcn     .
ln -s ../../LibCommon/LibCommon_VerdictControl.ttcn     .

ln -s ../../titan.ProtocolModules.SDP/src/lex.SDP_parse_.c .
ln -s ../../titan.ProtocolModules.SDP/src/SDP_EncDec.cc    .
ln -s ../../titan.ProtocolModules.SDP/src/SDP_parse_parser.h .
ln -s ../../titan.ProtocolModules.SDP/src/SDP_parse_.tab.c  .
ln -s ../../titan.ProtocolModules.SDP/src/SDP_parse_.tab.h  .
ln -s ../../titan.ProtocolModules.SDP/src/SDP_Types.ttcn  .


ln -s ../../titan.ProtocolModules.MIME/src/MIME_EncDec.cc  .
ln -s ../../titan.ProtocolModules.MIME/src/MIME_Types.ttcn  .
ln -s ../../titan.ProtocolModules.MIME/src/MIME_parse.h  .
ln -s ../../titan.ProtocolModules.MIME/src/MIME_parse.l  .
ln -s ../../titan.ProtocolModules.MIME/src/MIME_parse.y  .
ln -s ../../titan.ProtocolModules.MIME/src/MIME_parse_.tab.c  .
ln -s ../../titan.ProtocolModules.MIME/src/MIME_parse_.tab.h  .
ln -s ../../titan.ProtocolModules.MIME/src/lex.MIME_parse_.c  .


ln -s ../../titan.TestPorts.SIPmsg/src/lex.SIP_parse_.c .
ln -s ../../titan.TestPorts.SIPmsg/src/SIPmsg_PortType.ttcn .
ln -s ../../titan.TestPorts.SIPmsg/src/SIPmsg_PT.cc    .
ln -s ../../titan.TestPorts.SIPmsg/src/SIPmsg_PT.hh    .
ln -s ../../titan.TestPorts.SIPmsg/src/SIPmsg_Types.ttcn  .
ln -s ../../titan.TestPorts.SIPmsg/src/SIP_parse.h  .
ln -s ../../titan.TestPorts.SIPmsg/src/SIP_parse_.tab.h  .
ln -s ../../titan.TestPorts.SIPmsg/src/SIP_parse_.tab.c  .



ln -s   ../../titan.Libraries.TCCUsefulFunctions/src/TCCDateTime.cc .
ln -s   ../../titan.Libraries.TCCUsefulFunctions/src/TCCDateTime_Functions.ttcn
ln -s   ../../titan.Libraries.TCCUsefulFunctions/src/TCCConversion.cc .
ln -s   ../../titan.Libraries.TCCUsefulFunctions/src/TCCConversion_Functions.ttcn
ln -s   ../../titan.Libraries.TCCUsefulFunctions/src/TCCInterface.cc .
ln -s   ../../titan.Libraries.TCCUsefulFunctions/src/TCCInterface_Functions.ttcn
ln -s   ../../titan.Libraries.TCCUsefulFunctions/src/TCCInterface_ip.h


Below, I will survey the changes in the added files (besides the imports, which of course will change)


In LibSip_SDPTypes.ttcn:

-only constants kept, types replaced with their conterpart in SDP_Types.ttcn


In LibSip_SIPTypesAndValues.ttcn:

-only constants kept, types replaced with their counterpart in SIPmsg_Types
-wherever needed, aliases were declared, e.g. :

 type PDU_SIP_Request    Request;


-MIME types replaced

type PDU_MIME_entity MIME_Message ;

-Message body redefined according to the new structure:

type charstring MessageBody;


-MessageBody structure kept with a different name:

        type union Message_Body{
        SDP_Message sdpMessageBody, 	// if there is only SDP part
        //		XMLMessage xmlMessage,          // if there is XML message (with header and body)
        XmlBody xmlBody,				// if there is XML body
        MIME_Message mimeMessageBody, 	// if there is SDP and encapsulated ISUP part
        charstring sipfrag, 			// if content-Type is message/sipfrag (cp. NOTIFY, cp TS124147 A.4.3.1.2)
        charstring textplain,			// if content type is text/plain (for testing long messages)
        SimpleMsgSummary simpleMsgSummary, // RFC 3842
        octetstring smsMessage          // encoded SMS message 3GPP 23.040, 24.011
      };


for this, if needed, an encode-decode function can be written:

Message_Body ---> characterstring
characterstring ---> Message_Body


In LibSip_PIXITS.ttcn
-practically no change ( imports only)


In LibSip_Templates.ttcn
-many small changes, mainly due to difference in type/field names between LibSip_SIPTypesAndValues and SIPmsg_Types
(structures are largely similar though)

In LibSip_Steps.ttcn


-external functions from the library TCCUSefulFunctions added, wherever feasible
(some were replaced with dummies, these will have to be written at some stage)

LibSip_Steps.ttcn:import from TCCConversion_Functions all;
LibSip_Steps.ttcn:import from TCCInterface_Functions all;

:
:
group externalfunctions {
  
  //Return random charstring
  /*external*/ function fx_rndStr() return charstring{
    
    
    return "abcdefgh"  ; //FIXME
    
  };
  // Return the equivalent string in lower case
  function fx_putInLowercase(charstring par_string) return charstring
  {
    return f_putInLowercase(par_string);
    
  }
  
  function fx_getIpAddr(charstring host_name) return charstring{
    
    return f_getIpAddr(host_name);
    
  };
  
  
  // External function to generate a digest response.
  // References:
  //   * RFC 2617 HTTP Authentication: Basic and Digest Access
  //     Authentication, and
  //   * RFC 1321 The MD5 Message-Digest Algorithm
  // See RFC 2617, chapter 5 Sample implementation, for example usage, as
  // the signature of calculateDigestResponse is according to the example
  // given in the RFC.
  //
  /*external*/ function fx_calculateDigestResponse(
    charstring nonce,
    charstring cnonce,
    charstring user,
    charstring realm,
    charstring passwd,
    charstring alg,
    charstring nonceCount,
    charstring method,
    charstring qop,
    charstring URI,
    charstring HEntity) return charstring
  {
    return "abcdefg"; //FIXME
  };
  



Makefile was generated with the -U split option:

makefilegen -f -U type *.ttcn *.cc *.hh *.c *.h


After downloading the attached file and uncompressing it into Diam_Rx_ETSI

cd Diam_Rx_ETSI/LibSip/ttcn
./install.script
make 


should terminate with no errors.


In the next , and final step, we will add LibIms and Diameter_Rx


P.S. if any changes are done to the Makefile, a "make clean" should precede it:

for instance, if I want to change to a no-split Makefile:

make clean
makefilegen -f  *.ttcn *.cc *.hh *.c *.h



If I do the make clean after the changes, the clean may not work as supposed, as it will be based on the new Makefile content.


Best regards
Elemer
Re: Executing ETSI Diameter Rx test cases [message #1725894 is a reply to message #1725771] Tue, 08 March 2016 11:00 Go to previous messageGo to next message
Elemer Lelik is currently offline Elemer LelikFriend
Messages: 807
Registered: January 2015
Senior Member
Hi all,

in this last step I have added LibIms:


-In LibIms_Interface,LibIms_SIPTypesAndValues,LibIms_PIXITS,LibIms_Steps
there are no changes to to speak of;

-in LibIms_Templates , small changes , for the same reason as in LibSip_Templates.ttcn


After that , Diameter_Rx was added; this imports all the previously discussed content.


I'll briefly go through the changes:

-DiameterRx_ImsGm_TCFunctions.ttcn no significant change
-DiameterRx_PICS.ttcn no change
-DiameterRx_PIXITS.ttcn no change

-in DiameterRx_Rx_TCFunctions.ttcn the function f_awaitSTR_sendSTA()
is not declared , I have put in a dummy , but this has to be corrected:

function f_awaitSTR_sendSTA() {
//dummy
}


-DiameterRx_Steps.ttcn no change
-DiameterRx_Templates.ttcn small changes, same reason as for LibIms_Templates, LibSip_Templates


-in DiameterRx_TestSystem.ttcn the operator_SIP port was marked internal:

		type port operatorPort_SIP procedure {
			inout s_SIP_conversation; 
			inout s_SIP_ringing};


changed to:
		type port operatorPort_SIP procedure {
			inout s_SIP_conversation; 
			inout s_SIP_ringing} with {extension "internal"}; 



-in DiameterRx_TestConfiguration.ttcn we have to account for the new Diameter mapping component , and for the choices of test port:

            //Variables
            var FncRetCode v_ret := e_success;

            //Create
            p_diameterComponent_ims := DiameterComponent.create ;



            //Connect
            connect(p_diameterComponent_ims:syncPort, self:syncPort) ;
            //Map
            map(p_diameterComponent_ims:DIAMP, system:PCRF_Rx);// Diameter Init test Configuration



            if (PX_DIAM_LLP_ENABLED){
            	map(p_diameterComponent_ims:LLPP, system:LLIMS);// Lower Layer Primitive Init test Configuration
            }


changed to:





		            //Variables
            var FncRetCode v_ret := e_success;

            //Create
            p_diameterComponent_ims := DiameterComponent.create ;
            p_diameterMappingComponent:=    DIAMETER_Mapping_CT.create;


            //Connect
            connect(p_diameterComponent_ims:syncPort, self:syncPort) ;
            connect(p_diameterMappingComponent:DIA_PCO, p_diameterComponent_ims:DIAMP) ;


            //Map
    /*        map(p_diameterComponent_ims:DIAMP, system:PCRF_Rx);// Diameter Init test Configuration
            if (PX_DIAM_LLP_ENABLED){
            	map(p_diameterComponent_ims:LLPP, system:LLIMS);// Lower Layer Primitive Init test Configuration
            }
*/        if(tsp_transport==TCP)
             { map(p_diameterMappingComponent:TCP_PCO, system:TCP_PCO)}
           else   
             { map(p_diameterMappingComponent:SCTP_PCO, system:SCTP_PCO)}   





-same in DiameterRx_TestCases.ttcn:

                //Variables
                var ImsComponent v_imsComponent_ue1, v_imsComponent_ue2;
                var DiameterComponent v_diameterComponent_pcrf;
                f_cf_1Rx2GmUp(v_imsComponent_ue1, v_imsComponent_ue2, v_diameterComponent_pcrf);

                //Start
                if (PX_SIPsupport) {
                    f_IncCSeq(p_cSeq_s); v_imsComponent_ue1.start(f_TC_IMST2_GM_INI_04_UE1(p_cSeq_s));
                    f_IncCSeq(p_cSeq_s); v_imsComponent_ue2.start(f_TC_IMST2_GM_INI_04_UE2(p_cSeq_s));
                }




changed to:


			                //Variables
                var ImsComponent v_imsComponent_ue1, v_imsComponent_ue2;
                var DiameterComponent v_diameterComponent_pcrf;
                var DIAMETER_Mapping_CT v_diameterMappingComponent;
                f_cf_1Rx2GmUp(v_imsComponent_ue1, v_imsComponent_ue2, v_diameterComponent_pcrf, v_diameterMappingComponent);

                //Start
                if (PX_SIPsupport) {
                    f_IncCSeq(p_cSeq_s); v_imsComponent_ue1.start(f_TC_IMST2_GM_INI_04_UE1(p_cSeq_s));
                    f_IncCSeq(p_cSeq_s); v_imsComponent_ue2.start(f_TC_IMST2_GM_INI_04_UE2(p_cSeq_s));
                }
               if (tsp_transport==TCP){ v_diameterMappingComponent.start(f_DIA_TCP_Mapping_Client())}
               else { v_diameterMappingComponent.start(f_DIA_SCTP_Mapping_Client()) }
                v_diameterComponent_pcrf.start(f_TC_AF_IPS_01());






-DiameterRx_TestExecutions.ttcn: no change


the install.script has the content:
#!/bin/sh

ln -s ../LibSip/xsd/http_uri_etsi_org_ngn_params_xml_comm_div_info.ttcn     .
ln -s ../LibSip/xsd/http_uri_etsi_org_ngn_params_xml_simservs_mcid.ttcn     .
ln -s ../LibSip/xsd/http_uri_etsi_org_ngn_params_xml_simservs_pstn.ttcn     .
ln -s ../LibSip/xsd/http_uri_etsi_org_ngn_params_xml_simservs_xcap.ttcn     .
ln -s ../LibSip/xsd/http_www_w3_org_XML_1998_namespace.ttcn     .
ln -s ../LibSip/xsd/NoTargetNamespace.ttcn     .
ln -s ../LibSip/xsd/urn_3gpp_ns_cw_1_0.ttcn     .
ln -s ../LibSip/xsd/urn_ietf_params_xml_ns_common_policy.ttcn     .
ln -s ../LibSip/xsd/urn_ietf_params_xml_ns_conference_info.ttcn     .
ln -s ../LibSip/xsd/urn_ietf_params_xml_ns_pidf_geopriv10_basicPolicy.ttcn     .
ln -s ../LibSip/xsd/urn_ietf_params_xml_ns_pidf_geopriv10.ttcn     .
ln -s ../LibSip/xsd/urn_ietf_params_xml_ns_pidf.ttcn     .
ln -s ../LibSip/xsd/urn_ietf_params_xml_ns_reginfo.ttcn     .
ln -s ../LibSip/xsd/urn_ietf_params_xml_ns_resource_lists.ttcn     .
ln -s ../LibSip/xsd/urn_oma_xml_xdm_common_policy.ttcn     .
ln -s ../LibSip/xsd/UsefulTtcn3Types.ttcn     .
ln -s ../LibSip/xsd/XSD.ttcn     .


ln -s ../LibCommon/LibCommon_AbstractData.ttcn     .
ln -s ../LibCommon/LibCommon_BasicTypesAndValues.ttcn     .
ln -s ../LibCommon/LibCommon_DataStrings.ttcn     .
ln -s ../LibCommon/LibCommon_Sync.ttcn     .
ln -s ../LibCommon/LibCommon_TextStrings.ttcn     .
ln -s ../LibCommon/LibCommon_Time.ttcn     .
ln -s ../LibCommon/LibCommon_VerdictControl.ttcn     .

ln -s ../LibSip/ttcn/LibSip_Interface.ttcn     .
ln -s ../LibSip/ttcn/LibSip_PIXITS.ttcn     .
ln -s ../LibSip/ttcn/LibSip_SDPTypes.ttcn     .
ln -s ../LibSip/ttcn/LibSip_SimpleMsgSummaryTypes.ttcn     .
ln -s ../LibSip/ttcn/LibSip_SIPTypesAndValues.ttcn     .
ln -s ../LibSip/ttcn/LibSip_SMSFunctions.ttcn     .
ln -s ../LibSip/ttcn/LibSip_SMSTemplates.ttcn     .
ln -s ../LibSip/ttcn/LibSip_SMSTypesAndValues.ttcn     .
ln -s ../LibSip/ttcn/LibSip_Steps.ttcn     .
ln -s ../LibSip/ttcn/LibSip_Templates.ttcn     .
ln -s ../LibSip/ttcn/LibSip_XMLTypes.ttcn     .



ln -s ../LibIms/LibIms_Interface.ttcn
ln -s ../LibIms/LibIms_PIXITS.ttcn
ln -s ../LibIms/LibIms_SIPTypesAndValues.ttcn
ln -s ../LibIms/LibIms_Steps.ttcn
ln -s ../LibIms/LibIms_Templates.ttcn



ln -s ../LibDiameter/LibDiameter_Interface.ttcn .
ln -s ../LibDiameter/LibDiameter_PIXITS.ttcn .
ln -s ../LibDiameter/LibDiameter_Steps.ttcn .
ln -s ../LibDiameter/LibDiameter_Templates.ttcn .
ln -s ../LibDiameter/LibDiameter_TypesAndValues.ttcn .

ln -s ../LibDiameter/DIAMETER_EncDec.cc .
ln -s ../LibDiameter/DIAMETER_Mapping.ttcn .
ln -s ../LibDiameter/DIAMETER_Types.ttcn .



ln -s ../titan.ProtocolModules.SDP/src/lex.SDP_parse_.c .
ln -s ../titan.ProtocolModules.SDP/src/SDP_EncDec.cc    .
ln -s ../titan.ProtocolModules.SDP/src/SDP_parse_parser.h .
ln -s ../titan.ProtocolModules.SDP/src/SDP_parse_.tab.c  .
ln -s ../titan.ProtocolModules.SDP/src/SDP_parse_.tab.h  .
ln -s ../titan.ProtocolModules.SDP/src/SDP_Types.ttcn  .


ln -s ../titan.TestPorts.SIPmsg/src/lex.SIP_parse_.c .
ln -s ../titan.TestPorts.SIPmsg/src/SIPmsg_PortType.ttcn .
ln -s ../titan.TestPorts.SIPmsg/src/SIPmsg_PT.cc    .
ln -s ../titan.TestPorts.SIPmsg/src/SIPmsg_PT.hh    .
ln -s ../titan.TestPorts.SIPmsg/src/SIPmsg_Types.ttcn  .
ln -s ../titan.TestPorts.SIPmsg/src/SIP_parse.h  .k
ln -s ../titan.TestPorts.SIPmsg/src/SIP_parse_.tab.h  .
ln -s ../titan.TestPorts.SIPmsg/src/SIP_parse_.tab.c  .

ln -s ../titan.ProtocolModules.MIME/src/MIME_EncDec.cc  .
ln -s ../titan.ProtocolModules.MIME/src/MIME_Types.ttcn  .
ln -s ../titan.ProtocolModules.MIME/src/MIME_parse.h  .
ln -s ../titan.ProtocolModules.MIME/src/MIME_parse.l  .
ln -s ../titan.ProtocolModules.MIME/src/MIME_parse.y  .
ln -s ../titan.ProtocolModules.MIME/src/MIME_parse_.tab.c  .
ln -s ../titan.ProtocolModules.MIME/src/MIME_parse_.tab.h  .
ln -s ../titan.ProtocolModules.MIME/src/lex.MIME_parse_.c  .


ln -s   ../titan.Libraries.TCCUsefulFunctions/src/TCCDateTime.cc .
ln -s   ../titan.Libraries.TCCUsefulFunctions/src/TCCDateTime_Functions.ttcn
ln -s   ../titan.Libraries.TCCUsefulFunctions/src/TCCConversion.cc .
ln -s   ../titan.Libraries.TCCUsefulFunctions/src/TCCConversion_Functions.ttcn
ln -s   ../titan.Libraries.TCCUsefulFunctions/src/TCCInterface.cc .
ln -s   ../titan.Libraries.TCCUsefulFunctions/src/TCCInterface_Functions.ttcn
ln -s   ../titan.Libraries.TCCUsefulFunctions/src/TCCInterface_ip.h


ln -s  ../titan.TestPorts.SCTPasp/src/SCTPasp_PortType.ttcn .
ln -s  ../titan.TestPorts.SCTPasp/src/SCTPasp_PT.cc .
ln -s  ../titan.TestPorts.SCTPasp/src/SCTPasp_PT.hh .
ln -s  ../titan.TestPorts.SCTPasp/src/SCTPasp_Types.ttcn .

ln -s  ../titan.TestPorts.TCPasp/src/TCPasp_PortType.ttcn .
ln -s  ../titan.TestPorts.TCPasp/src/TCPasp_PT.cc .
ln -s  ../titan.TestPorts.TCPasp/src/TCPasp_PT.hh .
ln -s  ../titan.TestPorts.TCPasp/src/TCPasp_Types.ttcn .



ln -s  ../titan.TestPorts.Common_Components.Abstract_Socket/src/Abstract_Socket.cc    .
ln -s  ../titan.TestPorts.Common_Components.Abstract_Socket/src/Abstract_Socket.hh    .





Makefile was generated with the -U split option:

makefilegen -f -U type *.ttcn *.cc *.hh *.c *.h



I have uploaded the code to github, so

git clone https://github.com/eclipse/titan.misc
cd titan.misc

git submodule init
git submodule update

cd DIAMETER_Rx_ETSI/
cd DiameterRx/

./install.script

make

should terminate with no errors.



What's left to be done for execution: first and foremost, a config file covering test port and module parameters has to be assembled.
After this, theoretically at least, you are good to go; however, test cases will have to be validated one by one, and possible small errors corrected.

During this exercise, we have switched off warnings; after errors are corrected, these have to be dealt with or at least a build should be made with warnings enabled and the logfile for that has to be kept; if any problems are encountered during run time, this log file might offer some explanation.

This is the end of our journey in migrating a test suite from one TTCN-3 tool to another, Titan in this case.

The main areas that have to be tackled are: encoding, test ports, external functions (that is, whatever is not covered by the standard),
and then other small issues rooted in incompatibilities between tools, differences between old and new type declarations etc.

The conclusion is that , even if it's not instantaneous, it's perfectly doable.



Best regards

Elemer



Re: Executing ETSI Diameter Rx test cases [message #1784820 is a reply to message #1725894] Wed, 04 April 2018 12:51 Go to previous messageGo to next message
Yann Garcia is currently offline Yann GarciaFriend
Messages: 63
Registered: June 2016
Member
Hello Elemer,

I tried to compile DIAMETER_Rx_ETSI using the procedure from your previous response, using the latest version of TITAN (from github).
Unfortunately, I got some errors in TTCN-3 module LibCommon_TextStrings.ttcn:
LibCommon_TextStrings.ttcn: In TTCN-3 module `LibCommon_TextStrings':
LibCommon_TextStrings.ttcn:88.3-38: In type definition `String1':
LibCommon_TextStrings.ttcn:88.47-70: error: Variant attribute is not related to TEXT encoding
LibCommon_TextStrings.ttcn:89.3-38: In type definition `String2':
LibCommon_TextStrings.ttcn:89.47-70: error: Variant attribute is not related to TEXT encoding
....

It's strange because I use the same LibCommon in ITS project without any problem.
Do you have any hint to fix it?

Many thanks in advance,

Yann
Re: Executing ETSI Diameter Rx test cases [message #1784882 is a reply to message #1784820] Thu, 05 April 2018 07:13 Go to previous messageGo to next message
Elemer Lelik is currently offline Elemer LelikFriend
Messages: 807
Registered: January 2015
Senior Member
Hi Yann,


there are several versions of LibCommon and sometimes it's difficult to determine their provenance, so I will assume you refer to the one in

http://www.etsi.org/deliver/etsi_ts/101500_101599/10158003/02.01.01_60/ts_10158003v020101p0.zip


Indeed since then we have introduced the multiple encoding feature in Titan which often require that legacy mod to be set with a "-e "
flag in the Makefile; I'm guessing you need that;

see attached, which should compile flawlessly in you environment too.

Best regards
Elemer






Re: Executing ETSI Diameter Rx test cases [message #1785068 is a reply to message #1784820] Mon, 09 April 2018 05:53 Go to previous message
Yann Garcia is currently offline Yann GarciaFriend
Messages: 63
Registered: June 2016
Member
Hello Elemer,

I have forgotten this point. I compile now.
Many thanks for your response.

Have a nice day,

Yann
Previous Topic:How to express variable-length "C style" string in RAW codec?
Next Topic:TTCN3_Compiler problem
Goto Forum:
  


Current Time: Sun Sep 23 04:04:14 GMT 2018

Powered by FUDForum. Page generated in 0.02975 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top