Difference between revisions of "CAMEL proxy"
(→RequestReportBCSM and EventReportBCSM handling) |
(→General) |
||
| (One intermediate revision by one user not shown) | |||
| Line 553: | Line 553: | ||
The main characteristics of the proxy behaviour are: | 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. | * 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. | * 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. | * 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. | * 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: | * 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 634: | ||
* 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. | * 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=== | ===Leg ID and DP rewriting=== | ||
Latest revision as of 14:47, 28 October 2013
The camel_proxy.php module provides functionality that allows that a single gsmSSF CAMEL invocation be proxied to multiple SCFs. The aim of this module is to provide a way of providing multiple CAMEL services on a single CAMEL request.
The main purpose is to be able to provide CRBT and PPS (PrePaid Service) facilities in parallel.
The layout for such a scenario will look like this:
What it basically does is that for one IDP invocation, the proxy will be able to translate it to multiple IDPs sent to multiple SCPs, either locally (like the CRBT one) or external. The proxy keeps an evidence of these multiple invocations and aggregates them into a single, valid dialogue with the invoking SSP.
Contents |
[edit] Camel Proxy Module Configuration
The configuration file is camel_bcsm_proxy.conf
[edit] Module configuration
[edit] 'general' section
application: Application parameter in camel messages sent/handled for SSF dialogs.
This parameter is required and is not applied on reload (can't be changed after module starts).
gt: Global Title to be set in the first message sent in the SSF dialog.
This parameter is applied on reload.
TCAP address parameters to be set in the first message sent back to SSF can also be set using addr. prefix.
E.g. GT can be set as addr.CallingPartyAddress.gt along with other parameters like number nature addr.CallingPartyAddress.nature.
Setting the GT without other parameters is the same as:
addr.CallingPartyAddress.gt=[GT set]
addr.CallingPartyAddress.route=gt
addr.CallingPartyAddress.gt.encoding=bcd
addr.CallingPartyAddress.gt.translation=0
addr.CallingPartyAddress.gt.plan=isdn
addr.CallingPartyAddress.gt.nature=international
servicekey: CAMEL serviceKey to check when in received initialDP and set when forwarding them to SCFs.
Allowed interval: 0..2147483647.
Defaults to 0 if missing or invalid.
This parameter is applied on reload for new dialogs only.
query_scf: Boolean value indicating whether to query for proxied SCFs update when processing initialDP.
Is enabled a 'scf.query' message will be enqueued and the module will wait for a 'scf.response' message to continue IDP processing.
Defaults to no.
print_msg: boolean/string: Print sent/received messages to output if debug level is at least 9.
Allowed values are boolean values or 'verbose' string.
If verbose is specified, the message will be dumped on output.
Defaults to no.
print_xml: boolean/string: Print sent/received XML data to output if debug level is at least 9.
This parameter is ignored if print_msg is disabled.
Allowed values are boolean values or 'verbose' string.
If verbose is specified, XML elements' children, attributes or text will be shown on separate lines.
Defaults to no.
idp_calling_required: boolean: Calling party number is required (non empty) in initialDP.
Default to yes.
idp_called_required: boolean: Called party number is required (non empty) in initialDP.
Default to yes.
dispatcher_maxthreads: integer: Maximum number of message dispatch threads to use.
Set to 0 to enqueue messages using yate engine.
Defaults to 0.
When reloaded it can't be set to 0 (e.g. once set to a non 0 value it can be changed to non 0 values only).
[edit] Proxied SCF section(s)
enable: boolean: Enable the SCF.
Defaults to yes.
priority: integer: Priority in handling messages from SSF.
Defaults to 0.
servicekey: integer: Value with which the IDP serviceKey should be rewritten.
Allowed interval: 0..2147483647.
Defaults to SSF service key set in 'general' section.
dp: string: Comma separated list of detection points that should match the one received in IDP in order to contact this SCF.
Items may be DP value or name.
Defaults to termAttemptAuthorized if empty or all DPs are invalid.
endfatal: boolean: Indicate whether or not terminate the proxy dialog when this dialog ends.
Defaults to no.
errorfatal: boolean: Indicate whether or not an error or reject component from the SCF should terminate the whole proxy dialog.
Defaults to no.
local: boolean: The SCF is local (a local application) or external (it passes through the SS7 network to reach it).
Defaults to no (external application).
instances: integer: Number of local application instances.
This parameter is ignored for non local SCFs.
If non 0 it must be set to a value greater then 1.
Defaults to 0.
If non 0 the module will build the required number of SCFs and will pick them using a round-robin algorithm.
Each application's name will be built from SCF application name concatenated with instance suffix startting from 1.
E.g.:
[proxy SCP] instances=2
Will build 2 applications: SCP1 and SCP2.
handles: string: Comma separated list of operations received from the SSF accepted by this SCF.
Except ERB (Event Report BCSM), which is sent to all SCFs that match the reported DP, all operations that are handled by a SCF should be listed, otherwise the proxy will report to the SSF an error.
waittime: integer: Time, in miliseconds, to wait for a result from a SCF while being in Waiting For Instructions state, after which the dialog is aborted.
Defaults to 3000.
Minimum allowed value is 1000.
All other parameters starting with 'addr.' prefix will be put in dialog begin message sent for this SCF.
They should be set for non local SCFs.
Parameters:
- addr.CalledPartyAddress.route - string. It can be set to values: gt/ssn. It specifies how the SCCP address should be routed.
- addr.CalledPartyAddress.ssn - integer. It's the SSN number in case of SSN routing.
- addr.CalledPartyAddress.gt - string. GTT number digits for the SCF.
- addr.CalledPartyAddress.gt.encoding - string. It specifies the encoding for the GT digits. It is usually set to bcd.
- addr.CalledPartyAddress.gt.tt - integer. It specifies the GT translation type. It is usually set to 0.
- addr.CalledPartyAddress.gt.np - string. The GT numbering plan. It is usually set to isdn. It can be one of the following values: unknown, isdn, e164, generic, data, x121, telex, maritime-mobile, e210, e211, land-mobile, e212, isdn-mobile, e214, network-specific.
- addr.CalledPartyAddress.gt.nature - string. It specifies the nature of the GT number. It is usually set to international.It can have one the following values: unknown, subscriber, national-reserved, national-significant, international.
- addr.CallingPartyAddress.route
- addr.CalledPartyAddress.ssn
- addr.CallingPartyAddress.gt
- addr.CallingPartyAddress.gt.encoding
- addr.CallingPartyAddress.gt.tt
- addr.CallingPartyAddress.gt.np
- addr.CallingPartyAddress.gt.nature
[edit] Example
[general] application=camelProxy servicekey=1 gt=8820003 [proxy crbt-scp] servicekey=2 local=true [proxy pps-scp] servicekey=99 priority=2 errorfatal=true handles=applyChargingReport addr.CalledPartyAddress.gt=8820007 addr.CalledPartyAddress.route=gt addr.CalledPartyAddress.gt.encoding=bcd addr.CalledPartyAddress.gt.tt=0 addr.CalledPartyAddress.gt.np=isdn addr.CalledPartyAddress.gt.nature=international addr.CallingPartyAddress.gt=8820003 addr.CallingPartyAddress.route=gt addr.CallingPartyAddress.gt.encoding=bcd addr.CallingPartyAddress.gt.tt=0 addr.CallingPartyAddress.gt.np=isdn addr.CallingPartyAddress.gt.nature=international
[edit] camel_map configuration
[local camelProxy] translator=scp_proxy capabilities=Camel [tcap scp_proxy] type=CAMEL tcap=tcap_msc port=0 [local pps-scp] translator=scp_pps capabilities=Camel [tcap scp_pps] type=CAMEL tcap=tcap_pps port=0
[edit] camel_bcsm_proxy.conf.sample
; NOTE: This module is not loaded automatically, it needs a line in yate.conf:
; [postload]
; ${modulepath}/sig/camel_bcsm_proxy${modsuffix}=yes
[general]
; Unless explicitly specified, all parameters are applied on reload for new
; dialogs only
; All parameters starting with 'addr.' prefix will be put in the first message sent to SSF
; application: string: Application parameter in camel messages sent by the module
; This parameter is required
; This parameter is not applied on reload
;application=
; gt: string: Global Title to be set in the first message sent in the SSF dialog
; This parameter is applied on reload for new dialogs only
; If non empty other calling party address parameters will be set to default values
; This parameter can be overriden by addr.CallingPartyAddress.gt parameter
;gt=
; servicekey: integer: CAMEL serviceKey to check in received initialDP messages and
; set when forwarding them to SCFs
; Allowed interval: 0..2147483647
; Defaults to 0 if missing or invalid
; This parameter is applied on reload for new dialogs only
;servicekey=0
; query_scf: boolean: Query for proxied SCFs update when processing initialDP
; Is enabled a 'scf.query' message will be enqueued and the module will wait
; for a 'scf.response' message to continue IDP processing
; The response must return the list of SCFs to proxy
; The list may be shorter then configured SCFs
; New SCFs, other then configured ones, will be ignored
; The following SCF parameters can be overridden: priority, servicekey, errorfatal,
; handles, waittime and all parameters starting with 'addr.' prefix
; Defaults to no
;query_scf=no
; component_ttl: integer: Component time to live in milliseconds
; Minimum allowed value is 1000
; Defaults to 15000
;component_ttl=15000
; dialog_idle_ttl: integer: Dialog idle (nothing sent/received) time to live in milliseconds
; Minimum allowed value is 1000
; It can be set to 0 to keep it alive until the remote party terminates the dialog
; Defaults to 5000
;dialog_idle_ttl=5000
; dialog_ended_ttl: integer: Ended dialog time to live in milliseconds
; Minimum allowed value is 1000.
; It can be set to 0 to remove the dialog after termination
; Defaults to 0
;dialog_ended_ttl=0
; export_xml_as: string: Specify in which way the XML will be passed along into
; Yate messages
; Allowed values are:
; - string: pass the XML as a string
; - object: pass the XML as an object
; - both: pass the XML as a string and object
; Defaults to object
;export_xml_as=object
; print_msg: boolean/string: Print sent/received messages to output if debug
; level is at least 9
; Allowed values are boolean values or 'verbose' string
; If verbose is specified, the message will be dumped on output
; Defaults to no
;print_msg=no
; print_xml: boolean/string: Print sent/received XML data to output if debug
; level is at least 9
; This parameter is ignored if print_msg is disabled
; Allowed values are boolean values or 'verbose' string
; If verbose is specified, XML elements' children, attributes or text will be
; shown on separate lines
; Defaults to no
;print_xml=no
; idp_calling_required: boolean: Calling party number is required (non empty) in initialDP
; Default to yes
;idp_calling_required=yes
; idp_called_required: boolean: Called party number is required (non empty) in initialDP
; Default to yes
;idp_called_required=yes
; dispatcher_maxthreads: integer: Maximum number of message dispatch threads to use
; Set to 0 to enqueue messages using yate engine
; Defaults to 0
; When reloaded it can't be set to 0 (e.g. once set to a non 0 value it can be changed to
; non 0 values only)
;dispatcher_maxthreads=0
;dispatcher_priority: string: Default priority of message dispatch threads
; Can be one of: lowest, low, normal, high, highest
; High priorities need superuser privileges on POSIX operating systems
; Low priorities are not recommended except for debugging
; Defaults to 'normal'
; This parameter is applied on reload for new threads only
;dispatcher_priority=normal
;[proxy appname]
; This section configures a proxied SCF
; 'appname' is the application name to be used for the SCF
; enable: boolean: Enable the SCF
; Defaults to yes
;enable=yes
; priority: integer: Priority in handling messages from SSF
; Defaults to 0
;priority=0
; servicekey: integer: Value with which the IDP serviceKey should be rewritten
; Allowed interval: 0..2147483647
; Defaults to SSF service key set in 'general' section
;servicekey=
; dp: string: Comma separated list of detection points that should match the one received in IDP
; in order to contact this SCF
; Items may be DP value or name
; Defaults to termAttemptAuthorized if empty or all DPs are invalid
;dp=termAttemptAuthorized
; endfatal: boolean: Indicate whether or not terminate the proxy dialog when this dialog ends
; Defaults to no
;endfatal=no
; errorfatal: boolean: Indicate whether or not an error or reject component from
; the SCF should terminate the whole proxy dialog
; Defaults to no
;errorfatal=no
; local: boolean: The SCF is local (a local application) or external (it passes
; through the SS7 network to reach it)
; Defaults to no (external application)
;local=no
; instances: integer: Number of local application instances
; If non 0 the module will build the required number of SCFs and will pick them using a
; round-robin algorithm
; Each application's name will be built from SCF application name concatenated with instance
; suffix startting from 1
; E.g.
; [proxy SCP]
; instances=2
; Will build 2 applications: SCP1 and SCP2
; This parameter is ignored for non local SCFs
; If non 0 it must be set to a value greater then 1
; Defaults to 0
;instance=
; handles: string: Comma separated list of operations received from the SSF
; accepted by this SCF
; NOTE: Except ERB (Event Report BCSM), which is sent to all SCFs that match the reported DP,
; all operations that are handled by a SCF should be listed, otherwise the
; proxy will report to the SSF an error
;handles=
; waittime: integer: Time, in miliseconds, to wait for a result from a SCF
; while being in Waiting For Instructions state, after which the dialog
; is aborted
; Defaults to 3000
; Minimum allowed value is 1000
;waittime=3000
; All other parameters starting with 'addr.' prefix will be put in dialog begin
; message sent for this SCF
; E.g. addr.CalledPartyAddress.route=gt will be put as CalledPartyAddress.route=gt
[edit] Proxy Module Test
This chapter describes how the Camel Proxy module was tested.
The purpose of the test was to check if the Camel BCSM Proxy module can handle 100CPS.
The machine used was a Dual Intel Xeon E5620 (Quad Core with HT) = 16CPUs, 32GB RAM with CentOS 6.2
The setup was:
Yate1 - Call generator, sending calls to Yate3 using SIP
Yate2 - Call generator, sending calls to Yate4 using SIP
Yate3 - Call handling, send initialDP to Yate5 (Proxy)
Yate4 - Call handling, send initialDP to Yate5 (Proxy)
Yate5 - Camel BCSM Proxy
Yate6 - CRBT script
Yate7 - PPS script
Yate8 - PPS script
SIP M2PA link M2PA links
Yate1 ---------> Yate3 ------------| |-----------> Yate6 (CRBT)
| |
|-> Yate5 |-----------> Yate7 (PPS)
| |
SIP M2PA link | |-----------> Yate8 (PPS)
Yate2 ---------> Yate4 ------------|
NOTES:
- The sum of both call generators was 110CPS.
- During test top reported ~250%CPU for Proxy.
- All yate instances were running on the same machine.
- The reason of using 2 PPS instances was the performance of PPS script: 1 script is not able to respond quick enough. The PPS SCFs were rotated using 'scf.query' message.
How success was checked:
- On call generators all calls were answered
- On call handling instances (Yate3 and 4) there were no Tssf timeouts (this would indicate a timeout while waiting for instrunctions from SCP - after sending initialDP or eventReportBCSM with type='request')
- On Proxy instance (Yate5) there were no timeouts (this would indicate a SCF is not responding withing default 3 seconds interval)
[edit] Configuration
[edit] Script side
Configuration of the "camel_proxy.php" script is done through config_proxy.php. This allows setting the following parameters:
- 1 $myServiceKey - integer. The ID of the service provided by this gsmSCF application and which should come in IDP in order to accept the request.
- 2. $proxyName - string. It represent the value of the application parameter set in the camel.message coming from and going to the SSF. This value is used to check that the message is indeed intented for this script.
- 3. $mynum - string. GTT number assigned to this SCP.
- 4. $transTimeout - integer. It sets the time for which the PHP TCAP library will keep alive a TCAP dialogue after remaining with no active components. A new TCAP message will reset the associated timer. If the timer runs out, the library will generate a TCAP End in order to terminate the dialog. For this application, this timer is set by default to 180 seconds.
- 5. $scfs - array. This defines the list of configured proxied SCFs. Each entry in the array defines a SCF with its configuration parameters. The key set for the entry designates the name of the SCF and the value used for the aplication parameter set in the camel.message used to communicate between the proxy and the SCF. For each entry, the following parameters must be set:
- 5.1. serviceKey - integer. It represents the service key to be used when constructing an IDP for this SCF..
- 5.2. dp - string. It represent the detection point at which this SCF should be contacted. In order for the proxy to build an IDP for this SCF, the detection point received in the IDP from the SSF should match the one configured here.
- 5.3. priority - integer. It specifies the priority of this SCF when handling messages from SSF. According to priority,messages from the SSF will be passed by the proxy in priority order to the SCFs, first to the highest priority SCF (meaning the one with the lowest set value).
- 5.4. errorFatal - boolean. It specifies whether or not an error or reject component from this SCF should terminate the dialogue with the SSF and also with the other SCFs.
- 5.5. addr - array. It specifies SS7 network addressing parameters. They only need be set for external SCFs. Parameters are usually set here are:
- CalledPartyAddress.route - string. It can be set to values: gt/ssn. It specifies how the SCCP address should be routed.
- CalledPartyAddress.ssn - integer. It's the SSN number in case of SSN routing.
- CalledPartyAddress.gt - string. GTT number digits for the SCF.
- CalledPartyAddress.gt.encoding - string. It specifies the encoding for the GT digits. It is usually set to bcd.
- CalledPartyAddress.gt.translation - integer. It specifies the GT translation type. It is usually set to 0.
- CalledPartyAddress.gt.plan - string. The GT numbering plan. It is usually set to isdn. It can be one of the following values: unknown, isdn, e164, generic, data, x121, telex, maritime-mobile, e210, e211, land-mobile, e212, isdn-mobile, e214, network-specific.
- CalledPartyAddress.gt.nature- string. It specifies the nature of the GT number. It is usually set to international.It can have one the following values: unknown, subscriber, national-reserved, national-significant, international.
- CallingPartyAddress.route
- CalledPartyAddress.ssn
- CallingPartyAddress.gt
- CallingPartyAddress.gt.encoding
- CallingPartyAddress.gt.translation
- CallingPartyAddress.gt.plan
- CallingPartyAddress.gt.nature
- 5.6. local - boolean. It specifies whether the SCF application is found locally, inside the same Yate instance. If not, communication with the SCF means messages on the SS7 network.
- 5.7. handles - array. It specifies a list of operations that are handled by this SCF. Besides IDP and ERBE which are sent to all SCFs that match the sending criteria, other operation must be listed here in order for that SCF to receive it.
- 5.8. context - integer. The application context to be used in the dialogue with this SCF. If not set, the one received in the IDP from the SSF will be used.
- 5.9. waitTime - integer. It set the time, in seconds, for the proxy to wait for a result from this SCF while being in Waiting For Instructions state, after which the dialogue with that SCF is aborted, and proxy continues processing. Setting it to 0 means that the proxy will wait indefinetely.
A working configuration for camel_proxy.php looks like this:
$myServiceKey = "1";
$proxyName = "camelProxy";
/**
* GTT number of this SCP
*/
$mynum = "8820003";
/**
* Transaction timeout after inactivity
*/
$transTimeout = 180;
/**
* List of configured proxied SCFs
* The following parameters must be configured, all are mandatory:
* serviceKey - value with which the IDP serviceKey should be rewritten
* dp - detection point that should match the one received in IDP in order to contact this SCF
* priority - priority in handling messages from SSF
* errorFatal - whether or not an error or reject component from the SCF should terminate the whole proxy dialoque
* addr - SS7 network addressing parameters.
* local - whether the SCF is local (a local application) or external (it passes through the SS7 network to reach it)
* handles - lists operation received from the SSF that are accepted by this SCF.
* NOTE: Except ERBE, which is sent to all SCFs that match the reported DP, all operations that are handled by a
* SCF should be listed, otherwise the proxy will report to the SSF an error.
* context - if set, rewrites the application context for the dialog established with the SCF, otherwise leaves it as received
* waitTime - time, in seconds, to wait for a result from a SCF while being in Waiting For Instructions state, after which the dialogue
* is aborted.
*/
$scfs = array(
"crbt-scp" => array(
"serviceKey" => 2,
"dp" => "termAttemptAuthorized",
"priority" => 1,
"errorFatal" => false,
"addr" => array(),
"local" => true,
"handles" => array(),
"context" => "",
"waitTime" => 3,
),
"pps-scp" => array(
"serviceKey" => 99,
"dp" => "termAttemptAuthorized",
"priority" => 2,
"errorFatal" => true,
"addr" => array("CalledPartyAddress.gt" => "8820007",
"CalledPartyAddress.route" => "gt",
"CalledPartyAddress.gt.encoding" => "bcd",
"CalledPartyAddress.gt.tt" => "0",
"CalledPartyAddress.gt.np" => "isdn",
"CalledPartyAddress.gt.nature" => "international",
"CallingPartyAddress.gt" => "8820003",
"CallingPartyAddress.route" => "gt",
"CallingPartyAddress.gt.encoding" => "bcd",
"CallingPartyAddress.gt.tt" => "0",
"CallingPartyAddress.gt.np" => "isdn",
"CallingPartyAddress.gt.nature" => "international",
),
"local" => false,
"handles" => array("applyChargingReport"),
"context" => "",
"waitTime" => 3,
),
);
[edit] Yate side
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:
[local proxyName] - what comes after local will be the name of the application ;enable=no -- enable this application translator=scp - which translator should be used. A section named [tcap translatorValue] should be present in the config file. capabilities=Camel - capabilities supported by this application. CAMEL translator has only one capability and that is Camel. 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:
[tcap scp] -- what comes after tcap will be the name of the translator ;enable=no -- enable this translator tcap=tcap-scp -- TCAP to be used by the translator for SS7 network communication, a section with that name should be configured in ysigchan.conf host=0.0.0.0 -- address on which to listen for incoming applications port=0 -- port on which to listen for incoming applications. 0 means that will not build a listener, as the proxy works on messages. type=CAMEL -- type of translator (MAP/CAMEL). For the intended case, CAMEL should be set print-messages=true -- whether or not to print TCAP and XML messages in the logs add-encoding=false -- whether to add encoding attribute to data translated to XML
For an external proxied SCF, additional [local scfName] and [tcap name] sections must be configured:
[tcap msc] tcap=tcap-msc host=0.0.0.0 port=0 type=CAMEL print-messages=true add-encoding=false [local ext-scp] ;enable=no translator=msc capabilities=Camel export_xml_as=both
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.
[edit] Proxy Behaviour
Bellow, the behaviour of the CAMEL proxy implemented in camel_proxy.php is described.
[edit] 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 [page] for how to do this.
[edit] 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.
[edit] 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.
[edit] 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?
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.
[edit] 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.
