CAMEL proxy - Revision history

Monica: /* General */

2013-10-28T11:47:56Z

‎General

Monica: /* Multiple Continue/ContinueWithArgument handling */

2013-10-28T11:46:12Z

‎Multiple Continue/ContinueWithArgument handling

Monica: /* RequestReportBCSM and EventReportBCSM handling */

2013-10-28T11:45:45Z

‎RequestReportBCSM and EventReportBCSM handling

Monica: /* General */

2013-10-28T11:44:17Z

‎General

Monica: /* General */

2013-10-28T11:44:03Z

‎General

Monica: /* General */

2013-10-28T11:43:48Z

‎General

Monica: /* RequestReportBCSM and EventReportBCSM handling */

2013-10-28T11:43:07Z

‎RequestReportBCSM and EventReportBCSM handling

Monica: /* Yate side */

2013-10-28T11:42:25Z

‎Yate side

Monica: /* Yate side */

2013-10-28T11:40:51Z

‎Yate side

Monica: /* Yate side */

2013-10-28T11:40:34Z

‎Yate side

@@ Line 553: / Line 553: @@
 The main characteristics of the proxy behaviour are:
 * when receiving Invoke components from the SSF, the proxy will decide to which SCFs they should be passed along. The decision is taken by looking at the configuration of the SCF for what operation it specifically handles. The operation will be passed only to those SCFs that were configured to receive that specific information. If no SCF was configured to accept the incoming Invoke for an operation, the proxy will return an error to the SSF. InitialDP and EventReportBCSM operations are excluded from this kind of handling.
 * if for a Invoke component arrived from the SSF there are multiple SCFs that match it and to which it should be sent, the proxy will send it in order of SCF priority.
 * Invoke components from SCFs will be sent to the SSF and the proxy will keep track to which SCF each component belongs to.
 * Result and ReturnError components from the SSF will be passed by the proxy to the SCF that initially sent it.
 * sending of an Invoke component to multiple SCFs is done in a serialized fashion. It will send the message to the first SCF, then to the second. Depending on the state of the dialog with the SSF and of the state of the dialogs with the SCFs, the proxy first awaits or not a response from the SCF before sending the Invoke to the next SCF. If the received Invoke caused a SCF to change its state to ''WFI (Waiting For Instructions - from SCF)'', the proxy will first await a response containing a Continue or ContinueWithArgument operation (operation that moves the SCF into ''MON - Monitoring'' state) before sending the Invoke to the next SCF. This means that while a dialog with a SCF is in ''WFI'' state, it can exchange multiple messages with the SSF until the SCF goes into ''MON'' state, and just then the original Invoke will be sent to the next SCF. The message flow looks like this:

@@ Line 629: / Line 629: @@
 * if there is a mix of CWA and CONT invocations, all CONT invocations will be removed and the last CWA is moved to being the last invocation in the message.
-Question: how does SSF handle multiple CWA?<br/>
+'''Question:''' how does SSF handle multiple CWA?<br/>
-Answer: A SSF should be able to handle multiple CWAs, as usually multiple CWA are sent with different parameters: one can only modify call parameters, one can specify a continue with changed parameters on a certain leg or segment.
+'''Answer:''' A SSF should be able to handle multiple CWAs, as usually multiple CWA are sent with different parameters: one can only modify call parameters, one can specify a continue with changed parameters on a certain leg or segment.
 ===Leg ID and DP rewriting===

@@ Line 607: / Line 607: @@
 * when receiving an EventReportBCSM invocation from the SSF, the proxy will send it to all SCFs that had previously armed the reported DP. The proxy will not rewrite the mode how this event is reported as it interferes with situations where the dialogue with the SCF that requested ''interrupted'' might have been terminated due to a exception. Rewriting it to a ''notify'' will not correspond with the SSF BCSM state.
