Home » Eclipse Projects » Eclipse Titan » Executing ETSI Diameter Rx test cases
| |
Re: Executing ETSI Diameter Rx test cases [message #1721681 is a reply to message #1721672] |
Fri, 29 January 2016 07:53 |
|
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 |
|
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 #1722164 is a reply to message #1722158] |
Wed, 03 February 2016 08:11 |
|
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
(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:
to:
and compile:
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 |
uttam hoode 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 |
|
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 |
|
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
should throw no errors
Let's move to LibDiameter:
create simlinks:
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
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 |
|
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 |
|
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 |
|
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:
(Note that during conversion, the converter utility also generates additional files UsefulTtcn3Types.ttcn and XSD.ttcn containing default types)
generate a Makefile:
and build to verify the result:
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 |
|
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 #1725751 is a reply to message #1725738] |
Mon, 07 March 2016 12:22 |
|
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 |
|
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 |
|
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
|
|
| | | |
Goto Forum:
Current Time: Thu Sep 19 10:26:13 GMT 2024
Powered by FUDForum. Page generated in 0.06623 seconds
|