Hello,

Working on the ETSI SIP test suites, I came across a scenario like the following example:

Having two complex types MyType_1 and MyType_2, used in an alternative as:

alt {
[] p1.receive(MyType_1: ?) {...}
[] p1.receive(MyType_2: *) {...}
}

I can understand the semantic of the first receive in the alternative, however the second one is not clear to me.
Can somebody clarify this?

Thanks!

Hi Mihal,

this is an error in the TTCN-3 code; simply replace it with "?".

The TTCN-3 standard specifies:
B.1.2.4 Any value or none
....
Restrictions
...
b) At the time of matching during a receiving operation, it shall be applied to optional fields of record and set templates only.

BR, Gyorgy

Hi Gyorgy,

Thank you for your reply!

However as I mentioned in my post, this is not my code, and if what you are saying is correct, then there are approximately 25 errors in the ETSI SIP test suite (file SIP_Steps.ttcn).
Does it mean that the SIP test suite is not correct?

while from the standard point of view, legally speaking, this is not strictly allowed, the semantics in the context of the rest of the language is nevertheless clear. As a received message can never be omitted (i.e. the codec must give back a value of the given type hypothesis or null), the set of values matched by * is the same set as that matched by ?. That is why some tools have this non-standard-conform enlargement of the language with the expected semantics, i.e. it matches, if a message of the given type is received.

Hi Mihal,

When any code can be told to be 100% error free? By definition, never. In most of the cases ETSI doesn't validate the test code, but expects members & industry to report errors/probelms/findings. This is also the case here. The code is using a tool extension of a TTCN-3 tool and it has not been reported to ETSI yet (at least up to the version you are using). These are the facts of life we have to leave with.

So, the way forward is that if you are not using TTWorkbench, you correct the *-s to ?-s in your code (as in other tools, if it at all compiles, the runtime semantics is not defined) - and report the problem to ETSI in Mantis: forge.etsi.org/mantis/main_page.php, project ETSI TTCN-3 Libraries/SIP Library (the issue may also be present in the test case code, not (only) in the library part, but I cannot fing a better place at the moment).