CRBT logic - Revision history

Monica: /* Abnormal procedures */

2013-10-28T11:16:15Z

‎Abnormal procedures

Monica: /* Abnormal procedures */

2013-10-28T11:15:30Z

‎Abnormal procedures

Monica: /* 1.2.5 Errors received from SSF / Timeout detected for class 1 and 3 operations */

2013-10-28T11:13:34Z

‎1.2.5 Errors received from SSF / Timeout detected for class 1 and 3 operations

Monica: /* 1.2.3 Application context mismatch */

2013-10-28T11:13:20Z

‎1.2.3 Application context mismatch

Monica at 11:12, 28 October 2013

2013-10-28T11:12:11Z

Monica: /* Behaviour */

2013-10-28T11:11:41Z

‎Behaviour

Monica: /* Yate side */

2013-10-28T11:09:49Z

‎Yate side

Monica: /* Script side */

2013-10-28T11:06:53Z

‎Script side

Monica at 11:05, 28 October 2013

2013-10-28T11:05:57Z

Monica: /* Script side */

2013-10-28T11:05:06Z

‎Script side

@@ Line 290: / Line 290: @@
-Situations described in sections 2.1.2.1 - 2.1.2.4 shall also apply here.
+Situations described in sections 2.1.2.1 - 2.1.2.4 shall also apply here:
-* [[#Initial DP ServiceKey mismatch / DP mismatch ]]
+* [[#Initial DP ServiceKey mismatch / DP mismatch|Initial DP ServiceKey mismatch / DP mismatch]]
-* [[#Initial DP missing parameters ]]
+* [[#Initial DP missing parameters| Initial DP missing parameters]]
-* [[#Application context mismatch ]]
+* [[#Application context mismatch| Application context mismatch]]
-* [[#Receiving an unsupported CAMEL phase ]]
+* [[#Receiving an unsupported CAMEL phase| Receiving an unsupported CAMEL phase]]
 ====Errors received from SSF====

@@ Line 290: / Line 290: @@
-Situations described in sections 1.2.1 - 1.2.4 shall also apply here.
+Situations described in sections 2.1.2.1 - 2.1.2.4 shall also apply here.
+* [[#Initial DP ServiceKey mismatch / DP mismatch ]]
 ====Errors received from SSF====

@@ Line 252: / Line 252: @@
-=====1.2.5 Errors received from SSF / Timeout detected for class 1 and 3 operations=====
+=====Errors received from SSF / Timeout detected for class 1 and 3 operations=====
 The following schematics describe general error procedures when a error is reported by the SSF or when a result for an operation is not received in the specified time allotted for the operation.
@@ Line 269: / Line 269: @@
                    SCP can be in either of the states : 6  - 11
 .  <-------------------- MoveLeg --------------------------------------------------------
 ===Behaviour CAMEL phase 2/3===

← Older revision		Revision as of 11:13, 28 October 2013
Line 232:		Line 232:
	<-------------------- ReturnError(missingParameter) -----------------------------------		<-------------------- ReturnError(missingParameter) -----------------------------------

−	=====~~1.2.3~~ Application context mismatch=====	+	=====Application context mismatch=====

@@ Line 271: / Line 271: @@
-==Behaviour CAMEL phase 2/3==
+===Behaviour CAMEL phase 2/3===
-===Normal procedure for dialogue===
+====Normal procedure for dialogue====
@@ Line 288: / Line 288: @@
 . <------------------------- CONT ---------------------------------------------------------
-===Abnormal procedures===
+====Abnormal procedures====
 Situations described in sections 1.2.1 - 1.2.4 shall also apply here.
-===Errors received from SSF===
+====Errors received from SSF====

@@ Line 165: / Line 165: @@
 * the name of the local application should match the name set in ''$appName'' for the script
-===Script behaviour===
+==Script behaviour==
 This is a global script that awaits dialog beginnings from SSFs and it is able to handle CAMEL phases 2, 3 and 4.
@@ Line 183: / Line 182: @@
 Bellow there is detailed description of how the script will act in different scenarios.
-====Behaviour CAMEL phase 4====
+===Behaviour CAMEL phase 4===
-=====Normal procedure for dialogue=====
+====Normal procedure for dialogue====
 In case of a normal, error free dialogue, things will proceed according to the describing flow below:
@@ Line 214: / Line 213: @@
 . <-------------- RC (cause received in ERBE/Busy) --------------------------
-=====Abnormal procedures=====
+====Abnormal procedures====
 The following schematics will describe the behaviour of the script in certain scenarios.
 The numbers assigned above (in the normal dialogue schematic) designate states in the dialogue. These will be used to describe a starting state for when an error is detected.
-======Initial DP ServiceKey mismatch /  DP mismatch======
+=====Initial DP ServiceKey mismatch /  DP mismatch=====
@@ Line 226: / Line 225: @@
          <-------------------- ReturnError(unexpectedDataValue) --------------------------------
-======Initial DP missing parameters======
+=====Initial DP missing parameters=====
@@ Line 233: / Line 232: @@
          <-------------------- ReturnError(missingParameter) -----------------------------------
-======1.2.3 Application context mismatch======
+=====1.2.3 Application context mismatch=====
@@ Line 240: / Line 239: @@
          <-------------------- U_Abort (user-application-context-name-not-supported) -----------
-======Receiving an unsupported CAMEL phase======
+=====Receiving an unsupported CAMEL phase=====
 This error can be detected upon receiving an InitialDP operation, or in the ReturnResult for InitiateCallAttempt. Depending upon the state when the error is detected, handling will be done as described below:
@@ Line 253: / Line 252: @@
-======1.2.5 Errors received from SSF / Timeout detected for class 1 and 3 operations======
+=====1.2.5 Errors received from SSF / Timeout detected for class 1 and 3 operations=====
 The following schematics describe general error procedures when a error is reported by the SSF or when a result for an operation is not received in the specified time allotted for the operation.
@@ Line 272: / Line 271: @@
-===Behaviour CAMEL phase 2/3===
+==Behaviour CAMEL phase 2/3==
-====Normal procedure for dialogue====
+===Normal procedure for dialogue===
@@ Line 289: / Line 288: @@
 . <------------------------- CONT ---------------------------------------------------------
-====Abnormal procedures====
+===Abnormal procedures===
 Situations described in sections 1.2.1 - 1.2.4 shall also apply here.
-====Errors received from SSF====
+===Errors received from SSF===

@@ Line 161: / Line 161: @@
    export_xml_as=both - how to export the XML part: string, object or both?
- '''Note:'''
+'''Note:'''
- * setting port to 0 will disable the support for TCP applications
+* setting port to 0 will disable the support for TCP applications
- * the name of the local application should match the name set in ''$appName'' for the script
+* the name of the local application should match the name set in ''$appName'' for the script
 ==Behaviour==

@@ Line 110: / Line 110: @@
 ** ''yes''
 ** ''true''
 * 11. '''$shortTimer''', '''$mediumTimer''', '''$longTimer''' - integer. Timeout values for operations. Some operation have short timeouts, other medium or long times. These parameters configure their values. These default to 3,6 and 9 seconds respectively. In case of larger delays on the network, they should be increased.
@@ Line 124: / Line 123: @@
 * 14. '''$noAnswerTimer''' - integer. Timer value to be set when arming o/tNoAnswer. If not configured, this value will not be provided by RRBE. If set, the SSF should report a noAnswer DP after the timer value has expired and no other event was armed.
 * 15. '''$prearrangedEndOn''' - array. List of DP events reported as notifications that should determine a prearranged end situation. The listed events should match events listed for BCSMs in camel_map module (see  s_eventTypeBCSM[] in camel_map.cpp). In no events are listed, basic termination will be assumed for all DPs that represent an end to the TCAP dialogue.

@@ Line 143: / Line 143: @@
 On the Yate side, the ''camel_map'' module must be configured through ''camel_map.conf''.
-For functionality provided through a TCP socket, a @@[tcap name]@@ section should be configured. A section looks like this:
+For functionality provided through a TCP socket, a <tt>[tcap name]</tt> section should be configured. A section looks like this:
    [tcap camel] -- what comes after ''tcap'' will be the name of the translator
@@ Line 155: / Line 155: @@
-For functionality through Yate messages, an additional section, named @@[local appName]@@ should be configured:
+For functionality through Yate messages, an additional section, named <tt>[local appName]</tt> should be configured:
    [local camelLocal] - what comes after ''local'' will be the name of the application

@@ Line 36: / Line 36: @@
 * 10. '''$buildSRFNum''' - string. It specifies how the address of the gsmSRF for the EstablishTemporaryConnection operation will be built. It can have of of the following values:
-** ''prefix_called'' - build the gsmSRF address following this rule @@$srfNumber.$srfSeparator.$correlationID.$srfSeparator.$sfcID@@.
+** ''prefix_called'' - build the gsmSRF address following this rule <tt>$srfNumber.$srfSeparator.$correlationID.$srfSeparator.$sfcID</tt>.
 ** ''fixed_number'' - use ''$srfNumber'' as a fixed address for the gsmSRF address. Setting this means that correlationID and scfID for ETC wil be set separately.