-Question: It may turn that SCF requested ''notify'', but got ''interrupted'' EventReportBCSM, right? Is it OK? <br/>
+'''Question:''' It may turn that SCF requested ''notify'', but got ''interrupted'' EventReportBCSM, right? Is it OK? <br/>
-Answer: Yes, that's the behaviour right now, but it can be changed to report notify. This would mean adding a configuration parameter as to what to do when this situation occurs: either pass it to the SCF how it was received (what it does right now)  or let the proxy generate a Continue if it could not send it with interrupted to anyone.
+'''Answer:''' Yes, that's the behaviour right now, but it can be changed to report notify. This would mean adding a configuration parameter as to what to do when this situation occurs: either pass it to the SCF how it was received (what it does right now)  or let the proxy generate a Continue if it could not send it with interrupted to anyone.
-Question: Does this mean, that every SCF, which received ''interrupted'' EventReportBCSM, is obliged to decide on it and issue CONT in the end, even if it didn't intend to receive such an event in ''interrupted'' mode?<br/>
+'''Question:''' Does this mean, that every SCF, which received ''interrupted'' EventReportBCSM, is obliged to decide on it and issue CONT in the end, even if it didn't intend to receive such an event in ''interrupted'' mode?<br/>
-Answer: Yes.
+'''Answer:''' Yes.
-Question: Are CRBT scripts ready for this scenario?<br/>
+'''Question:''' Are CRBT scripts ready for this scenario?<br/>
-Answer: Yes, the CRBT script when handling DPs is prepared to handle such a situation.
+'''Answer:''' Yes, the CRBT script when handling DPs is prepared to handle such a situation.
-Question: It seems better to issue CONT by proxy and change ''interrupted'' to what was originally requested by certain SCF. Not sure.<br/>
+'''Question:''' It seems better to issue CONT by proxy and change ''interrupted'' to what was originally requested by certain SCF. Not sure.<br/>
-Answer: Yes, the proxy could decide to send a Continue to the SSF if none of the SCFs requested it in "interrupted" mode. If one of the SCFs requested "interrupted", the proxy will expect the SCF to send the Continue.
+'''Answer:''' Yes, the proxy could decide to send a Continue to the SSF if none of the SCFs requested it in "interrupted" mode. If one of the SCFs requested "interrupted", the proxy will expect the SCF to send the Continue.
 ===Multiple Continue/ContinueWithArgument handling===

@@ Line 548: / Line 548: @@
 ===General===
-The main purpose of the proxy is to act as a SCF on the SSF side and as a SSF on the proxied SCF side.<br/>
+The main purpose of the proxy is to act as a SCF on the SSF side and as a SSF on the proxied SCF side.
 The proxy sits between the SSF and and the SCFs. From the point of view of the SSF, it will act as a SCF, from the point of view of the proxied SCFs, it will act as a SSF.
-<br/>
 The main characteristics of the proxy behaviour are:
 * when receiving Invoke components from the SSF, the proxy will decide to which SCFs they should be passed along. The decision is taken by looking at the configuration of the SCF for what operation it specifically handles. The operation will be passed only to those SCFs that were configured to receive that specific information. If no SCF was configured to accept the incoming Invoke for an operation, the proxy will return an error to the SSF. InitialDP and EventReportBCSM operations are excluded from this kind of handling.

@@ Line 549: / Line 549: @@
 The main purpose of the proxy is to act as a SCF on the SSF side and as a SSF on the proxied SCF side.<br/>
-<br/>
 The proxy sits between the SSF and and the SCFs. From the point of view of the SSF, it will act as a SCF, from the point of view of the proxied SCFs, it will act as a SSF.
 <br/>

