Home » Eclipse Projects » Eclipse Titan » Testing SIPmsg demo defined in titan.TestPorts.SIPmsg(Testing SIPmsg demo defined in titan.TestPorts.SIPmsg)
| | |
Re: Testing SIPmsg demo defined in titan.TestPorts.SIPmsg [message #1717165 is a reply to message #1717155] |
Thu, 10 December 2015 11:50 |
|
HI Yannick,
I think Jeno was asking if the SIP test port is sufficient to reproduce the problem.
- a few things that are not immediately useful, but may come handy later:
- I have updated the SIP test port revision , so you may want to download the new one
-there's no config file in /demo ( I will add one soon) so either you add initial values in SIPexample.ttcn and SIPeaxmpleTemplates.ttcn (both of them),
for instance
modulepar charstring PX_ETS_LOCAL_USER2:="user2";
modulepar charstring PX_ETS_IPADDR2:="127.0.0.1";
modulepar integer PX_ETS_PORT2:=6667;
modulepar charstring PX_ETS_LOCAL_USER:="user1";
modulepar charstring PX_ETS_IPADDR:="127.0.0.1";
modulepar integer PX_ETS_PORT:=6666;
or add your own config file containing some values for these module parameters.
Jeno will continue with the Eclipse setting issue.
BR Elemer
|
|
| | | | | |
Re: Testing SIPmsg demo defined in titan.TestPorts.SIPmsg [message #1717320 is a reply to message #1717208] |
Fri, 11 December 2015 16:35 |
Yannick LH Messages: 5 Registered: November 2015 |
Junior Member |
|
|
Hi,
Thanks for your answer previously.
I have 2 questions: one concerning the start under Windows and another concerning an error under TITAN executing notification.
Something is not so clear to me with cygwin usage.
From what i rode in the installation documentation :
"Installing Cygwin is optional and only needed if Eclipse is used for project compilation and test execution. TTCN-3 module editing is supported without Cygwin. "
But if i launch Eclipse from Windows, how can I start the "build " which launch command as "make", i guess I have to configure some path, right ?
It's a bit confusing to me this configuration.
However, I used TITAN through cygwin and the MC component is listening. I sent a SIP message (a basic INVITE ) trough the dynamic port running over TCP , it seems TITAN received something but I can read an error in the "notification" tab about "decoding/coding" :
"Error: Error during encoding/decoding of a message: Text decoder: Negative message length (-9)."
"Error: Maleformed message was received on an unknown connection from FR00115358.ericsson.se [LocalIP]."
I was wondering what could be the problem , if you have any idea ( directly), otherwise I also have the wireshark trace. I can send you through email.
Br,
Yannick
|
|
| | |
Re: Testing SIPmsg demo defined in titan.TestPorts.SIPmsg [message #1722904 is a reply to message #1717038] |
Wed, 10 February 2016 08:55 |
Martin vom Hagen Messages: 4 Registered: February 2016 |
Junior Member |
|
|
Hi,
I just managed to compile the SIPmsg Test Port example. Do you know how to build the ETSI SIP test suite? I had to comment out
type port SipPort message {
inout Request,
Response,
Raw
//TODO Alias port message types
//(Pls. do not delete or change the above comment,
// it helps to find the place when using Eclipse)
// ,REGISTER_Request,
// INVITE_Request,
// OPTIONS_Request,
// BYE_Request,
// CANCEL_Request,
// ACK_Request,
// Raw_REGISTER_Request,
// Raw_INVITE_Request,
// Raw_BYE_Request,
// Raw_Response,
// Raw_Unknown_Request
}
in SIP_TypesAndConf.ttcn to get rid of errors Duplicate outgoing message type `@SIP_TypesAndConf.Request', Duplicate incoming message type `@SIP_TypesAndConf.Request' and alike.
But when then generating the Makefile just with the derived files from the test suite the compilation complains of a forward declaration of
The problematic line is in SIP_TypesAndConf.hh:
Am I simply missing something? Perhaps ETSI LibSip or something? The inclusion of the SIPmsg Test Port files is not helping.
Greetings,
Martin
|
|
|
Re: Testing SIPmsg demo defined in titan.TestPorts.SIPmsg [message #1722984 is a reply to message #1722904] |
Wed, 10 February 2016 16:16 |
|
Hi Martin,
there's a slight difference between the ETSI SIP type definitions and ours.
(
basically, for reasons of convenience, we have added a top level union type
type union PDU_SIP
{
PDU_SIP_Request request,
PDU_SIP_Response response,
PDU_SIP_Raw raw
}
to which the encoding/decoding functions refer, e.g.:
external function f_SIP_encode(in PDU_SIP pdu) return charstring;
)
On top of that , the codec functions are not fully auto-generated as for the majority
of the protocol modules: for reasons of speed , they are partly manually written.
Bottom line is, to be able to run the ETSI SIP suite, we will have to produce an ETSI-compatible version of the SIP test port; good news is , we are already working on it ( there have been others requesting it) , and should be ready in a couple of days.
Once this done, the suite should work with no problems.
(We could probably tweak the declarations so the two sides (the ETSI part and the SIP test port part) meet each other to the degree that the code becomes compileable,
but the encoding-decoding will not work anyhow.)
So please keep an eye on this thread ;as soon as the ETSI port is done, I'll post here.
Best regards
Elemer
|
|
| |
Re: Testing SIPmsg demo defined in titan.TestPorts.SIPmsg [message #1723678 is a reply to message #1723070] |
Wed, 17 February 2016 08:35 |
|
Hi Martin,
there's a bit of a problem around SIP, not technical, but administrative:
there is no one unambiguous ETSI SIP variant:
The SESSION INITIATION PROTOCOL (SIP) TEST SUITE contains
SIP_TypesAndConf dated September 2007
The IP MULTIMEDIA SUBSYSTEM (IMS) TEST SUITES contains
LibSip_SIPTypesAndValues dated 2014-01-31
The Diameter on the Rx interface contains LibSip_SIPTypesAndValues.ttcn dated 2011-12-09
The Diameter on the Cx and Dx interfaces contains LibSip_SIPTypesAndValues.ttcn dated 2014-09-18
and the different variants are not exactly compatible ; we are talking with ETSI to find out which version would be the most comprehensive ( as we don't want to produce several Titan-compatible variants ).
It would also help if we could understand what are you pursuing:
is there any specific test suite you are interested in or your interest is generic?
Best regards
Elemer
|
|
| | |
Re: Testing SIPmsg demo defined in titan.TestPorts.SIPmsg [message #1724207 is a reply to message #1723799] |
Mon, 22 February 2016 10:01 |
|
Hi Martin,
I have modified the ETSI code downloaded from the above location to compile with the SIPmsg test port.
You can download the code from https://github.com/eclipse/titan.misc
as below:
git clone https://github.com/eclipse/titan.misc
cd titan.misc
git submodule init
git submodule update
cd SIP_ETSI
./install.script
make
I'll add some details about changes later.
The code should be usable now, although you should add a .cfg file containing all (relevant) module parameters and test port parameters.
Best regards
Elemer
|
|
|
Re: Testing SIPmsg demo defined in titan.TestPorts.SIPmsg [message #1724252 is a reply to message #1724207] |
Mon, 22 February 2016 14:45 |
|
Hi Martin,
first thing I have done was to remove from SIP_TypesAndConf
all structures already declared in SIPmsg_Types.
I have also added some aliases
//aliases
type PDU_SIP_Response Response;
type PDU_SIP_Request Request;
type PDU_SIP_Request REGISTER_Request;
type PDU_SIP_Request INVITE_Request;
type PDU_SIP_Request OPTIONS_Request;
type PDU_SIP_Request BYE_Request;
type PDU_SIP_Request CANCEL_Request;
type PDU_SIP_Request ACK_Request;
type PDU_SIP_Raw Raw_Response;
type PDU_SIP_Raw Raw_REGISTER_Request;
type PDU_SIP_Raw Raw_BYE_Request;
type PDU_SIP_Raw Raw_Unknown_Request;
type PDU_SIP_Raw Raw_INVITE_Request;
so I can leave type names in the files untouched.
Most changes are due to two differences in declarations (which of course will propagate through the code):
A
SIP_TypesAndConf
type record WwwAuthenticate {
FieldName fieldName(WWW_AUTHENTICATE_E),
Challenge challenge
}
to
SIPmsg_Types
type record WwwAuthenticate
{
FieldName fieldName (WWW_AUTHENTICATE_E),
Challenge_list challenge
}
//-----------------------------------------------------------------
B
SIP_TypesAndConf
type record Authorization {
FieldName fieldName(AUTHORIZATION_E),
//dbo:uses as a charstring
//Credentials body
charstring body optional
}
to
SIPmsg_Types
type record Authorization
{
FieldName fieldName (AUTHORIZATION_E),
Credentials body
}
type union Credentials
{
CommaParam_List digestResponse,
OtherAuth otherResponse
}
type record OtherAuth
{
charstring authScheme,
CommaParam_List authParams
}
type record GenericParam
{
charstring id,
charstring paramValue optional
}
type set of GenericParam GenericParam_List;
type GenericParam_List CommaParam_List;
Of course all imports from SIPmsg_Types and SIPmsg_PortType had to be added accordingly.
As in the old version Credentials are interpreted as a (structured , with delimiters) character string,
while in the new one is a 'set of' structures, I have modified the function calculateCredentials in SIP_steps to return a structure instead of a character string; I'm not exactly sure about the delimiters used ,
so please check this.
Likewise, as in many place character strings were used, I have implemented a function f_convertCredentials to calculate the equivalent character string from a Credential structure; please check this one too.
Wherever I could I did use external functions from our library( TCCUsefulFunctions); If there was no equivalent I have put in dummies , so those will have to be written:
function getMajorDigit() return integer{ return 1};//FIXME
function getMinorDigit() return integer{ return 2};//FIXME
function calculateDigestResponse(
charstring vl_nonce,
charstring cnonce,
charstring user,
charstring vl_realm,
charstring passwd,
charstring alg,
charstring nonceCount,
charstring method,
charstring qop,
charstring URI,
charstring HEntity) return charstring {return "FIXME"}; //FIXME
function encodeEscapeDelim(charstring user) return charstring{return "FIXME"}; //FIXME
Finally, for test case selection a weird mechanism is used; so I have created a module parameter:
type record TestCaseSelection
{
charstring tc_name,
boolean selection
}
type record of TestCaseSelection TestCaseSelectionArray;
modulepar TestCaseSelectionArray par_selection:= {
{tc_name:="SIP_CC_OE_CE_TI_001", selection:= false},
{tc_name:="SIP_CC_OE_CE_TI_002", selection:= false},
:
{tc_name:="SIP_RG_RT_V_012", selection:= false},
{tc_name:="SIP_RG_RT_V_013", selection:= false}
}
This will have to be added to the config file; when a selection for a certain test case name is set to "true", the test case will be executed.
This should give you a head start. Please let me know if you encounter any problems.
Best regards
Elemer
|
|
| |
Goto Forum:
Current Time: Thu Apr 25 20:15:15 GMT 2024
Powered by FUDForum. Page generated in 0.04059 seconds
|