maybe the links are correct now.

Signed-off-by: Kristof Szabados <Kristof.Szabados@ericsson.com>

usrguide/java_referenceguide/11-encoding_and_decoding.adoc

@@ -3,7 +3,7 @@
 :table-number: 2
 :toc:
 
-TITAN is equipped with several standard encoding/decoding mechanisms. A part of these functions reside in the core library, but the type-dependent part must be generated by the Java code generator. In order to reduce the code size and compilation time, the code generation for encoding functions (separately for different encoders) can be switched off if they are not needed as described in <<5-compiling_ttcn3_and_asn1_modules.adoc #build-options, Build Options>>.
+TITAN is equipped with several standard encoding/decoding mechanisms. A part of these functions reside in the core library, but the type-dependent part must be generated by the Java code generator. In order to reduce the code size and compilation time, the code generation for encoding functions (separately for different encoders) can be switched off if they are not needed as described in <<5-compiling_ttcn3_and_asn1_modules.adoc#build-options, Build Options>>.
 
 To make it easier to use the encoding features, a unified common API was developed. With help of this API the behaviour of the test executor in different error situations can be set during coding. There is also a common buffer class. The details of the above mentioned API as well as the specific features of the certain encoders are explained in the following sections.
 

usrguide/java_referenceguide/13-tips_&_troubleshooting.adoc