← Older revision		Revision as of 11:42, 28 October 2013
Line 541:		Line 541:

	'''NOTE!''' In a proxy scenario, please check that you won't have a valid <tt>[local crbt-scp]</tt> section configured in camel_map.conf. If so, this will allow to the camel_map module to catch messages emitted by the CRBT SCP that should have been catched by the proxy instead.		'''NOTE!''' In a proxy scenario, please check that you won't have a valid <tt>[local crbt-scp]</tt> section configured in camel_map.conf. If so, this will allow to the camel_map module to catch messages emitted by the CRBT SCP that should have been catched by the proxy instead.
		+
		+	==Proxy Behaviour==
		+
		+	Bellow, the behaviour of the CAMEL proxy implemented in ''camel_proxy.php'' is described.
		+
		+	===General===
		+
		+	The main purpose of the proxy is to act as a SCF on the SSF side and as a SSF on the proxied SCF side.
		+
		+	The proxy sits between the SSF and and the SCFs. From the point of view of the SSF, it will act as a SCF, from the point of view of the proxied SCFs, it will act as a SSF.
		+
		+	The main characteristics of the proxy behaviour are:
		+	* when receiving Invoke components from the SSF, the proxy will decide to which SCFs they should be passed along. The decision is taken by looking at the configuration of the SCF for what operation it specifically handles. The operation will be passed only to those SCFs that were configured to receive that specific information. If no SCF was configured to accept the incoming Invoke for an operation, the proxy will return an error to the SSF. InitialDP and EventReportBCSM operations are excluded from this kind of handling.
		+	* if for a Invoke component arrived from the SSF there are multiple SCFs that match it and to which it should be sent, the proxy will send it in order of SCF priority.
		+	* Invoke components from SCFs will be sent to the SSF and the proxy will keep track to which SCF each component belongs to.
		+	* Result and ReturnError components from the SSF will be passed by the proxy to the SCF that initially sent it.
		+	* sending of an Invoke component to multiple SCFs is done in a serialized fashion. It will send the message to the first SCF, then to the second. Depending on the state of the dialog with the SSF and of the state of the dialogs with the SCFs, the proxy first awaits or not a response from the SCF before sending the Invoke to the next SCF. If the received Invoke caused a SCF to change its state to ''WFI (Waiting For Instructions - from SCF)'', the proxy will first await a response containing a Continue or ContinueWithArgument operation (operation that moves the SCF into ''MON - Monitoring'' state) before sending the Invoke to the next SCF. This means that while a dialog with a SCF is in ''WFI'' state, it can exchange multiple messages with the SSF until the SCF goes into ''MON'' state, and just then the original Invoke will be sent to the next SCF. The message flow looks like this:
		+
		+	SSF Proxy SCF 1 SCF 2
		+	\|------- Invoke 1 ----------->\|WFI \| \|
		+	\| \|----- Invoke 1a ------>\|WFI \|
		+	\| \|<---- Invoke 2a -------\|WFI \|
		+	\|<------ Invoke 2a -----------\|WFI \| \|
		+	\|------- Result 2a ---------->\|WFI \| \|
		+	\| \|----- Result 2a ------>\|WFI \|
		+	\| \|<---- Invoke 3a CWA ---\|MON \|
		+	\| \|------------------------------ Invoke 1b --------->\|WFI
		+	\| \|<----------------------------- Invoke 2b ----------\|WFI
		+	\| \|<----------------------------- Invoke CONT 3b CONT-\|MON
		+	\|<------ Invoke 2b -----------\| \| \|
		+	\|<------ Invoke 3a CWA -------\|MON \| \|
		+	\| \| \| \|
		+	\| \| \| \|
		+	\|------- Invoke 4 ----------->\|MON \| \|
		+	\| \|------ Invoke 4a ----->\|MON \|
		+	\| \|------------------------------ Invoke 4b --------->\|MON
		+
		+	* if the proxy received a error or reject component from a SCF, it will check whether an error on that dialog is fatal (this is part of the SCF configuration), and if so, the proxy will abort the dialog with the SSF and with all SCFs.
		+	* when sending a operation in a WFI state, the proxy will start a timer for how long it will wait a response from the SCF to which it had just sent the operation. If the timer expires, it will send an abort on the dialogue with that SCF. If an error is fatal on this dialog, the dialogs with the SSF and other SCFs are also aborted. If not, the proxy will try to pass the operation to the next SCF that should receive it.
		+	* if an TCAP End message is received from a SCF and there other SCFs that have active dialogues with the SSF, the proxy will terminate the dialogue with just that SCFs. If the TCAP End message contained components, the proxy will rewrite the TCAP END to TCAP CONTINUE and send it to the SSF.
		+	* the proxy will set the required SS7 addressing information if so configured for a SCF. '''NOTE!''' For external SCFs, the configuration parameter for addressing must not be empty. Refer to the the [[http://crbt-doc.lan/index.php?n=CRBT.ProxyConfiguration\|configuration page]] for how to do this.
		+
		+
		+	===InitialDP handling===
		+
		+	The initialDP operation has special handling. Upon receiving this operation from the SSF, the proxy will take the following steps:
		+	* it will check for presence of the ''serviceKey'' parameter. If missing, it will reject the operation and end the dialogue with the SSF.
		+	* then it will compare the received serviceKey value with the one configured for the proxy. If they do not match, the proxy will return an error for the operation and end the dialogue with the SSF.
		+	* it will check for the presence of the ''eventTypeBCSM'' parameter. If missing, the proxy will return an error for the operation and end the dialogue with the SSF.
		+	* after passing these checks, the proxy will look for SCFs that match the BCSM event that triggered the IDP. If no SCFs match the detection point, the proxy will return an error for the operation and end the dialogue with the SSF. Otherwise, it will build dialogues towards every matched SCF and, build IDP operation for them and start processing.
		+	* if a matched SCF requires another service key value or another application context, the proxy will replace these values with the ones configured for the SCF.
		+
		+	===RequestReportBCSM and EventReportBCSM handling===
		+
		+
		+	The RequestReportBCSM and EventReportBCSM operation are specially handled as seeing that multiple SCFs can arm the same DP (detection point) with different event modes: ''interrupted, notify, transparent''. A subsequent arming request for a DP will override the previous arming mode and this can be a problem if one SCF first armed a DP in interrupted mode and another one puts it afterwards in notify or transparent mode.
		+	If a DP was rearmed to ''notify'' from ''interrupted'', this will mess up the handling for the first SCF as it probably armed it as ''interrupted'' as to not continue with call handling until it decided upon something. A ''notify'' means that the SSF continued with call handling without waiting anything from the SCF. ''transparent'' means that the SCF will not be notified about the event, which again messes up the handling of the first SCF.
		+
		+	In order to prevent that, proxy does the following:
		+	* the proxy keeps track about how DPs were armed for the dialogue with the SSF, and also for the dialogues with the SCFs.
		+	* upon a RequestReportBCSM invocation from a SCF, it will check for all requested DPs if the DP wasn't already armed previously. If it wasn't already armed, the proxy will leave it as is. If it was already armed, it will check how was it armed and depending on the situation, will leave it as is or rewrite it. For example:
		+	** if the DP was previously armed as ''transparent'' and now it is requested as ''notify'' or ''interrupted'', the proxy will leave it the invocation as is and update only the information about how was it armed.
		+	** if the DP was previously armed as ''notify'' and now it is requested as ''interrupted'', , the proxy will leave it the invocation as is and update only the information about how was it armed.
		+	** if the DP was previously armed as ''interrupted'' and now it is requested as ''notify'' or ''transparent, , the proxy will rewrite the arming mode in the invocation.
		+	** if the DP was previously armed as ''notify'' and now it is requested as ''transparent, , the proxy will rewrite the arming mode in the invocation.
		+	* when receiving an EventReportBCSM invocation from the SSF, the proxy will send it to all SCFs that had previously armed the reported DP. The proxy will not rewrite the mode how this event is reported as it interferes with situations where the dialogue with the SCF that requested ''interrupted'' might have been terminated due to a exception. Rewriting it to a ''notify'' will not correspond with the SSF BCSM state.
		+
		+	Question: It may turn that SCF requested ''notify'', but got ''interrupted'' EventReportBCSM, right? Is it OK? \\
		+	Answer: Yes, that's the behaviour right now, but it can be changed to report notify. This would mean adding a configuration parameter as to what to do when this situation occurs: either pass it to the SCF how it was received (what it does right now) or let the proxy generate a Continue if it could not send it with interrupted to anyone.
		+
		+	Question: Does this mean, that every SCF, which received ''interrupted'' EventReportBCSM, is obliged to decide on it and issue CONT in the end, even if it didn't intend to receive such an event in ''interrupted'' mode?\\
		+	Answer: Yes.
		+
		+	Question: Are CRBT scripts ready for this scenario?\\
		+	Answer: Yes, the CRBT script when handling DPs is prepared to handle such a situation.
		+
		+	Question: It seems better to issue CONT by proxy and change ''interrupted'' to what was originally requested by certain SCF. Not sure.\\
		+	Answer: Yes, the proxy could decide to send a Continue to the SSF if none of the SCFs requested it in "interrupted" mode. If one of the SCFs requested "interrupted", the proxy will expect the SCF to send the Continue.
		+
		+	===Multiple Continue/ContinueWithArgument handling===
		+
		+
		+	The proxy deals with the situation in which SCFs that were all in ''WFI'' state send each a Continue (CONT)/ ContinueWithArgument (CWA) invocation to get into ''MON'' state. The proxy gathers all their invocations in a single message to the SSF. Because sending multiple CONT/CWA in a single message to the SSF can alterate the BCSM processing - for example, a CONT will stop processing of subsequent operation invocation until the next interrupt - the proxy ensures that it sends a valid mesage to the SSF in order to process all the operations that were requested by the SCFs.
		+	For that, the proxy will do the following:
		+	* if from the view of the proxy, the dialogue with the SSF should result in a ''WFI'' state in the BCSM, it will remove from the message all CONT/CWAs.
		+	* if in the message there are only CONT invocations, only the last one is left, the other ones are removed before sending.
		+	* in in the message there are onle CWA invocations, they are all kept, but the last CWA is moved to also be the last invocation in the message.
		+	* if there is a mix of CWA and CONT invocations, all CONT invocations will be removed and the last CWA is moved to being the last invocation in the message.
		+
		+	Question: how does SSF handle multiple CWA?<br/>
		+	Answer: A SSF should be able to handle multiple CWAs, as usually multiple CWA are sent with different parameters: one can only modify call parameters, one can specify a continue with changed parameters on a certain leg or segment.
		+
		+	===Leg ID and DP rewriting===
		+
		+	In case of CAMEL phase 4 call party handling (what the CRBT SCF does), the proxy does special handling of leg IDs and DPs in order to deal with the fact that leg 2 is disconnected and leg 3 is created. The PPS SCF has no way to know that leg 2 doesn't exist anymore, so handling for dealing with the fact that from its point of view leg 2 still exists has been implemented:
		+	* for this, the proxy will keep track of what legs exist. When a successful InitiateCallAttempt operation has occurred, the proxy will consider it as a replacement for a previously disconnected leg, if that exists.
		+	* when the proxy receives an operation that request actions on a leg previously disconnected, the proxy will rewrite the leg ID towards the SSF to match with the one, that from it's point of view, replaced it. If an operation arrives from the SSF and must be transmitted to a SCF that doesn't not know that the leg it had requested no longes exists, it will rewrite it to its replacement.
		+	* in case of a RRBE operation, if the leg ID must be rewritten, the armed DPs will also be rewritten to matcht the BCSM state machine for the leg that is the replacement (leg 2 was a T-BSCM so PPS would arm T-BCSM DPs, but replacing the leg with leg 3, which is a result of an ICA, means arming DPs for O-BCSM events)
		+	* when a ERBE operation is received from the SSF, if required, the proxy will rewrite the leg ID and reported DP to the SCF that doesn't know that the leg was disconnected.
		+	* leg rewriting handling also aplies to ApplyCharging and ApplyChargingReport operations.
		+
		+	In case of a SCF that had armed DPs on a leg that was subsequently disconnected, the proxy, in order to ensure that events will be reported to the SCF even after the leg was disconnected, will send to the SSF a RRBE operation to arm on the replacement leg all DPs that are equivalent with the ones that were armed for the disconnected leg.

@@ Line 532: / Line 532: @@
    print-messages=true
    add-encoding=false
-−
    [local ext-scp]
    ;enable=no

@@ Line 503: / Line 503: @@
 On the Yate side, the ''camel_map'' module must be configured through ''camel_map.conf''.
-In order for the module to ensure communication with the SSF, a section named @@[local name_of_proxy]@@ must be configured:
+In order for the module to ensure communication with the SSF, a section named <tt>[local name_of_proxy]</tt> must be configured:
    [local proxyName] - what comes after ''local'' will be the name of the application
@@ Line 511: / Line 511: @@
    export_xml_as=both - how to export the XML part: string, object or both?
-A @@[tcap name]@@ section must be configured also. A section looks like this:
+A <tt>[tcap name]</tt> section must be configured also. A section looks like this:
    [tcap scp] -- what comes after ''tcap'' will be the name of the translator
@@ Line 523: / Line 523: @@
-For an external proxied SCF, additional @@[local scfName]@@ and @@[tcap name]@@ sections must be configured:
+For an external proxied SCF, additional <tt>[local scfName]</tt> and <tt>[tcap name]</tt> sections must be configured:
    [tcap msc]
@@ Line 540: / Line 540: @@
-'''NOTE!''' In a proxy scenario, please check that you won't have a valid @@[local crbt-scp]@@ section configured in camel_map.conf. If so, this will allow to the camel_map module to catch messages emitted by the CRBT SCP that should have been catched by the proxy instead.
+'''NOTE!''' In a proxy scenario, please check that you won't have a valid <tt>[local crbt-scp]</tt> section configured in camel_map.conf. If so, this will allow to the camel_map module to catch messages emitted by the CRBT SCP that should have been catched by the proxy instead.