@@ -93,7 +93,7 @@ public class MyModule_externalfunctions {
 ----
 
 
-Both pre-defined and user-defined TTCN–3 data types can be used as parameters and/or return types of the Java functions. The detailed description of the equivalent Java classes as well as the name mapping rules are described in chapter <<12-mapping_ttcn3_data_types_to_java_constructs.adoc #mapping-of-names-and-identifiers, Mapping of Names and Identifiers>>.
+Both pre-defined and user-defined TTCN–3 data types can be used as parameters and/or return types of the Java functions. The detailed description of the equivalent Java classes as well as the name mapping rules are described in chapter <<12-mapping_ttcn3_data_types_to_java_constructs.adoc#mapping-of-names-and-identifiers, Mapping of Names and Identifiers>>.
 
 Using templates as formal parameters in external functions is possible, but not recommended because the API of the classes realizing templates is not documented and subject to change without notice.
 

usrguide/java_referenceguide/9-test_ports.adoc

@@ -14,7 +14,7 @@ A Test Port consists of two parts. One part is generated automatically by the Ja
 
 The other part is a Java class, which is written mainly by the user. This class can be found in a separate Java file (their suffixes are `.java`). It is recommended to store this file in a folder separate from the generated java files (for example called `user_provided`), so as it should not be deleted when clearing the project.
 The name of the source files and the Java class have to be identical to the name of the port type. And the Java class has to be located in the Java package whos name is generated as `org.eclipse.titan.` + projectname + `.user_provided`.
-Please note that the name mapping rules described in <<5-mapping_ttcn3_data_types_to_c+\+_constructs.adoc#mapping-of-names-and-identifiers, Mapping of Names and Identifiers>> also apply to these class and file names.
+Please note that the name mapping rules described in <<12-mapping_ttcn3_data_types_to_java_constructs.adoc#mapping-of-names-and-identifiers, Mapping of Names and Identifiers>> also apply to these class and file names.
 
 During the compilation, when the Java compiler encounters the usage of a Test Port that does not yet has a user generated implementation, it will report an error in the generated code for missing its import. Also offering Quick Fixes either by simply bringing the mouse cursor over the error location, or by right clicking and selecting Quick Fix from the menu. Using the action that starts like `Create class 'MyMessagePort' in package ...` eclipse will automatically generate the class the user needs.
 Once the class is create one should set its base class and right click in its body part selecting the `Source`/`Override\Implement Methods...` to automatically generate a skeleton for the needed functions.
@@ -305,13 +305,13 @@ Outgoing operations are `send` (specific to message based ports); `call`, `reply
 
 The Test Port class has an overloaded function called `outgoing_send` for each outgoing message type. This function will be called when a message is sent on the port and it should be routed to the system (that is, SUT) according to the addressing semanticsfootnote:[That is, the port has exactly one mapping and either the port has no connections or the message is explicitly addressed by a `send (…) to system` statement.] of TTCN–3. The messages (implicitly or explicitly) addressed to other test components are handled inside the test executor; the Test Ports have nothing to do with them. The function `outgoing_send` will be also called if the port has neither connections nor mappings, but a message is sent on it.
 
-The only parameter of `outgoing_send` contains a read-only reference to the message in the internal data representation format of the test executor. The access methods for internal data types are described in <<12-mapping_ttcn3_data_types_to_java_constructs.adoc #predefined-ttcn-3-data-types, Predefined TTCN–3 Data Types>>. The test port writer should encode and send the message towards SUT. For information on how to use the standard encoding functions like RAW, please consult the earlier chapters of this document. Sending a message on a not started port causes a dynamic test case error. In this case `outgoing_send` will not be called.
+The only parameter of `outgoing_send` contains a read-only reference to the message in the internal data representation format of the test executor. The access methods for internal data types are described in <<12-mapping_ttcn3_data_types_to_java_constructs.adoc#predefined-ttcn-3-data-types, Predefined TTCN–3 Data Types>>. The test port writer should encode and send the message towards SUT. For information on how to use the standard encoding functions like RAW, please consult the earlier chapters of this document. Sending a message on a not started port causes a dynamic test case error. In this case `outgoing_send` will not be called.
 
 ==== Call, Reply and Raise Functions
 
 The procedure based Test Port class has overloaded functions called `outgoing_call`, `outgoing_reply` and `outgoing_raise` for each `call`, `reply` and `raise` operations, respectively. One of these functions will be called when a port-operation is addressing the system (that is, SUT using the to `system` statement).
 
-The only parameter of these functions is an internal representation of the signature parameters (and possibly its return value) or the exceptions it may raise. The signature classes are described in <<5-mapping_ttcn3_data_types_to_c++_constructs.adoc#using-the-signature-classes,Using the Signature Classes>>.
+The only parameter of these functions is an internal representation of the signature parameters (and possibly its return value) or the exceptions it may raise. The signature classes are described in <<12-mapping_ttcn3_data_types_to_java_constructs.adoc#using-the-signature-classes,Using the Signature Classes>>.
 
 === Incoming Operations
 
@@ -565,7 +565,7 @@ The following sections deal with logging and error handling in Test Ports.
 
 Test Ports may record important events in the Test Executor log during sending/receiving or encoding/decoding messages. Such log messages are also good for debugging fresh code.
 
-The Test Port member functions may call the functions of class `TTCN_Logger`. These functions are detailed in <<6-tips_&_troubleshooting.adoc#logging-in-test-ports-or-external-functions, Logging in Test Ports or External Functions>>.
+The Test Port member functions may call the functions of class `TTCN_Logger`. These functions are detailed in <<13-tips_&_troubleshooting.adoc#logging-in-test-ports-or-external-functions, Logging in Test Ports or External Functions>>.
 
 If there are many points in the Test Port code that want to log something, it can be a good practice to write a common log function in the Test Port class. We show here an example where the calling of `log` uses Java's MessageFormat.format to create a custom message, and inside the `log` function TTCN_Logger.log_event demonstrates logging using the standard C function `printf` style and forwards the message to the Test Executor’s logger:
 
@@ -615,7 +615,7 @@ This function puts an entry in the executor’s log with severity `TTCN_WARNING`
 
 == Setting timestamps
 
-In order to use the timestamp redirects (`-> timestamp`) described in chapter 5 of the TTCN-3 standard extension `TTCN-3 Performance and Real Time Testing` (ETSI ES 202 782 V1.3.1, <<7-references.adoc#_16, [16]>>) the test port writer needs to add extra code to set the timestamps for the incoming and outgoing port operations of each port with the `realtime` clause.
+In order to use the timestamp redirects (`-> timestamp`) described in chapter 5 of the TTCN-3 standard extension `TTCN-3 Performance and Real Time Testing` (ETSI ES 202 782 V1.3.1, <<14-references.adoc#_16, [16]>>) the test port writer needs to add extra code to set the timestamps for the incoming and outgoing port operations of each port with the `realtime` clause.
 
 === Incoming operations