ss7api.null.ro - User contributions [en]

https://ss7api.null.ro/api.php?action=feedcontributions&feedformat=atom&user=Monica ss7api.null.ro - User contributions [en] 2026-04-27T17:48:30Z User contributions MediaWiki 1.20.2 https://ss7api.null.ro/index.php/RegisterSS RegisterSS 2019-10-03T14:36:04Z

<p>Monica: </p> <hr /> <div>{{DISPLAYTITLE:registerSS}}<br /> ==Usage==<br /> <br /> This message is sent to a HLR to register a Supplementary Service for a Mobile Station<br /> <br /> ==Addressing==<br /> <br /> The TCAP dialog userInformation is used for identifying the subscriber. The destinationReference parameter will normally hold the IMSI as a land-mobile international number.<br /> <br /> ==Invoke parameters==<br /> <br /> * '''ss-Code''' – code of the Supplementary Service<br /> * ''basicService'' – Affected bearer or teleservice, one of:<br /> ** bearer – Affected bearer<br /> ** service – Affected service<br /> * ''forwardedToNumber'' – Number to which the service will be diverted<br /> * ''forwardedToSubaddress'' – Subaddress to which the service will be diverted<br /> * ''noReplyConditionTime'' – How long until a "no answer" condition is declared, 5 to 30<br /> * ''defaultPriority'' – Priority of the service, 0 to 15<br /> * ''nbrUser'' - is sent to register the MC maximum number of user defined circuit switched bearers to be used.<br /> * ''longFTN-Supported'' - indicates that the mobile station supports Long Forwarded-to Numbers.<br /> <br /> ==Result parameters==<br /> The set of parameters in the result depends on the invoke parameters, can be one of:<br /> *forwardingInfo – information about call forwarding<br /> **''ss-Code'' – code of the Supplementary Service<br /> **'''forwardingFeatureList''' – list of forwarding features:<br /> ***forwardingFeature – represents the information about each combination of a basic service and call forwarding service. It is a list of the following parameters:<br /> ****basicService – bearer or teleservice<br /> ****ss-Status<br /> ****forwardedToNumber<br /> ****forwardedToSubaddress<br /> ****forwardingOptions<br /> ****noReplyConditionTime<br /> ****extensionContainer<br /> ****longForwardedToNumber <br /> *callBarringInfo – information about a call barring service:<br /> **''ss-Code'' – code for supplementary service<br /> **'''callBarringFeatureList''' – list of call barring features parameters:<br /> ***ext-CallBarFeature – this gives the status of call barring services as they are applicable to the basic service:<br /> ****''basicService'' – the bearer or teleservice<br /> ****'''ss-Status''' – state information of individual supplementary services, see [[interrogateSS]] description.<br /> ****''extensionContainer''<br /> **''extensionContainer''<br /> *cug-Info – refers to the information required for the operation of each CUG (Closed User Group):<br /> **'''cug-SubscriptionList''' – list of CUG subscriptions:<br /> ***cug-Subscription – set of information for each CUG defined in the subscription. Contains the following parameters:<br /> ****'''cug-Index''' – CUG index defined in ETS 300 138.<br /> ****'''cug-Interlock''' – CUG interlock code defined in ETS 300 138.<br /> ****'''intraCUG-Options''' – describes whether or not the subscriber is allowed to originate/to receive calls to/from withing the CUG. It has one of the following values:<br /> *****noCUG-Restrictions – no restrictions<br /> *****cugIC-CallBarred – incoming CUG calls are barred<br /> *****cugOG-CallBarred – outgoing CUG calls are barred<br /> ****''basicServiceGroupList'' – list of basic services<br /> *****basicService<br /> ****''extensionContainer''<br /> **''cug-FeatureList'' – sequence of CUG features:<br /> ***cug-Feature – specifies parameters that are to be associated with the Basic Service Group. If the Basic Service is missing, the feature applies to all Basic Services.<br /> ****''basicService'' – the basic Service to which the feature applies<br /> ****'''preferentialCUG-Indicator''' – indicates which CUG indes is to be used at an outgoing call setup using the Basic Service Group<br /> ****'''interCUG-Restrictions''' – indicates whether if for the specified Basic Service Group outgoing and incoming call are allowed. It can have one of the following values:<br /> *****CUG-only – calls only within the CUG are allowed<br /> *****CUG-outgoing-access – calls outside the CUG are allowed<br /> *****CUG-incoming-access – calls coming from outside the CUG are allowed<br /> *****CUG-both – both incoming and outgoing calls are allowed<br /> ****''extensionContainer''<br /> **''extensionContainer''<br /> *ss-Data – Supplementary Service data<br /> **'''ss-Code''' – code of the Supplementary Service<br /> **'''ss-Status''' – state information of individual Supplementary Services, see [[interrogateSS]] description.<br /> **''ss-SubscriptionOption'' – specifies an option attached to the supplementary service. It is a choice between:<br /> ***cliRestrictionOption – refers to the Restriction mode attached to the supplementary service. It can have one of the following values:<br /> ****permanent<br /> ****temporaryDefaultRestricted<br /> ****temporaryDefaultAllowed<br /> ***overrideCategory - specifies the Override Category option attached to the supplementary service. It can have one of the following values:<br /> ****overrideEnabled<br /> ****overrideDisabled<br /> **''basicServiceGroupList'' – list of:<br /> ***basicService – bearer or teleservice<br /> **''extensionContainer''<br /> *emlpp-Info – specifies data associated with the eMLPP service. It has the following parameters:<br /> **'''maximumentitledPriority''' – indicates the highest priority a subscriber is allowed to apply to an outgoing call setup.<br /> **'''defaultPriority''' – defines the priority level that should be assigned if no explicit priority is indicated during call setup.<br /> **''extensionContainer''<br /> <br /> ==Example==<br /> <component remoteCID="1" type="Invoke" operationCode="registerSS"><br /> <ss-Code>plmn-specificSS-D</ss-Code><br /> </component><br /> <br /> ==References==<br /> * ETSI TS 100 974 V7.15.0 (2004-03) p1076</div>

Monica https://ss7api.null.ro/index.php/DeactivateSS DeactivateSS 2019-10-03T14:35:29Z

<p>Monica: </p> <hr /> <div>{{DISPLAYTITLE:deactivateSS}}<br /> ==Usage==<br /> <br /> This message is sent to a HLR to deactivate a Supplementary Service from a MSC via a VLR.<br /> <br /> ==Addressing==<br /> ...<br /> <br /> ==Invoke parameters==<br /> <br /> * '''ss-Code''' – the code of the supplementary service to be deactivated.<br /> * ''basicService'' – indicates for which basic service group the supplementary service should be deactivated. If not included, the deactivation request applies to all basic services. It's a choice between:<br /> ** bearerService – affected bearer<br /> ** teleservice – affected service<br /> * ''longFTN-Supported'' - indicates that the mobile station supports Long Forwarded-to Numbers.<br /> <br /> ==Result parameters==<br /> <br /> The set of parameters in the result depends on the invoke parameters, can be one of:<br /> <br /> * forwardingInfo – information about call forwarding<br /> ** ''ss-Code'' – code of the Supplementary Service<br /> ** forwardingFeatureList – list of forwarding features:<br /> *** forwardingFeature – represents the information about each combination of a basic service and call forwarding service. It is a list of the following parameters:<br /> **** ''basicService'' – bearer or teleservice<br /> **** ''ss-Status''<br /> **** ''forwardedToNumber''<br /> **** ''forwardedToSubaddress''<br /> **** ''forwardingOptions''<br /> **** ''noReplyConditionTime''<br /> **** ''extensionContainer''<br /> **** ''longForwardedToNumber''<br /> * callBarringInfo – information about a call barring service:<br /> ** ss-Code – code for supplementary service<br /> ** callBarringFeatureList – list of call barring features parameters:<br /> *** ext-CallBarFeature – this gives the status of call barring services as they are applicable to the basic service:<br /> **** ''basicService'' – the bearer or teleservice<br /> **** ss-Status – state information of individual supplementary services, see [[interrogateSS]] description.<br /> **** extensionContainer <br /> ** extensionContainer <br /> * cug-Info – refers to the information required for the operation of each CUG (Closed User Group):<br /> ** cug-SubscriptionList – list of CUG subscriptions:<br /> *** cug-Subscription – set of information for each CUG defined in the subscription. Contains the following parameters:<br /> **** cug-Index – CUG index defined in ETS 300 138.<br /> **** cug-Interlock – CUG interlock code defined in ETS 300 138.<br /> **** intraCUG-Options – describes whether or not the subscriber is allowed to originate/to receive calls to/from within the CUG. It has one of the following values:<br /> ***** noCUG-Restrictions – no restrictions<br /> ***** cugIC-CallBarred – incoming CUG calls are barred<br /> ***** cugOG-CallBarred – outgoing CUG calls are barred<br /> **** basicServiceGroupList – list of basic services<br /> ***** basicService<br /> **** extensionContainer<br /> ** cug-FeatureList – sequence of CUG features:<br /> *** cug-Feature – specifies parameters that are to be associated with the Basic Service Group. If the Basic Service is missing, the feature applies to all Basic Services.<br /> **** ''basicService'' – the basic Service to which the feature applies<br /> **** preferentialCUG-Indicator – indicates which CUG indes is to be used at an outgoing call setup using the Basic Service Group<br /> **** interCUG-Restrictions – indicates whether if for the specified Basic Service Group outgoing and incoming call are allowed. It can have one of the following values:<br /> ***** CUG-only – calls only within the CUG are allowed<br /> ***** CUG-outgoing-access – calls outside the CUG are allowed<br /> ***** CUG-incoming-access – calls coming from outside the CUG are allowed<br /> ***** CUG-both – both incoming and outgoing calls are allowed<br /> **** extensionContainer <br /> ** extensionContainer<br /> * ss-Data – Supplementary Service data<br /> ** ss-Code – code of the Supplementary Service<br /> ** ss-Status – state information of individual Supplementary Services, see [[interrogateSS]] description.<br /> ** ''ss-SubscriptionOption'' – specifies an option attached to the supplementary service. It is a choice between:<br /> *** cliRestrictionOption – refers to the Restriction mode attached to the supplementary service. It can have one of the following values:<br /> **** permanent<br /> **** temporaryDefaultRestricted<br /> **** temporaryDefaultAllowed<br /> *** overrideCategory - specifies the Override Category option attached to the supplementary service. It can have one of the following values:<br /> **** overrideEnabled<br /> **** overrideDisabled<br /> ** ''basicServiceGroupList'' – list of:<br /> *** basicService – bearer or teleservice<br /> ** ''extensionContainer'' <br /> * emlpp-Info – specifies data associated with the eMLPP service. It has the following parameters:<br /> ** maximumentitledPriority – indicates the highest priority a subscriber is allowed to apply to an outgoing call setup.<br /> ** defaultPriority – defines the priority level that should be assigned if no explicit priority is indicated during call setup.<br /> ** extensionContainer<br /> <br /> ==Example==<br /> <br /> <component localCID="1" type="Invoke" operationCode="deactivateSS"><br /> <ss-Code>allCallOfferingSS</ss-Code><br /> <basicService><br /> <teleservice>automaticFacsimileGroup3</teleservice><br /> </basicService><br /> </component><br /> <br /> ==References==<br /> <br /> * ETSI TS 100 974 V7.15.0 (2004-03) p1078</div>

Monica https://ss7api.null.ro/index.php/ActivateSS ActivateSS 2019-10-03T14:35:03Z

<p>Monica: </p> <hr /> <div>{{DISPLAYTITLE:activateSS}}<br /> ==Usage==<br /> <br /> This message is sent to a HLR to activate a supplementary service from a MSC via a VLR.<br /> <br /> ==Addressing==<br /> <br /> ...<br /> <br /> ==Invoke parameters==<br /> <br /> * '''ss-Code''' – the code of the supplementary service to be activated<br /> <br /> * '''basicService''' – indicates for which basic service group the supplemtary service should be activated. If not included, the activation request applies to all basic services. It's a choice between:<br /> ** bearerService – affected bearer<br /> ** teleservice – affected service<br /> <br /> * ''longFTN-Supported'' - indicates that the mobile station supports Long Forwarded-to Numbers.<br /> <br /> <br /> ==Result parameters==<br /> <br /> The set of parameters in the result depends on the invoke parameters, can be one of:<br /> <br /> * forwardingInfo – information about call forwarding<br /> ** ''ss-Code'' – code of the Supplementary Service<br /> ** forwardingFeatureList – list of forwarding features:<br /> *** forwardingFeature – represents the information about each combination of a basic service and call forwarding service. It is a list of the following parameters:<br /> **** ''basicService'' – bearer or teleservice<br /> **** ''ss-Status''<br /> **** ''forwardedToNumber''<br /> **** ''forwardedToSubaddress''<br /> **** ''forwardingOptions''<br /> **** ''noReplyConditionTime''<br /> **** ''extensionContainer''<br /> **** ''longForwardedToNumber''<br /> * callBarringInfo – information about a call barring service:<br /> ** ss-Code – code for supplementary service<br /> ** callBarringFeatureList – list of call barring features parameters:<br /> *** ext-CallBarFeature – this gives the status of call barring services as they are applicable to the basic service:<br /> **** ''basicService'' – the bearer or teleservice<br /> **** ss-Status – state information of individual supplementary services, see [[interrogateSS]] description.<br /> **** ''extensionContainer''<br /> ** extensionContainer <br /> * cug-Info – refers to the information required for the operation of each CUG (Closed User Group):<br /> ** cug-SubscriptionList – list of CUG subscriptions:<br /> *** cug-Subscription – set of information for each CUG defined in the subscription. Contains the following parameters:<br /> **** cug-Index – CUG index defined in ETS 300 138.<br /> **** cug-Interlock – CUG interlock code defined in ETS 300 138.<br /> **** intraCUG-Options – describes whether or not the subscriber is allowed to originate/to receive calls to/from within the CUG. It has one of the following values:<br /> ***** noCUG-Restrictions – no restrictions<br /> ***** cugIC-CallBarred – incoming CUG calls are barred<br /> ***** cugOG-CallBarred – outgoing CUG calls are barred<br /> **** basicServiceGroupList – list of basic services<br /> ***** basicService<br /> **** extensionContainer<br /> ** cug-FeatureList – sequence of CUG features:<br /> *** cug-Feature – specifies parameters that are to be associated with the Basic Service Group. If the Basic Service is missing, the feature applies to all Basic Services.<br /> **** ''basicService'' – the basic Service to which the feature applies<br /> **** preferentialCUG-Indicator – indicates which CUG indes is to be used at an outgoing call setup using the Basic Service Group<br /> **** interCUG-Restrictions – indicates whether if for the specified Basic Service Group outgoing and incoming call are allowed. It can have one of the following values:<br /> ***** CUG-only – calls only within the CUG are allowed<br /> ***** CUG-outgoing-access – calls outside the CUG are allowed<br /> ***** CUG-incoming-access – calls coming from outside the CUG are allowed<br /> ***** CUG-both – both incoming and outgoing calls are allowed<br /> **** ''extensionContainer''<br /> ** extensionContainer<br /> * ss-Data – Supplementary Service data<br /> ** ss-Code – code of the Supplementary Service<br /> ** ss-Status – state information of individual Supplementary Services, see [[interrogateSS]] description.<br /> ** ''ss-SubscriptionOption'' – specifies an option attached to the supplementary service. It is a choice between:<br /> *** cliRestrictionOption – refers to the Restriction mode attached to the supplementary service. It can have one of the following values:<br /> **** permanent<br /> **** temporaryDefaultRestricted<br /> **** temporaryDefaultAllowed<br /> *** overrideCategory - specifies the Override Category option attached to the supplementary service. It can have one of the following values:<br /> **** overrideEnabled<br /> **** overrideDisabled<br /> ** ''basicServiceGroupList'' – list of:<br /> *** basicService – bearer or teleservice<br /> ** extensionContainer <br /> * emlpp-Info – specifies data associated with the eMLPP service. It has the following parameters:<br /> ** maximumentitledPriority – indicates the highest priority a subscriber is allowed to apply to an outgoing call setup.<br /> ** defaultPriority – defines the priority level that should be assigned if no explicit priority is indicated during call setup.<br /> ** ''extensionContainer''<br /> <br /> ==Example==<br /> <br /> <component localCID="1" type="Invoke" operationCode="activateSS"><br /> <ss-Code>allCallOfferingSS</ss-Code><br /> <basicService><br /> <teleservice>automaticFacsimileGroup3</teleservice><br /> </basicService><br /> </component><br /> <br /> <br /> ==References==<br /> <br /> * ETSI TS 100 974 V7.15.0 (2004-03) p1077</div>

Monica https://ss7api.null.ro/index.php/EraseSS EraseSS 2019-10-03T14:34:19Z

<p>Monica: </p> <hr /> <div>{{DISPLAYTITLE:eraseSS}}<br /> ==Usage==<br /> This message is sent to a HLR to erase data related to a Supplementary Service from a MSC via a VLR.<br /> ==Addressing==<br /> ...<br /> ==Invoke parameters==<br /> <br /> * '''ss-Code''' – the code of the supplementary service to be erased<br /> <br /> * ''basicService'' – indicates for which basic service group the supplemtary service should be erased. If not included, the erasure request applies to all basic services. It's a choice between:<br /> ** bearerService – affected bearer<br /> ** teleservice – affected service<br /> <br /> * ''longFTN-Supported'' - indicates that the mobile station supports Long Forwarded-to Numbers.<br /> <br /> ==Result parameters==<br /> <br /> The set of parameters in the result depends on the invoke parameters, can be one of:<br /> <br /> * forwardingInfo – information about call forwarding<br /> ** ''ss-Code'' – code of the Supplementary Service<br /> ** forwardingFeatureList – list of forwarding features:<br /> *** forwardingFeature – represents the information about each combination of a basic service and call forwarding service. It is a list of the following parameters:<br /> **** ''basicService'' – bearer or teleservice<br /> **** ''ss-Status''<br /> **** ''forwardedToNumber''<br /> **** ''forwardedToSubaddress''<br /> **** ''forwardingOptions''<br /> **** ''noReplyConditionTime''<br /> **** ''extensionContainer''<br /> **** ''longForwardedToNumber''<br /> * callBarringInfo – information about a call barring service:<br /> ** ss-Code – code for supplementary service<br /> ** callBarringFeatureList – list of call barring features parameters:<br /> *** ext-CallBarFeature – this gives the status of call barring services as they are applicable to the basic service:<br /> **** ''basicService'' – the bearer or teleservice<br /> **** ''ss-Status'' – state information of individual supplementary services, see [[interrogateSS]] description.<br /> **** ''extensionContainer'' <br /> ** ''extensionContainer ''<br /> <br /> * cug-Info – refers to the information required for the operation of each CUG (Closed User Group):<br /> ** cug-SubscriptionList – list of CUG subscriptions:<br /> *** cug-Subscription – set of information for each CUG defined in the subscription. Contains the following parameters:<br /> **** cug-Index – CUG index defined in ETS 300 138.<br /> **** cug-Interlock – CUG interlock code defined in ETS 300 138.<br /> **** intraCUG-Options – describes whether or not the subscriber is allowed to originate/to receive calls to/from withing the CUG. It has one of the following values:<br /> ***** noCUG-Restrictions – no restrictions<br /> ***** cugIC-CallBarred – incoming CUG calls are barred<br /> ***** cugOG-CallBarred – outgoing CUG calls are barred<br /> **** basicServiceGroupList – list of basic services<br /> ***** basicService<br /> **** extensionContainer<br /> ** cug-FeatureList – sequence of CUG features:<br /> *** cug-Feature – specifies parameters that are to be associated with the Basic Service Group. If the Basic Service is missing, the feature applies to all Basic Services.<br /> **** ''basicService'' – the basic Service to which the feature applies<br /> **** preferentialCUG-Indicator – indicates which CUG indes is to be used at an outgoing call setup using the Basic Service Group<br /> **** interCUG-Restrictions – indicates whether if for the specified Basic Service Group outgoing and incoming call are allowed. It can have one of the following values:<br /> ***** CUG-only – calls only within the CUG are allowed<br /> ***** CUG-outgoing-access – calls outside the CUG are allowed<br /> ***** CUG-incoming-access – calls coming from outside the CUG are allowed<br /> ***** CUG-both – both incoming and outgoing calls are allowed<br /> **** extensionContainer <br /> ** extensionContainer<br /> <br /> * ss-Data – Supplementary Service data<br /> ** ss-Code – code of the Supplementary Service<br /> ** ss-Status – state information of individual Supplementary Services, see [[InterrogateSS]] description.<br /> ** ''ss-SubscriptionOption'' – specifies an option attached to the supplementary service. It is a choice between:<br /> *** cliRestrictionOption – refers to the Restriction mode attached to the supplementary service. It can have one of the following values:<br /> *** permanent<br /> **** temporaryDefaultRestricted<br /> **** temporaryDefaultAllowed<br /> *** overrideCategory - specifies the Override Category option attached to the supplementary service. It can have one of the following values:<br /> **** overrideEnabled<br /> **** overrideDisabled<br /> ** ''basicServiceGroupList'' – list of:<br /> *** basicService – bearer or teleservice<br /> ** ''extensionContainer'' <br /> <br /> * emlpp-Info – specifies data associated with the eMLPP service. It has the following parameters:<br /> ** maximumentitledPriority – indicates the highest priority a subscriber is allowed to apply to an outgoing call setup.<br /> ** defaultPriority – defines the priority level that should be assigned if no explicit priority is indicated during call setup.<br /> ** ''extensionContainer''<br /> <br /> ==Example==<br /> <br /> <component remoteCID="1" type="Invoke" operationCode="eraseSS"><br /> <ss-Code>plmn-specificSS-A</ss-Code><br /> <basicService><br /> <bearerService>general-dataPDS</bearerService><br /> </basicService><br /> </component><br /> <br /> ==References==<br /> <br /> * ETSI TS 100 974 V7.15.0 (2004-03) p1076</div>

Monica https://ss7api.null.ro/index.php/Main_Page Main Page 2013-12-16T12:32:56Z

<p>Monica: </p> <hr /> <div><br /> ==YATE's TCAP XML Interface==<br /> <br /> <br /> <br /> The purpose of this document is to describe the XML based protocol used to implement communication between TCAP and the application servers for mobile services.<br /> <br /> <br /> MAP (Mobile Application Part) and CAMEL (Customized Application of Mobile Enhanced Logic) are SS7 protocols used for authentication, registration, messaging, call control and billing in mobile networks. Both protocols are based on TCAP (Transaction Capabilities Application Part) which is a transaction oriented protocol.<br /> <br /> <br /> This protocol aims to map the structure of MAP and CAMEL messages and messageless TCAP primitives on XML messages as transparently as possible. However, some concepts of the TCAP layer will reflect in the message flow and in some of the parameters.<br /> <br /> <br /> Each communication between two network elements happens inside a dialog created by the first message. Multiple components can exist inside the dialog, each with its own direction and timing. The dialog is ended normally when the last component finished exchanging data. The correlation of simultaneously happening dialogs and components is done using unique identifiers. Dialogs hold a local ID and a remote ID. Each such ID must be unique per communication endpoint.<br /> <br /> <br /> Components also hold an ID inside the dialog. Each such ID must be unique per component and direction. It is important to note that same numeric ID may be used for components invoked from the opposing sides of the connection.<br /> <br /> <br /> The following picture shows a transaction with two components: <br /> <br /> [[File:tcap_transaction.png]]</div>

Monica https://ss7api.null.ro/index.php/MSC_simulator MSC simulator 2013-10-28T11:57:10Z

<p>Monica: /* call.execute handling */</p> <hr /> <div>This module simulates the call related features of a CAMEL capable MSC.<br /> <br /> In particular the module implements the Basic Call Machine State described by the CAMEL standards.<br /> <br /> The module does not store the CAMEL subscription, instead it expects any subscription information to be provided in the inbound call routing parameters.<br /> <br /> ==BCSM Module Configuration==<br /> The configuration file is '''camel_bcsm.conf'''.<br /> Sections:<br /> ===[general]===<br /> Unless explicitly specified, all parameters in this section are applied on reload for new calls only.<br/><br /> Parameters:<br /> <br /> * '''application''': string: Application parameter in camel messages sent by the module<br/><br /> This parameter is required<br/><br /> This parameter can be overridden from routing for each call<br/><br /> <br /> * '''camel_phase''': integer: CAMEL phase to use<br /> Allowed values: 1, 2, 3, 4<br/><br /> Defaults to 4<br/><br /> This parameter can be overridden from routing for each call<br/><br /> <br /> * '''servicekey''': integer: CAMEL serviceKey parameter to be set in initialDP messages<br /> Allowed interval: 0..2147483647<br/><br /> Defaults to 0<br/><br /> This parameters can be overridden from routing for each statically armed DP (see [[#call.execute handling|call.execute handling]])<br/><br /> <br /> * '''msc_address''': string: The mscAddress parameter to be set when sending initialDP<br /> * '''msc_address_plan''': string: MSC address numbering plan. Values: unknown, isdn, data, telex, land-mobile, isdn-mobile, national, private, extension-reserved<br /> * '''msc_address_nature''': string: MSC address number nature. Values: unknown, international, national, network-specific, subscriber, reserved, abbreviated, extension-reserved<br /> This parameters can be overridden from routing for each statically armed DP (see [[#call.execute handling|call.execute handlin]])<br /> <br /> * '''default_call_handling_continue''': boolean: Continue operation when an error occurs<br /> Defaults to enable<br/><br /> This parameters can be overridden from routing for each statically armed DP (see [[#call.execute handling|call.execute handlin]])<br/><br /> <br /> * '''tssf_timer''': integer: Application timer (milliseconds) for non user interaction<br/><br /> This interval is used when call processing is suspended and no user interaction is expected, e.g. an event was notified to SCP and we are waiting for instructions<br/><br /> Interval allowed: 1000..20000 (1..20s)<br/><br /> Defaults to 3000 (3 seconds)<br/><br /> <br /> * '''tssf_timer_user''': integer: Application timer (milliseconds) for user interaction<br/><br /> This interval id used when call processing is suspended and user interaction is expected, e.g. a disconnectForwardConnection (disconnect a temporary leg) was received from SCP<br/><br /> Interval allowed: 60000..1800000 (1..30min)<br/><br /> Defaults to 180000 (3 minutes)<br/><br /> <br /> * '''report_etc_failed_timer''': integer: The interval in milliseconds to report failure for temporary calls started on Establish Temporary Connection requests<br /> Failure will be reported if the SRF terminates the call within this interval<br/><br /> If no failure is reported the controlling SCF (which has its own timer) will treat the request as succeeded<br/><br /> This parameter can be overridden from routing<br/><br /> Minimum allowed value is 1000<br/><br /> Defaults to 3000.<br/><br /> <br /> * '''dp_busy_reason''': regexp: Regexp to match termination reason when a called party terminates the call and we have the 'busy' DP armed<br/><br /> If the reason matches dp_busy_reason the 'busy' DP will be notified to SCP<br/><br /> Defaults to ^busy$<br/><br /> <br /> * '''dp_noanswer_reason''': regexp: Regexp to match termination reason when a called party terminates the call and we have the 'no answer' DP armed<br/><br /> If the reason matches dp_noanswer_reason the 'no answer' DP will be notified to SCP<br/><br /> Defaults to ^noanswer$<br/><br /> <br /> * '''export_xml_as''': string: Specify in which way the XML will be passed along into camel messages. Allowed values are:<br /> ** string: pass the XML as a string<br/><br /> ** object: pass the XML as an object<br/><br /> ** both: pass the XML as a string and object<br/><br /> This parameter can be overridden from routing.<br/><br /> Defaults to object<br/><br /> <br /> * '''print_xml''': boolean/string: Instruct the module to print sent/received xml components. Allowed values are:<br /> ** boolean true: Print xml on single line<br /> ** boolean false: Don't print xml<br /> ** verbose: Print xml children on separate lines<br /> This parameter can be overridden from routing.<br/><br /> Defaults to false<br/><br /> <br /> * '''print_decoded''': boolean: Print decoded xml elements to output if debug is at level 10<br/><br /> This parameter can be overridden from routing.<br/><br /> Defaults to no<br/><br /> <br /> ==BCSM Routing==<br /> <br /> ===call.execute handling===<br /> <br /> An incoming call is routed to this module by adding a '''bcsm/''' prefix to target.<br/><br /> The prefix may be followed a call target to use when CAMEL SCF request to continue the call at initial DP, CAMEL SCF is not available (network failure) or initialDP fails:<br /> <br /> ^123$=bcsm/sig/123;trunk=trunk1<br /> <br /> The following parameters (See [[#BCSM Configuration|BCSM Configuration]] for details) can be added when routing:<br /> * servicekey<br /> * default_call_handling_continue<br /> <br /> Example:<br /> <br /> ^123$=bcsm/sig/123;trunk=trunk1;servicekey=2;default_call_handling_continue=false<br /> <br /> ===Starting outgoing calls===<br /> <br /> When need to start an outgoing call (received ETC, ICA/CWA, CWA, CONT) the module will send ''call.preroute'', ''call.route'' and ''call.execute'' messages.<br/><br /> The ''call.preroute'' message is filled with initial ''call.execute'' message parameters and request parameters (the request may override initial parameters).<br/><br /> <br/><br /> The following parameters are always replaced in the initial message:<br /> * '''id''': Replaced by BCSM leg id<br /> * '''module''': Replaced by BCSM module name<br /> <br /> When the initial call is continued, e.g. the call must be continued to initial called number, the call is routed if no target was specified in ''call.execute'' message, e.g. the call was initially routed to ''bcsm/''.<br/><br /> Otherwise, a ''call.execute'' message is sent with initial target in ''callto'' parameter.<br/><br /> <br /> '''NOTES:'''<br /> * The preroute/route/execute messages are dispatched, e.g. the operation is done synchronously.<br /> * When ICA/CWA is processed, the initial message parameters are replaced from ICA first and then from CWA request.</div>

Monica https://ss7api.null.ro/index.php/MSC_simulator MSC simulator 2013-10-28T11:56:58Z

<p>Monica: /* call.execute handling */</p> <hr /> <div>This module simulates the call related features of a CAMEL capable MSC.<br /> <br /> In particular the module implements the Basic Call Machine State described by the CAMEL standards.<br /> <br /> The module does not store the CAMEL subscription, instead it expects any subscription information to be provided in the inbound call routing parameters.<br /> <br /> ==BCSM Module Configuration==<br /> The configuration file is '''camel_bcsm.conf'''.<br /> Sections:<br /> ===[general]===<br /> Unless explicitly specified, all parameters in this section are applied on reload for new calls only.<br/><br /> Parameters:<br /> <br /> * '''application''': string: Application parameter in camel messages sent by the module<br/><br /> This parameter is required<br/><br /> This parameter can be overridden from routing for each call<br/><br /> <br /> * '''camel_phase''': integer: CAMEL phase to use<br /> Allowed values: 1, 2, 3, 4<br/><br /> Defaults to 4<br/><br /> This parameter can be overridden from routing for each call<br/><br /> <br /> * '''servicekey''': integer: CAMEL serviceKey parameter to be set in initialDP messages<br /> Allowed interval: 0..2147483647<br/><br /> Defaults to 0<br/><br /> This parameters can be overridden from routing for each statically armed DP (see [[#call.execute handling|call.execute handling]])<br/><br /> <br /> * '''msc_address''': string: The mscAddress parameter to be set when sending initialDP<br /> * '''msc_address_plan''': string: MSC address numbering plan. Values: unknown, isdn, data, telex, land-mobile, isdn-mobile, national, private, extension-reserved<br /> * '''msc_address_nature''': string: MSC address number nature. Values: unknown, international, national, network-specific, subscriber, reserved, abbreviated, extension-reserved<br /> This parameters can be overridden from routing for each statically armed DP (see [[#call.execute handling|call.execute handlin]])<br /> <br /> * '''default_call_handling_continue''': boolean: Continue operation when an error occurs<br /> Defaults to enable<br/><br /> This parameters can be overridden from routing for each statically armed DP (see [[#call.execute handling|call.execute handlin]])<br/><br /> <br /> * '''tssf_timer''': integer: Application timer (milliseconds) for non user interaction<br/><br /> This interval is used when call processing is suspended and no user interaction is expected, e.g. an event was notified to SCP and we are waiting for instructions<br/><br /> Interval allowed: 1000..20000 (1..20s)<br/><br /> Defaults to 3000 (3 seconds)<br/><br /> <br /> * '''tssf_timer_user''': integer: Application timer (milliseconds) for user interaction<br/><br /> This interval id used when call processing is suspended and user interaction is expected, e.g. a disconnectForwardConnection (disconnect a temporary leg) was received from SCP<br/><br /> Interval allowed: 60000..1800000 (1..30min)<br/><br /> Defaults to 180000 (3 minutes)<br/><br /> <br /> * '''report_etc_failed_timer''': integer: The interval in milliseconds to report failure for temporary calls started on Establish Temporary Connection requests<br /> Failure will be reported if the SRF terminates the call within this interval<br/><br /> If no failure is reported the controlling SCF (which has its own timer) will treat the request as succeeded<br/><br /> This parameter can be overridden from routing<br/><br /> Minimum allowed value is 1000<br/><br /> Defaults to 3000.<br/><br /> <br /> * '''dp_busy_reason''': regexp: Regexp to match termination reason when a called party terminates the call and we have the 'busy' DP armed<br/><br /> If the reason matches dp_busy_reason the 'busy' DP will be notified to SCP<br/><br /> Defaults to ^busy$<br/><br /> <br /> * '''dp_noanswer_reason''': regexp: Regexp to match termination reason when a called party terminates the call and we have the 'no answer' DP armed<br/><br /> If the reason matches dp_noanswer_reason the 'no answer' DP will be notified to SCP<br/><br /> Defaults to ^noanswer$<br/><br /> <br /> * '''export_xml_as''': string: Specify in which way the XML will be passed along into camel messages. Allowed values are:<br /> ** string: pass the XML as a string<br/><br /> ** object: pass the XML as an object<br/><br /> ** both: pass the XML as a string and object<br/><br /> This parameter can be overridden from routing.<br/><br /> Defaults to object<br/><br /> <br /> * '''print_xml''': boolean/string: Instruct the module to print sent/received xml components. Allowed values are:<br /> ** boolean true: Print xml on single line<br /> ** boolean false: Don't print xml<br /> ** verbose: Print xml children on separate lines<br /> This parameter can be overridden from routing.<br/><br /> Defaults to false<br/><br /> <br /> * '''print_decoded''': boolean: Print decoded xml elements to output if debug is at level 10<br/><br /> This parameter can be overridden from routing.<br/><br /> Defaults to no<br/><br /> <br /> ==BCSM Routing==<br /> <br /> ===call.execute handling===<br /> <br /> An incoming call is routed to this module by adding a '''bcsm/''' prefix to target.\\<br /> The prefix may be followed a call target to use when CAMEL SCF request to continue the call at initial DP, CAMEL SCF is not available (network failure) or initialDP fails:<br /> <br /> ^123$=bcsm/sig/123;trunk=trunk1<br /> <br /> The following parameters (See [[#BCSM Configuration|BCSM Configuration]] for details) can be added when routing:<br /> * servicekey<br /> * default_call_handling_continue<br /> <br /> Example:<br /> <br /> ^123$=bcsm/sig/123;trunk=trunk1;servicekey=2;default_call_handling_continue=false<br /> <br /> ===Starting outgoing calls===<br /> <br /> When need to start an outgoing call (received ETC, ICA/CWA, CWA, CONT) the module will send ''call.preroute'', ''call.route'' and ''call.execute'' messages.<br/><br /> The ''call.preroute'' message is filled with initial ''call.execute'' message parameters and request parameters (the request may override initial parameters).<br/><br /> <br/><br /> The following parameters are always replaced in the initial message:<br /> * '''id''': Replaced by BCSM leg id<br /> * '''module''': Replaced by BCSM module name<br /> <br /> When the initial call is continued, e.g. the call must be continued to initial called number, the call is routed if no target was specified in ''call.execute'' message, e.g. the call was initially routed to ''bcsm/''.<br/><br /> Otherwise, a ''call.execute'' message is sent with initial target in ''callto'' parameter.<br/><br /> <br /> '''NOTES:'''<br /> * The preroute/route/execute messages are dispatched, e.g. the operation is done synchronously.<br /> * When ICA/CWA is processed, the initial message parameters are replaced from ICA first and then from CWA request.</div>

Monica https://ss7api.null.ro/index.php/MSC_simulator MSC simulator 2013-10-28T11:56:26Z

<p>Monica: /* [general] */</p> <hr /> <div>This module simulates the call related features of a CAMEL capable MSC.<br /> <br /> In particular the module implements the Basic Call Machine State described by the CAMEL standards.<br /> <br /> The module does not store the CAMEL subscription, instead it expects any subscription information to be provided in the inbound call routing parameters.<br /> <br /> ==BCSM Module Configuration==<br /> The configuration file is '''camel_bcsm.conf'''.<br /> Sections:<br /> ===[general]===<br /> Unless explicitly specified, all parameters in this section are applied on reload for new calls only.<br/><br /> Parameters:<br /> <br /> * '''application''': string: Application parameter in camel messages sent by the module<br/><br /> This parameter is required<br/><br /> This parameter can be overridden from routing for each call<br/><br /> <br /> * '''camel_phase''': integer: CAMEL phase to use<br /> Allowed values: 1, 2, 3, 4<br/><br /> Defaults to 4<br/><br /> This parameter can be overridden from routing for each call<br/><br /> <br /> * '''servicekey''': integer: CAMEL serviceKey parameter to be set in initialDP messages<br /> Allowed interval: 0..2147483647<br/><br /> Defaults to 0<br/><br /> This parameters can be overridden from routing for each statically armed DP (see [[#call.execute handling|call.execute handling]])<br/><br /> <br /> * '''msc_address''': string: The mscAddress parameter to be set when sending initialDP<br /> * '''msc_address_plan''': string: MSC address numbering plan. Values: unknown, isdn, data, telex, land-mobile, isdn-mobile, national, private, extension-reserved<br /> * '''msc_address_nature''': string: MSC address number nature. Values: unknown, international, national, network-specific, subscriber, reserved, abbreviated, extension-reserved<br /> This parameters can be overridden from routing for each statically armed DP (see [[#call.execute handling|call.execute handlin]])<br /> <br /> * '''default_call_handling_continue''': boolean: Continue operation when an error occurs<br /> Defaults to enable<br/><br /> This parameters can be overridden from routing for each statically armed DP (see [[#call.execute handling|call.execute handlin]])<br/><br /> <br /> * '''tssf_timer''': integer: Application timer (milliseconds) for non user interaction<br/><br /> This interval is used when call processing is suspended and no user interaction is expected, e.g. an event was notified to SCP and we are waiting for instructions<br/><br /> Interval allowed: 1000..20000 (1..20s)<br/><br /> Defaults to 3000 (3 seconds)<br/><br /> <br /> * '''tssf_timer_user''': integer: Application timer (milliseconds) for user interaction<br/><br /> This interval id used when call processing is suspended and user interaction is expected, e.g. a disconnectForwardConnection (disconnect a temporary leg) was received from SCP<br/><br /> Interval allowed: 60000..1800000 (1..30min)<br/><br /> Defaults to 180000 (3 minutes)<br/><br /> <br /> * '''report_etc_failed_timer''': integer: The interval in milliseconds to report failure for temporary calls started on Establish Temporary Connection requests<br /> Failure will be reported if the SRF terminates the call within this interval<br/><br /> If no failure is reported the controlling SCF (which has its own timer) will treat the request as succeeded<br/><br /> This parameter can be overridden from routing<br/><br /> Minimum allowed value is 1000<br/><br /> Defaults to 3000.<br/><br /> <br /> * '''dp_busy_reason''': regexp: Regexp to match termination reason when a called party terminates the call and we have the 'busy' DP armed<br/><br /> If the reason matches dp_busy_reason the 'busy' DP will be notified to SCP<br/><br /> Defaults to ^busy$<br/><br /> <br /> * '''dp_noanswer_reason''': regexp: Regexp to match termination reason when a called party terminates the call and we have the 'no answer' DP armed<br/><br /> If the reason matches dp_noanswer_reason the 'no answer' DP will be notified to SCP<br/><br /> Defaults to ^noanswer$<br/><br /> <br /> * '''export_xml_as''': string: Specify in which way the XML will be passed along into camel messages. Allowed values are:<br /> ** string: pass the XML as a string<br/><br /> ** object: pass the XML as an object<br/><br /> ** both: pass the XML as a string and object<br/><br /> This parameter can be overridden from routing.<br/><br /> Defaults to object<br/><br /> <br /> * '''print_xml''': boolean/string: Instruct the module to print sent/received xml components. Allowed values are:<br /> ** boolean true: Print xml on single line<br /> ** boolean false: Don't print xml<br /> ** verbose: Print xml children on separate lines<br /> This parameter can be overridden from routing.<br/><br /> Defaults to false<br/><br /> <br /> * '''print_decoded''': boolean: Print decoded xml elements to output if debug is at level 10<br/><br /> This parameter can be overridden from routing.<br/><br /> Defaults to no<br/><br /> <br /> ==BCSM Routing==<br /> <br /> ===call.execute handling===<br /> <br /> An incoming call is routed to this module by adding a '''bcsm/''' prefix to target.\\<br /> The prefix may be followed a call target to use when CAMEL SCF request to continue the call at initial DP, CAMEL SCF is not available (network failure) or initialDP fails:<br /> <br /> ^123$=bcsm/sig/123;trunk=trunk1<br /> <br /> The following parameters (See [[BCSM Configuration]] for details) can be added when routing:<br /> * servicekey<br /> * default_call_handling_continue<br /> <br /> Example:<br /> <br /> ^123$=bcsm/sig/123;trunk=trunk1;servicekey=2;default_call_handling_continue=false<br /> <br /> <br /> ===Starting outgoing calls===<br /> <br /> When need to start an outgoing call (received ETC, ICA/CWA, CWA, CONT) the module will send ''call.preroute'', ''call.route'' and ''call.execute'' messages.<br/><br /> The ''call.preroute'' message is filled with initial ''call.execute'' message parameters and request parameters (the request may override initial parameters).<br/><br /> <br/><br /> The following parameters are always replaced in the initial message:<br /> * '''id''': Replaced by BCSM leg id<br /> * '''module''': Replaced by BCSM module name<br /> <br /> When the initial call is continued, e.g. the call must be continued to initial called number, the call is routed if no target was specified in ''call.execute'' message, e.g. the call was initially routed to ''bcsm/''.<br/><br /> Otherwise, a ''call.execute'' message is sent with initial target in ''callto'' parameter.<br/><br /> <br /> '''NOTES:'''<br /> * The preroute/route/execute messages are dispatched, e.g. the operation is done synchronously.<br /> * When ICA/CWA is processed, the initial message parameters are replaced from ICA first and then from CWA request.</div>

Monica https://ss7api.null.ro/index.php/MSC_simulator MSC simulator 2013-10-28T11:55:30Z

<p>Monica: </p> <hr /> <div>This module simulates the call related features of a CAMEL capable MSC.<br /> <br /> In particular the module implements the Basic Call Machine State described by the CAMEL standards.<br /> <br /> The module does not store the CAMEL subscription, instead it expects any subscription information to be provided in the inbound call routing parameters.<br /> <br /> ==BCSM Module Configuration==<br /> The configuration file is '''camel_bcsm.conf'''.<br /> Sections:<br /> ===[general]===<br /> Unless explicitly specified, all parameters in this section are applied on reload for new calls only.<br/><br /> Parameters:<br /> <br /> * '''application''': string: Application parameter in camel messages sent by the module<br/><br /> This parameter is required<br/><br /> This parameter can be overridden from routing for each call<br/><br /> <br /> * '''camel_phase''': integer: CAMEL phase to use<br /> Allowed values: 1, 2, 3, 4<br/><br /> Defaults to 4<br/><br /> This parameter can be overridden from routing for each call<br/><br /> <br /> * '''servicekey''': integer: CAMEL serviceKey parameter to be set in initialDP messages<br /> Allowed interval: 0..2147483647<br/><br /> Defaults to 0<br/><br /> This parameters can be overridden from routing for each statically armed DP (see [[BCSM Routing#BehaviourCallExecuteHandle|call.execute handling]])<br/><br /> <br /> * '''msc_address''': string: The mscAddress parameter to be set when sending initialDP<br /> * '''msc_address_plan''': string: MSC address numbering plan. Values: unknown, isdn, data, telex, land-mobile, isdn-mobile, national, private, extension-reserved<br /> * '''msc_address_nature''': string: MSC address number nature. Values: unknown, international, national, network-specific, subscriber, reserved, abbreviated, extension-reserved<br /> This parameters can be overridden from routing for each statically armed DP (see [[BCSM Routing#BehaviourCallExecuteHandle|call.execute handling]])<br /> <br /> * '''default_call_handling_continue''': boolean: Continue operation when an error occurs<br /> Defaults to enable<br/><br /> This parameters can be overridden from routing for each statically armed DP (see [[BCSM Routing#BehaviourCallExecuteHandle|call.execute handling]])<br/><br /> <br /> * '''tssf_timer''': integer: Application timer (milliseconds) for non user interaction<br/><br /> This interval is used when call processing is suspended and no user interaction is expected, e.g. an event was notified to SCP and we are waiting for instructions<br/><br /> Interval allowed: 1000..20000 (1..20s)<br/><br /> Defaults to 3000 (3 seconds)<br/><br /> <br /> * '''tssf_timer_user''': integer: Application timer (milliseconds) for user interaction<br/><br /> This interval id used when call processing is suspended and user interaction is expected, e.g. a disconnectForwardConnection (disconnect a temporary leg) was received from SCP<br/><br /> Interval allowed: 60000..1800000 (1..30min)<br/><br /> Defaults to 180000 (3 minutes)<br/><br /> <br /> * '''report_etc_failed_timer''': integer: The interval in milliseconds to report failure for temporary calls started on Establish Temporary Connection requests<br /> Failure will be reported if the SRF terminates the call within this interval<br/><br /> If no failure is reported the controlling SCF (which has its own timer) will treat the request as succeeded<br/><br /> This parameter can be overridden from routing<br/><br /> Minimum allowed value is 1000<br/><br /> Defaults to 3000.<br/><br /> <br /> * '''dp_busy_reason''': regexp: Regexp to match termination reason when a called party terminates the call and we have the 'busy' DP armed<br/><br /> If the reason matches dp_busy_reason the 'busy' DP will be notified to SCP<br/><br /> Defaults to ^busy$<br/><br /> <br /> * '''dp_noanswer_reason''': regexp: Regexp to match termination reason when a called party terminates the call and we have the 'no answer' DP armed<br/><br /> If the reason matches dp_noanswer_reason the 'no answer' DP will be notified to SCP<br/><br /> Defaults to ^noanswer$<br/><br /> <br /> * '''export_xml_as''': string: Specify in which way the XML will be passed along into camel messages. Allowed values are:<br /> ** string: pass the XML as a string<br/><br /> ** object: pass the XML as an object<br/><br /> ** both: pass the XML as a string and object<br/><br /> This parameter can be overridden from routing.<br/><br /> Defaults to object<br/><br /> <br /> * '''print_xml''': boolean/string: Instruct the module to print sent/received xml components. Allowed values are:<br /> ** boolean true: Print xml on single line<br /> ** boolean false: Don't print xml<br /> ** verbose: Print xml children on separate lines<br /> This parameter can be overridden from routing.<br/><br /> Defaults to false<br/><br /> <br /> * '''print_decoded''': boolean: Print decoded xml elements to output if debug is at level 10<br/><br /> This parameter can be overridden from routing.<br/><br /> Defaults to no<br/><br /> <br /> ==BCSM Routing==<br /> <br /> ===call.execute handling===<br /> <br /> An incoming call is routed to this module by adding a '''bcsm/''' prefix to target.\\<br /> The prefix may be followed a call target to use when CAMEL SCF request to continue the call at initial DP, CAMEL SCF is not available (network failure) or initialDP fails:<br /> <br /> ^123$=bcsm/sig/123;trunk=trunk1<br /> <br /> The following parameters (See [[BCSM Configuration]] for details) can be added when routing:<br /> * servicekey<br /> * default_call_handling_continue<br /> <br /> Example:<br /> <br /> ^123$=bcsm/sig/123;trunk=trunk1;servicekey=2;default_call_handling_continue=false<br /> <br /> <br /> ===Starting outgoing calls===<br /> <br /> When need to start an outgoing call (received ETC, ICA/CWA, CWA, CONT) the module will send ''call.preroute'', ''call.route'' and ''call.execute'' messages.<br/><br /> The ''call.preroute'' message is filled with initial ''call.execute'' message parameters and request parameters (the request may override initial parameters).<br/><br /> <br/><br /> The following parameters are always replaced in the initial message:<br /> * '''id''': Replaced by BCSM leg id<br /> * '''module''': Replaced by BCSM module name<br /> <br /> When the initial call is continued, e.g. the call must be continued to initial called number, the call is routed if no target was specified in ''call.execute'' message, e.g. the call was initially routed to ''bcsm/''.<br/><br /> Otherwise, a ''call.execute'' message is sent with initial target in ''callto'' parameter.<br/><br /> <br /> '''NOTES:'''<br /> * The preroute/route/execute messages are dispatched, e.g. the operation is done synchronously.<br /> * When ICA/CWA is processed, the initial message parameters are replaced from ICA first and then from CWA request.</div>

Monica https://ss7api.null.ro/index.php/MSC_simulator MSC simulator 2013-10-28T11:53:27Z

<p>Monica: Created page with "This module simulates the call related features of a CAMEL capable MSC. In particular the module implements the Basic Call Machine State described by the CAMEL standards. Th..."</p> <hr /> <div>This module simulates the call related features of a CAMEL capable MSC.<br /> <br /> In particular the module implements the Basic Call Machine State described by the CAMEL standards.<br /> <br /> The module does not store the CAMEL subscription, instead it expects any subscription information to be provided in the inbound call routing parameters.<br /> <br /> ==BCSM Module Configuration==<br /> The configuration file is '''camel_bcsm.conf'''.<br /> Sections:<br /> ===[general]===<br /> Unless explicitly specified, all parameters in this section are applied on reload for new calls only.<br/><br /> Parameters:<br /> <br /> * '''application''': string: Application parameter in camel messages sent by the module<br/><br /> This parameter is required<br/><br /> This parameter can be overridden from routing for each call<br/><br /> <br /> * '''camel_phase''': integer: CAMEL phase to use<br /> Allowed values: 1, 2, 3, 4<br/><br /> Defaults to 4<br/><br /> This parameter can be overridden from routing for each call<br/><br /> <br /> * '''servicekey''': integer: CAMEL serviceKey parameter to be set in initialDP messages<br /> Allowed interval: 0..2147483647<br/><br /> Defaults to 0<br/><br /> This parameters can be overridden from routing for each statically armed DP (see [[BCSM Routing#BehaviourCallExecuteHandle|call.execute handling]])<br/><br /> <br /> * '''msc_address''': string: The mscAddress parameter to be set when sending initialDP<br /> * '''msc_address_plan''': string: MSC address numbering plan. Values: unknown, isdn, data, telex, land-mobile, isdn-mobile, national, private, extension-reserved<br /> * '''msc_address_nature''': string: MSC address number nature. Values: unknown, international, national, network-specific, subscriber, reserved, abbreviated, extension-reserved<br /> This parameters can be overridden from routing for each statically armed DP (see [[BCSM Routing#BehaviourCallExecuteHandle|call.execute handling]])<br /> <br /> * '''default_call_handling_continue''': boolean: Continue operation when an error occurs<br /> Defaults to enable<br/><br /> This parameters can be overridden from routing for each statically armed DP (see [[BCSM Routing#BehaviourCallExecuteHandle|call.execute handling]])<br/><br /> <br /> * '''tssf_timer''': integer: Application timer (milliseconds) for non user interaction<br/><br /> This interval is used when call processing is suspended and no user interaction is expected, e.g. an event was notified to SCP and we are waiting for instructions<br/><br /> Interval allowed: 1000..20000 (1..20s)<br/><br /> Defaults to 3000 (3 seconds)<br/><br /> <br /> * '''tssf_timer_user''': integer: Application timer (milliseconds) for user interaction<br/><br /> This interval id used when call processing is suspended and user interaction is expected, e.g. a disconnectForwardConnection (disconnect a temporary leg) was received from SCP<br/><br /> Interval allowed: 60000..1800000 (1..30min)<br/><br /> Defaults to 180000 (3 minutes)<br/><br /> <br /> * '''report_etc_failed_timer''': integer: The interval in milliseconds to report failure for temporary calls started on Establish Temporary Connection requests<br /> Failure will be reported if the SRF terminates the call within this interval<br/><br /> If no failure is reported the controlling SCF (which has its own timer) will treat the request as succeeded<br/><br /> This parameter can be overridden from routing<br/><br /> Minimum allowed value is 1000<br/><br /> Defaults to 3000.<br/><br /> <br /> * '''dp_busy_reason''': regexp: Regexp to match termination reason when a called party terminates the call and we have the 'busy' DP armed<br/><br /> If the reason matches dp_busy_reason the 'busy' DP will be notified to SCP<br/><br /> Defaults to ^busy$<br/><br /> <br /> * '''dp_noanswer_reason''': regexp: Regexp to match termination reason when a called party terminates the call and we have the 'no answer' DP armed<br/><br /> If the reason matches dp_noanswer_reason the 'no answer' DP will be notified to SCP<br/><br /> Defaults to ^noanswer$<br/><br /> <br /> * '''export_xml_as''': string: Specify in which way the XML will be passed along into camel messages. Allowed values are:<br /> ** string: pass the XML as a string<br/><br /> ** object: pass the XML as an object<br/><br /> ** both: pass the XML as a string and object<br/><br /> This parameter can be overridden from routing.<br/><br /> Defaults to object<br/><br /> <br /> * '''print_xml''': boolean/string: Instruct the module to print sent/received xml components. Allowed values are:<br /> ** boolean true: Print xml on single line<br /> ** boolean false: Don't print xml<br /> ** verbose: Print xml children on separate lines<br /> This parameter can be overridden from routing.<br/><br /> Defaults to false<br/><br /> <br /> * '''print_decoded''': boolean: Print decoded xml elements to output if debug is at level 10<br/><br /> This parameter can be overridden from routing.<br/><br /> Defaults to no<br/></div>

Monica https://ss7api.null.ro/index.php/CAMEL_proxy CAMEL proxy 2013-10-28T11:47:56Z

<p>Monica: /* General */</p> <hr /> <div>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.<br /> <br /> The main purpose is to be able to provide CRBT and PPS (PrePaid Service) facilities in parallel.<br /> <br /> The layout for such a scenario will look like this:<br /> <br /> [[File:CamelProxy.png]]<br /> <br /> 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.<br /> The proxy keeps an evidence of these multiple invocations and aggregates them into a single, valid dialogue with the invoking SSP.<br /> <br /> ==Camel Proxy Module Configuration==<br /> <br /> The configuration file is camel_bcsm_proxy.conf<br /> <br /> ===Module configuration===<br /> <br /> ===='general' section====<br /> <br /> '''application''': Application parameter in camel messages sent/handled for SSF dialogs.<br/><br /> This parameter is required and is not applied on reload (can't be changed after module starts).<br/><br /> <br/><br /> '''gt''': Global Title to be set in the first message sent in the SSF dialog.<br/><br /> This parameter is applied on reload.<br/><br /> TCAP address parameters to be set in the first message sent back to SSF can also be set using '''addr.''' prefix.<br/><br /> E.g. GT can be set as '''addr.CallingPartyAddress.gt''' along with other parameters like number nature '''addr.CallingPartyAddress.nature'''.<br/><br /> Setting the GT without other parameters is the same as:<br/><br /> addr.CallingPartyAddress.gt=[GT set]<br/><br /> addr.CallingPartyAddress.route=gt<br/><br /> addr.CallingPartyAddress.gt.encoding=bcd<br/><br /> addr.CallingPartyAddress.gt.translation=0<br/><br /> addr.CallingPartyAddress.gt.plan=isdn<br/><br /> addr.CallingPartyAddress.gt.nature=international<br/><br /> <br/><br /> '''servicekey''': CAMEL serviceKey to check when in received initialDP and set when forwarding them to SCFs.<br/><br /> Allowed interval: 0..2147483647.<br/><br /> Defaults to 0 if missing or invalid.<br/><br /> This parameter is applied on reload for new dialogs only.<br/><br /> <br/><br /> '''query_scf''': Boolean value indicating whether to query for proxied SCFs update when processing initialDP.<br/><br /> Is enabled a 'scf.query' message will be enqueued and the module will wait for a 'scf.response' message to continue IDP processing.<br/><br /> Defaults to no.<br/><br /> <br/><br /> '''print_msg''': boolean/string: Print sent/received messages to output if debug level is at least 9.<br/><br /> Allowed values are boolean values or 'verbose' string.<br/><br /> If verbose is specified, the message will be dumped on output.<br/><br /> Defaults to no.<br/><br /> <br/><br /> '''print_xml''': boolean/string: Print sent/received XML data to output if debug level is at least 9.<br/><br /> This parameter is ignored if print_msg is disabled.<br/><br /> Allowed values are boolean values or 'verbose' string.<br/><br /> If verbose is specified, XML elements' children, attributes or text will be shown on separate lines.<br/><br /> Defaults to no.<br/><br /> <br/><br /> '''idp_calling_required''': boolean: Calling party number is required (non empty) in initialDP.<br/><br /> Default to yes.<br/><br /> <br/><br /> '''idp_called_required''': boolean: Called party number is required (non empty) in initialDP.<br/><br /> Default to yes.<br/><br /> <br/><br /> '''dispatcher_maxthreads''': integer: Maximum number of message dispatch threads to use.<br/><br /> Set to 0 to enqueue messages using yate engine.<br/><br /> Defaults to 0.<br/><br /> 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).<br/><br /> <br/><br /> ====Proxied SCF section(s)====<br /> <br /> '''enable''': boolean: Enable the SCF.<br/><br /> Defaults to yes.<br/><br /> <br/><br /> '''priority''': integer: Priority in handling messages from SSF.<br/><br /> Defaults to 0.<br/><br /> <br/><br /> '''servicekey''': integer: Value with which the IDP serviceKey should be rewritten.<br/><br /> Allowed interval: 0..2147483647.<br/><br /> Defaults to SSF service key set in 'general' section.<br/><br /> <br/><br /> '''dp''': string: Comma separated list of detection points that should match the one received in IDP in order to contact this SCF.<br/><br /> Items may be DP value or name.<br/><br /> Defaults to termAttemptAuthorized if empty or all DPs are invalid.<br/><br /> <br/><br /> '''endfatal''': boolean: Indicate whether or not terminate the proxy dialog when this dialog ends.<br/><br /> Defaults to no.<br/><br /> <br/><br /> '''errorfatal''': boolean: Indicate whether or not an error or reject component from the SCF should terminate the whole proxy dialog.<br/><br /> Defaults to no.<br/><br /> <br/><br /> '''local''': boolean: The SCF is local (a local application) or external (it passes through the SS7 network to reach it).<br/><br /> Defaults to no (external application).<br/><br /> <br/><br /> '''instances''': integer: Number of local application instances.<br/><br /> This parameter is ignored for non local SCFs.<br/><br /> If non 0 it must be set to a value greater then 1.<br/><br /> Defaults to 0.<br/><br /> If non 0 the module will build the required number of SCFs and will pick them using a round-robin algorithm.<br/><br /> Each application's name will be built from SCF application name concatenated with instance suffix startting from 1.<br/><br /> E.g.:<br /> <br /> [proxy SCP]<br /> instances=2<br /> <br /> Will build 2 applications: SCP1 and SCP2.<br/><br /> <br/><br /> '''handles''': string: Comma separated list of operations received from the SSF accepted by this SCF.<br/><br /> 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.<br/><br /> <br/><br /> '''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.<br/><br /> Defaults to 3000.<br/><br /> Minimum allowed value is 1000.<br/><br /> <br/><br /> All other parameters starting with 'addr.' prefix will be put in dialog begin message sent for this SCF.<br/><br /> They should be set for non local SCFs.<br/><br /> Parameters:<br /> * '''addr.CalledPartyAddress.route''' - string. It can be set to values: gt/ssn. It specifies how the SCCP address should be routed.<br /> * '''addr.CalledPartyAddress.ssn''' - integer. It's the SSN number in case of SSN routing.<br /> * '''addr.CalledPartyAddress.gt''' - string. GTT number digits for the SCF.<br /> * '''addr.CalledPartyAddress.gt.encoding''' - string. It specifies the encoding for the GT digits. It is usually set to bcd.<br /> * '''addr.CalledPartyAddress.gt.tt''' - integer. It specifies the GT translation type. It is usually set to 0.<br /> * '''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.<br /> * '''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.<br /> * '''addr.CallingPartyAddress.route'''<br /> * '''addr.CalledPartyAddress.ssn'''<br /> * '''addr.CallingPartyAddress.gt'''<br /> * '''addr.CallingPartyAddress.gt.encoding'''<br /> * '''addr.CallingPartyAddress.gt.tt'''<br /> * '''addr.CallingPartyAddress.gt.np'''<br /> * '''addr.CallingPartyAddress.gt.nature''' <br /> <br /> ====Example====<br /> <br /> [general]<br /> application=camelProxy<br /> servicekey=1<br /> gt=8820003<br /> <br /> [proxy crbt-scp]<br /> servicekey=2<br /> local=true<br /> <br /> [proxy pps-scp]<br /> servicekey=99<br /> priority=2<br /> errorfatal=true<br /> handles=applyChargingReport<br /> addr.CalledPartyAddress.gt=8820007<br /> addr.CalledPartyAddress.route=gt<br /> addr.CalledPartyAddress.gt.encoding=bcd<br /> addr.CalledPartyAddress.gt.tt=0<br /> addr.CalledPartyAddress.gt.np=isdn<br /> addr.CalledPartyAddress.gt.nature=international<br /> addr.CallingPartyAddress.gt=8820003<br /> addr.CallingPartyAddress.route=gt<br /> addr.CallingPartyAddress.gt.encoding=bcd<br /> addr.CallingPartyAddress.gt.tt=0<br /> addr.CallingPartyAddress.gt.np=isdn<br /> addr.CallingPartyAddress.gt.nature=international<br /> <br /> <br /> === camel_map configuration ===<br /> <br /> [local camelProxy]<br /> translator=scp_proxy<br /> capabilities=Camel<br /> <br /> [tcap scp_proxy]<br /> type=CAMEL<br /> tcap=tcap_msc<br /> port=0<br /> <br /> [local pps-scp]<br /> translator=scp_pps<br /> capabilities=Camel<br /> <br /> [tcap scp_pps]<br /> type=CAMEL<br /> tcap=tcap_pps<br /> port=0<br /> <br /> ===camel_bcsm_proxy.conf.sample===<br /> <br /> ; NOTE: This module is not loaded automatically, it needs a line in yate.conf:<br /> ; [postload]<br /> ; ${modulepath}/sig/camel_bcsm_proxy${modsuffix}=yes<br /> <br /> [general]<br /> ; Unless explicitly specified, all parameters are applied on reload for new<br /> ; dialogs only<br /> ; All parameters starting with 'addr.' prefix will be put in the first message sent to SSF<br /> <br /> ; application: string: Application parameter in camel messages sent by the module<br /> ; This parameter is required<br /> ; This parameter is not applied on reload<br /> ;application=<br /> <br /> ; gt: string: Global Title to be set in the first message sent in the SSF dialog<br /> ; This parameter is applied on reload for new dialogs only<br /> ; If non empty other calling party address parameters will be set to default values<br /> ; This parameter can be overriden by addr.CallingPartyAddress.gt parameter<br /> ;gt=<br /> <br /> ; servicekey: integer: CAMEL serviceKey to check in received initialDP messages and<br /> ; set when forwarding them to SCFs<br /> ; Allowed interval: 0..2147483647<br /> ; Defaults to 0 if missing or invalid<br /> ; This parameter is applied on reload for new dialogs only<br /> ;servicekey=0<br /> <br /> ; query_scf: boolean: Query for proxied SCFs update when processing initialDP<br /> ; Is enabled a 'scf.query' message will be enqueued and the module will wait<br /> ; for a 'scf.response' message to continue IDP processing<br /> ; The response must return the list of SCFs to proxy<br /> ; The list may be shorter then configured SCFs<br /> ; New SCFs, other then configured ones, will be ignored<br /> ; The following SCF parameters can be overridden: priority, servicekey, errorfatal,<br /> ; handles, waittime and all parameters starting with 'addr.' prefix<br /> ; Defaults to no<br /> ;query_scf=no<br /> <br /> ; component_ttl: integer: Component time to live in milliseconds<br /> ; Minimum allowed value is 1000<br /> ; Defaults to 15000<br /> ;component_ttl=15000<br /> <br /> ; dialog_idle_ttl: integer: Dialog idle (nothing sent/received) time to live in milliseconds<br /> ; Minimum allowed value is 1000<br /> ; It can be set to 0 to keep it alive until the remote party terminates the dialog<br /> ; Defaults to 5000<br /> ;dialog_idle_ttl=5000<br /> <br /> ; dialog_ended_ttl: integer: Ended dialog time to live in milliseconds<br /> ; Minimum allowed value is 1000.<br /> ; It can be set to 0 to remove the dialog after termination<br /> ; Defaults to 0<br /> ;dialog_ended_ttl=0<br /> <br /> ; export_xml_as: string: Specify in which way the XML will be passed along into<br /> ; Yate messages<br /> ; Allowed values are:<br /> ; - string: pass the XML as a string<br /> ; - object: pass the XML as an object<br /> ; - both: pass the XML as a string and object<br /> ; Defaults to object<br /> ;export_xml_as=object<br /> <br /> ; print_msg: boolean/string: Print sent/received messages to output if debug<br /> ; level is at least 9<br /> ; Allowed values are boolean values or 'verbose' string<br /> ; If verbose is specified, the message will be dumped on output<br /> ; Defaults to no<br /> ;print_msg=no<br /> <br /> ; print_xml: boolean/string: Print sent/received XML data to output if debug<br /> ; level is at least 9<br /> ; This parameter is ignored if print_msg is disabled<br /> ; Allowed values are boolean values or 'verbose' string<br /> ; If verbose is specified, XML elements' children, attributes or text will be<br /> ; shown on separate lines<br /> ; Defaults to no<br /> ;print_xml=no<br /> <br /> ; idp_calling_required: boolean: Calling party number is required (non empty) in initialDP<br /> ; Default to yes<br /> ;idp_calling_required=yes<br /> <br /> ; idp_called_required: boolean: Called party number is required (non empty) in initialDP<br /> ; Default to yes<br /> ;idp_called_required=yes<br /> <br /> ; dispatcher_maxthreads: integer: Maximum number of message dispatch threads to use<br /> ; Set to 0 to enqueue messages using yate engine<br /> ; Defaults to 0<br /> ; When reloaded it can't be set to 0 (e.g. once set to a non 0 value it can be changed to<br /> ; non 0 values only)<br /> ;dispatcher_maxthreads=0<br /> <br /> ;dispatcher_priority: string: Default priority of message dispatch threads<br /> ; Can be one of: lowest, low, normal, high, highest<br /> ; High priorities need superuser privileges on POSIX operating systems<br /> ; Low priorities are not recommended except for debugging<br /> ; Defaults to 'normal'<br /> ; This parameter is applied on reload for new threads only<br /> ;dispatcher_priority=normal<br /> <br /> <br /> ;[proxy appname]<br /> ; This section configures a proxied SCF<br /> ; 'appname' is the application name to be used for the SCF<br /> <br /> ; enable: boolean: Enable the SCF<br /> ; Defaults to yes<br /> ;enable=yes<br /> <br /> ; priority: integer: Priority in handling messages from SSF<br /> ; Defaults to 0<br /> ;priority=0<br /> <br /> ; servicekey: integer: Value with which the IDP serviceKey should be rewritten<br /> ; Allowed interval: 0..2147483647<br /> ; Defaults to SSF service key set in 'general' section<br /> ;servicekey=<br /> <br /> ; dp: string: Comma separated list of detection points that should match the one received in IDP<br /> ; in order to contact this SCF<br /> ; Items may be DP value or name<br /> ; Defaults to termAttemptAuthorized if empty or all DPs are invalid<br /> ;dp=termAttemptAuthorized<br /> <br /> ; endfatal: boolean: Indicate whether or not terminate the proxy dialog when this dialog ends<br /> ; Defaults to no<br /> ;endfatal=no<br /> <br /> ; errorfatal: boolean: Indicate whether or not an error or reject component from<br /> ; the SCF should terminate the whole proxy dialog<br /> ; Defaults to no<br /> ;errorfatal=no<br /> <br /> ; local: boolean: The SCF is local (a local application) or external (it passes<br /> ; through the SS7 network to reach it)<br /> ; Defaults to no (external application)<br /> ;local=no<br /> <br /> ; instances: integer: Number of local application instances<br /> ; If non 0 the module will build the required number of SCFs and will pick them using a<br /> ; round-robin algorithm<br /> ; Each application's name will be built from SCF application name concatenated with instance<br /> ; suffix startting from 1<br /> ; E.g.<br /> ; [proxy SCP]<br /> ; instances=2<br /> ; Will build 2 applications: SCP1 and SCP2<br /> ; This parameter is ignored for non local SCFs<br /> ; If non 0 it must be set to a value greater then 1<br /> ; Defaults to 0<br /> ;instance=<br /> <br /> ; handles: string: Comma separated list of operations received from the SSF<br /> ; accepted by this SCF<br /> ; NOTE: Except ERB (Event Report BCSM), which is sent to all SCFs that match the reported DP,<br /> ; all operations that are handled by a SCF should be listed, otherwise the<br /> ; proxy will report to the SSF an error<br /> ;handles=<br /> <br /> ; waittime: integer: Time, in miliseconds, to wait for a result from a SCF<br /> ; while being in Waiting For Instructions state, after which the dialog<br /> ; is aborted<br /> ; Defaults to 3000<br /> ; Minimum allowed value is 1000<br /> ;waittime=3000<br /> <br /> ; All other parameters starting with 'addr.' prefix will be put in dialog begin<br /> ; message sent for this SCF<br /> ; E.g. addr.CalledPartyAddress.route=gt will be put as CalledPartyAddress.route=gt<br /> <br /> ==Proxy Module Test==<br /> This chapter describes how the Camel Proxy module was tested.<br /> <br /> The purpose of the test was to check if the Camel BCSM Proxy module can handle 100CPS.<br /> <br /> The machine used was a Dual Intel Xeon E5620 (Quad Core with HT) = 16CPUs, 32GB RAM with CentOS 6.2<br /> <br /> The setup was:<br/><br /> Yate1 - Call generator, sending calls to Yate3 using SIP<br/><br /> Yate2 - Call generator, sending calls to Yate4 using SIP<br/><br /> Yate3 - Call handling, send initialDP to Yate5 (Proxy)<br/><br /> Yate4 - Call handling, send initialDP to Yate5 (Proxy)<br/><br /> Yate5 - Camel BCSM Proxy<br/><br /> Yate6 - CRBT script<br/><br /> Yate7 - PPS script<br/><br /> Yate8 - PPS script<br /> <br /> <br /> SIP M2PA link M2PA links<br /> Yate1 ---------> Yate3 ------------| |-----------> Yate6 (CRBT)<br /> | |<br /> |-> Yate5 |-----------> Yate7 (PPS)<br /> | |<br /> SIP M2PA link | |-----------> Yate8 (PPS)<br /> Yate2 ---------> Yate4 ------------| <br /> <br /> <br /> '''NOTES:'''<br /> * The sum of both call generators was 110CPS.<br /> * During test top reported ~250%CPU for Proxy.<br /> * All yate instances were running on the same machine.<br /> * 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.<br /> <br /> How success was checked:<br /> * On call generators all calls were answered<br /> * 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')<br /> * On Proxy instance (Yate5) there were no timeouts (this would indicate a SCF is not responding withing default 3 seconds interval)<br /> <br /> ==Configuration==<br /> <br /> ===Script side===<br /> <br /> Configuration of the "camel_proxy.php" script is done through ''config_proxy.php''. This allows setting the following parameters:<br /> <br /> * 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.<br /> <br /> * 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.<br /> <br /> * 3. '''$mynum''' - string. GTT number assigned to this SCP. <br /> <br /> * 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.<br /> <br /> * 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:<br /> ** 5.1. '''serviceKey''' - integer. It represents the service key to be used when constructing an IDP for this SCF..<br /> ** 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.<br /> ** 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).<br /> ** 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.<br /> ** 5.5. '''addr''' - array. It specifies SS7 network addressing parameters. They only need be set for external SCFs. Parameters are usually set here are:<br /> *** '''CalledPartyAddress.route''' - string. It can be set to values: gt/ssn. It specifies how the SCCP address should be routed.<br /> *** '''CalledPartyAddress.ssn''' - integer. It's the SSN number in case of SSN routing.<br /> *** '''CalledPartyAddress.gt''' - string. GTT number digits for the SCF.<br /> *** '''CalledPartyAddress.gt.encoding''' - string. It specifies the encoding for the GT digits. It is usually set to ''bcd''.<br /> *** '''CalledPartyAddress.gt.translation''' - integer. It specifies the GT translation type. It is usually set to ''0''. <br /> *** '''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.<br /> *** '''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.<br /> *** '''CallingPartyAddress.route'''<br /> *** '''CalledPartyAddress.ssn'''<br /> *** '''CallingPartyAddress.gt'''<br /> *** '''CallingPartyAddress.gt.encoding'''<br /> *** '''CallingPartyAddress.gt.translation'''<br /> *** '''CallingPartyAddress.gt.plan'''<br /> *** '''CallingPartyAddress.gt.nature''' <br /> ** 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.<br /> ** 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.<br /> ** 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.<br /> ** 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.<br /> <br /> A working configuration for ''camel_proxy.php'' looks like this:<br /> <br /> <br /> $myServiceKey = "1"; <br /> <br /> $proxyName = "camelProxy"; <br /> <br /> /** <br /> * GTT number of this SCP <br /> */ <br /> $mynum = "8820003"; <br /> <br /> /** <br /> * Transaction timeout after inactivity <br /> */ <br /> $transTimeout = 180; <br /> <br /> /** <br /> * List of configured proxied SCFs <br /> * The following parameters must be configured, all are mandatory: <br /> * serviceKey - value with which the IDP serviceKey should be rewritten <br /> * dp - detection point that should match the one received in IDP in order to contact this SCF <br /> * priority - priority in handling messages from SSF <br /> * errorFatal - whether or not an error or reject component from the SCF should terminate the whole proxy dialoque <br /> * addr - SS7 network addressing parameters. <br /> * local - whether the SCF is local (a local application) or external (it passes through the SS7 network to reach it) <br /> * handles - lists operation received from the SSF that are accepted by this SCF. <br /> * NOTE: Except ERBE, which is sent to all SCFs that match the reported DP, all operations that are handled by a <br /> * SCF should be listed, otherwise the proxy will report to the SSF an error. <br /> * context - if set, rewrites the application context for the dialog established with the SCF, otherwise leaves it as received <br /> * waitTime - time, in seconds, to wait for a result from a SCF while being in Waiting For Instructions state, after which the dialogue <br /> * is aborted. <br /> */ <br /> $scfs = array( <br /> "crbt-scp" => array( <br /> "serviceKey" => 2, <br /> "dp" => "termAttemptAuthorized", <br /> "priority" => 1, <br /> "errorFatal" => false, <br /> "addr" => array(), <br /> "local" => true, <br /> "handles" => array(), <br /> "context" => "", <br /> "waitTime" => 3, <br /> ),<br /> "pps-scp" => array( <br /> "serviceKey" => 99, <br /> "dp" => "termAttemptAuthorized", <br /> "priority" => 2, <br /> "errorFatal" => true, <br /> "addr" => array("CalledPartyAddress.gt" => "8820007", <br /> "CalledPartyAddress.route" => "gt", <br /> "CalledPartyAddress.gt.encoding" => "bcd", <br /> "CalledPartyAddress.gt.tt" => "0", <br /> "CalledPartyAddress.gt.np" => "isdn", <br /> "CalledPartyAddress.gt.nature" => "international", <br /> "CallingPartyAddress.gt" => "8820003", <br /> "CallingPartyAddress.route" => "gt", <br /> "CallingPartyAddress.gt.encoding" => "bcd", <br /> "CallingPartyAddress.gt.tt" => "0", <br /> "CallingPartyAddress.gt.np" => "isdn", <br /> "CallingPartyAddress.gt.nature" => "international", <br /> ), <br /> "local" => false, <br /> "handles" => array("applyChargingReport"), <br /> "context" => "", <br /> "waitTime" => 3, <br /> ), <br /> );<br /> <br /> ===Yate side===<br /> <br /> On the Yate side, the ''camel_map'' module must be configured through ''camel_map.conf''. <br /> <br /> In order for the module to ensure communication with the SSF, a section named <tt>[local name_of_proxy]</tt> must be configured:<br /> <br /> [local proxyName] - what comes after ''local'' will be the name of the application<br /> ;enable=no -- enable this application<br /> translator=scp - which translator should be used. A section named [tcap translatorValue] should be present in the config file.<br /> capabilities=Camel - capabilities supported by this application. CAMEL translator has only one capability and that is ''Camel''.<br /> export_xml_as=both - how to export the XML part: string, object or both?<br /> <br /> A <tt>[tcap name]</tt> section must be configured also. A section looks like this:<br /> <br /> [tcap scp] -- what comes after ''tcap'' will be the name of the translator<br /> ;enable=no -- enable this translator<br /> 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''<br /> host=0.0.0.0 -- address on which to listen for incoming applications<br /> port=0 -- port on which to listen for incoming applications. 0 means that will not build a listener, as the proxy works on messages.<br /> type=CAMEL -- type of translator (MAP/CAMEL). For the intended case, CAMEL should be set<br /> print-messages=true -- whether or not to print TCAP and XML messages in the logs<br /> add-encoding=false -- whether to add encoding attribute to data translated to XML<br /> <br /> <br /> For an external proxied SCF, additional <tt>[local scfName]</tt> and <tt>[tcap name]</tt> sections must be configured:<br /> <br /> [tcap msc]<br /> tcap=tcap-msc<br /> host=0.0.0.0<br /> port=0<br /> type=CAMEL<br /> print-messages=true<br /> add-encoding=false<br /> <br /> [local ext-scp]<br /> ;enable=no<br /> translator=msc<br /> capabilities=Camel<br /> export_xml_as=both<br /> <br /> <br /> '''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.<br /> <br /> ==Proxy Behaviour==<br /> <br /> Bellow, the behaviour of the CAMEL proxy implemented in ''camel_proxy.php'' is described.<br /> <br /> ===General===<br /> <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.<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 /> <br /> The main characteristics of the proxy behaviour are:<br /> <br /> * 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.<br /> <br /> * 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.<br /> <br /> * Invoke components from SCFs will be sent to the SSF and the proxy will keep track to which SCF each component belongs to.<br /> <br /> * Result and ReturnError components from the SSF will be passed by the proxy to the SCF that initially sent it.<br /> <br /> * 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:<br /> <br /> SSF Proxy SCF 1 SCF 2<br /> |------- Invoke 1 ----------->|WFI | | <br /> | |----- Invoke 1a ------>|WFI | <br /> | |<---- Invoke 2a -------|WFI |<br /> |<------ Invoke 2a -----------|WFI | |<br /> |------- Result 2a ---------->|WFI | |<br /> | |----- Result 2a ------>|WFI |<br /> | |<---- Invoke 3a CWA ---|MON |<br /> | |------------------------------ Invoke 1b --------->|WFI<br /> | |<----------------------------- Invoke 2b ----------|WFI<br /> | |<----------------------------- Invoke CONT 3b CONT-|MON<br /> |<------ Invoke 2b -----------| | |<br /> |<------ Invoke 3a CWA -------|MON | |<br /> | | | |<br /> | | | |<br /> |------- Invoke 4 ----------->|MON | |<br /> | |------ Invoke 4a ----->|MON |<br /> | |------------------------------ Invoke 4b --------->|MON<br /> <br /> * 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.<br /> * 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.<br /> * 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.<br /> * 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.<br /> <br /> ===InitialDP handling===<br /> <br /> The initialDP operation has special handling. Upon receiving this operation from the SSF, the proxy will take the following steps:<br /> * it will check for presence of the ''serviceKey'' parameter. If missing, it will reject the operation and end the dialogue with the SSF.<br /> * 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.<br /> * 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.<br /> * 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.<br /> * 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. <br /> <br /> ===RequestReportBCSM and EventReportBCSM handling===<br /> <br /> <br /> 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. <br /> 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.<br /> <br /> In order to prevent that, proxy does the following:<br /> * the proxy keeps track about how DPs were armed for the dialogue with the SSF, and also for the dialogues with the SCFs.<br /> * 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:<br /> ** 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.<br /> ** 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.<br /> ** 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.<br /> ** 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.<br /> * 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.<br /> <br /> '''Question:''' It may turn that SCF requested ''notify'', but got ''interrupted'' EventReportBCSM, right? Is it OK? <br/><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.<br /> <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/><br /> '''Answer:''' Yes.<br /> <br /> '''Question:''' Are CRBT scripts ready for this scenario?<br/><br /> '''Answer:''' Yes, the CRBT script when handling DPs is prepared to handle such a situation.<br /> <br /> '''Question:''' It seems better to issue CONT by proxy and change ''interrupted'' to what was originally requested by certain SCF. Not sure.<br/><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.<br /> <br /> ===Multiple Continue/ContinueWithArgument handling===<br /> <br /> <br /> 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.<br /> For that, the proxy will do the following:<br /> * 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.<br /> * if in the message there are only CONT invocations, only the last one is left, the other ones are removed before sending.<br /> * 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.<br /> * 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.<br /> <br /> '''Question:''' how does SSF handle multiple CWA?<br/><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.<br /> <br /> ===Leg ID and DP rewriting===<br /> <br /> 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:<br /> * 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.<br /> * 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.<br /> * 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)<br /> * 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.<br /> * leg rewriting handling also aplies to ApplyCharging and ApplyChargingReport operations.<br /> <br /> 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.</div>

Monica https://ss7api.null.ro/index.php/CAMEL_proxy CAMEL proxy 2013-10-28T11:46:12Z

<p>Monica: /* Multiple Continue/ContinueWithArgument handling */</p> <hr /> <div>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.<br /> <br /> The main purpose is to be able to provide CRBT and PPS (PrePaid Service) facilities in parallel.<br /> <br /> The layout for such a scenario will look like this:<br /> <br /> [[File:CamelProxy.png]]<br /> <br /> 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.<br /> The proxy keeps an evidence of these multiple invocations and aggregates them into a single, valid dialogue with the invoking SSP.<br /> <br /> ==Camel Proxy Module Configuration==<br /> <br /> The configuration file is camel_bcsm_proxy.conf<br /> <br /> ===Module configuration===<br /> <br /> ===='general' section====<br /> <br /> '''application''': Application parameter in camel messages sent/handled for SSF dialogs.<br/><br /> This parameter is required and is not applied on reload (can't be changed after module starts).<br/><br /> <br/><br /> '''gt''': Global Title to be set in the first message sent in the SSF dialog.<br/><br /> This parameter is applied on reload.<br/><br /> TCAP address parameters to be set in the first message sent back to SSF can also be set using '''addr.''' prefix.<br/><br /> E.g. GT can be set as '''addr.CallingPartyAddress.gt''' along with other parameters like number nature '''addr.CallingPartyAddress.nature'''.<br/><br /> Setting the GT without other parameters is the same as:<br/><br /> addr.CallingPartyAddress.gt=[GT set]<br/><br /> addr.CallingPartyAddress.route=gt<br/><br /> addr.CallingPartyAddress.gt.encoding=bcd<br/><br /> addr.CallingPartyAddress.gt.translation=0<br/><br /> addr.CallingPartyAddress.gt.plan=isdn<br/><br /> addr.CallingPartyAddress.gt.nature=international<br/><br /> <br/><br /> '''servicekey''': CAMEL serviceKey to check when in received initialDP and set when forwarding them to SCFs.<br/><br /> Allowed interval: 0..2147483647.<br/><br /> Defaults to 0 if missing or invalid.<br/><br /> This parameter is applied on reload for new dialogs only.<br/><br /> <br/><br /> '''query_scf''': Boolean value indicating whether to query for proxied SCFs update when processing initialDP.<br/><br /> Is enabled a 'scf.query' message will be enqueued and the module will wait for a 'scf.response' message to continue IDP processing.<br/><br /> Defaults to no.<br/><br /> <br/><br /> '''print_msg''': boolean/string: Print sent/received messages to output if debug level is at least 9.<br/><br /> Allowed values are boolean values or 'verbose' string.<br/><br /> If verbose is specified, the message will be dumped on output.<br/><br /> Defaults to no.<br/><br /> <br/><br /> '''print_xml''': boolean/string: Print sent/received XML data to output if debug level is at least 9.<br/><br /> This parameter is ignored if print_msg is disabled.<br/><br /> Allowed values are boolean values or 'verbose' string.<br/><br /> If verbose is specified, XML elements' children, attributes or text will be shown on separate lines.<br/><br /> Defaults to no.<br/><br /> <br/><br /> '''idp_calling_required''': boolean: Calling party number is required (non empty) in initialDP.<br/><br /> Default to yes.<br/><br /> <br/><br /> '''idp_called_required''': boolean: Called party number is required (non empty) in initialDP.<br/><br /> Default to yes.<br/><br /> <br/><br /> '''dispatcher_maxthreads''': integer: Maximum number of message dispatch threads to use.<br/><br /> Set to 0 to enqueue messages using yate engine.<br/><br /> Defaults to 0.<br/><br /> 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).<br/><br /> <br/><br /> ====Proxied SCF section(s)====<br /> <br /> '''enable''': boolean: Enable the SCF.<br/><br /> Defaults to yes.<br/><br /> <br/><br /> '''priority''': integer: Priority in handling messages from SSF.<br/><br /> Defaults to 0.<br/><br /> <br/><br /> '''servicekey''': integer: Value with which the IDP serviceKey should be rewritten.<br/><br /> Allowed interval: 0..2147483647.<br/><br /> Defaults to SSF service key set in 'general' section.<br/><br /> <br/><br /> '''dp''': string: Comma separated list of detection points that should match the one received in IDP in order to contact this SCF.<br/><br /> Items may be DP value or name.<br/><br /> Defaults to termAttemptAuthorized if empty or all DPs are invalid.<br/><br /> <br/><br /> '''endfatal''': boolean: Indicate whether or not terminate the proxy dialog when this dialog ends.<br/><br /> Defaults to no.<br/><br /> <br/><br /> '''errorfatal''': boolean: Indicate whether or not an error or reject component from the SCF should terminate the whole proxy dialog.<br/><br /> Defaults to no.<br/><br /> <br/><br /> '''local''': boolean: The SCF is local (a local application) or external (it passes through the SS7 network to reach it).<br/><br /> Defaults to no (external application).<br/><br /> <br/><br /> '''instances''': integer: Number of local application instances.<br/><br /> This parameter is ignored for non local SCFs.<br/><br /> If non 0 it must be set to a value greater then 1.<br/><br /> Defaults to 0.<br/><br /> If non 0 the module will build the required number of SCFs and will pick them using a round-robin algorithm.<br/><br /> Each application's name will be built from SCF application name concatenated with instance suffix startting from 1.<br/><br /> E.g.:<br /> <br /> [proxy SCP]<br /> instances=2<br /> <br /> Will build 2 applications: SCP1 and SCP2.<br/><br /> <br/><br /> '''handles''': string: Comma separated list of operations received from the SSF accepted by this SCF.<br/><br /> 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.<br/><br /> <br/><br /> '''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.<br/><br /> Defaults to 3000.<br/><br /> Minimum allowed value is 1000.<br/><br /> <br/><br /> All other parameters starting with 'addr.' prefix will be put in dialog begin message sent for this SCF.<br/><br /> They should be set for non local SCFs.<br/><br /> Parameters:<br /> * '''addr.CalledPartyAddress.route''' - string. It can be set to values: gt/ssn. It specifies how the SCCP address should be routed.<br /> * '''addr.CalledPartyAddress.ssn''' - integer. It's the SSN number in case of SSN routing.<br /> * '''addr.CalledPartyAddress.gt''' - string. GTT number digits for the SCF.<br /> * '''addr.CalledPartyAddress.gt.encoding''' - string. It specifies the encoding for the GT digits. It is usually set to bcd.<br /> * '''addr.CalledPartyAddress.gt.tt''' - integer. It specifies the GT translation type. It is usually set to 0.<br /> * '''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.<br /> * '''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.<br /> * '''addr.CallingPartyAddress.route'''<br /> * '''addr.CalledPartyAddress.ssn'''<br /> * '''addr.CallingPartyAddress.gt'''<br /> * '''addr.CallingPartyAddress.gt.encoding'''<br /> * '''addr.CallingPartyAddress.gt.tt'''<br /> * '''addr.CallingPartyAddress.gt.np'''<br /> * '''addr.CallingPartyAddress.gt.nature''' <br /> <br /> ====Example====<br /> <br /> [general]<br /> application=camelProxy<br /> servicekey=1<br /> gt=8820003<br /> <br /> [proxy crbt-scp]<br /> servicekey=2<br /> local=true<br /> <br /> [proxy pps-scp]<br /> servicekey=99<br /> priority=2<br /> errorfatal=true<br /> handles=applyChargingReport<br /> addr.CalledPartyAddress.gt=8820007<br /> addr.CalledPartyAddress.route=gt<br /> addr.CalledPartyAddress.gt.encoding=bcd<br /> addr.CalledPartyAddress.gt.tt=0<br /> addr.CalledPartyAddress.gt.np=isdn<br /> addr.CalledPartyAddress.gt.nature=international<br /> addr.CallingPartyAddress.gt=8820003<br /> addr.CallingPartyAddress.route=gt<br /> addr.CallingPartyAddress.gt.encoding=bcd<br /> addr.CallingPartyAddress.gt.tt=0<br /> addr.CallingPartyAddress.gt.np=isdn<br /> addr.CallingPartyAddress.gt.nature=international<br /> <br /> <br /> === camel_map configuration ===<br /> <br /> [local camelProxy]<br /> translator=scp_proxy<br /> capabilities=Camel<br /> <br /> [tcap scp_proxy]<br /> type=CAMEL<br /> tcap=tcap_msc<br /> port=0<br /> <br /> [local pps-scp]<br /> translator=scp_pps<br /> capabilities=Camel<br /> <br /> [tcap scp_pps]<br /> type=CAMEL<br /> tcap=tcap_pps<br /> port=0<br /> <br /> ===camel_bcsm_proxy.conf.sample===<br /> <br /> ; NOTE: This module is not loaded automatically, it needs a line in yate.conf:<br /> ; [postload]<br /> ; ${modulepath}/sig/camel_bcsm_proxy${modsuffix}=yes<br /> <br /> [general]<br /> ; Unless explicitly specified, all parameters are applied on reload for new<br /> ; dialogs only<br /> ; All parameters starting with 'addr.' prefix will be put in the first message sent to SSF<br /> <br /> ; application: string: Application parameter in camel messages sent by the module<br /> ; This parameter is required<br /> ; This parameter is not applied on reload<br /> ;application=<br /> <br /> ; gt: string: Global Title to be set in the first message sent in the SSF dialog<br /> ; This parameter is applied on reload for new dialogs only<br /> ; If non empty other calling party address parameters will be set to default values<br /> ; This parameter can be overriden by addr.CallingPartyAddress.gt parameter<br /> ;gt=<br /> <br /> ; servicekey: integer: CAMEL serviceKey to check in received initialDP messages and<br /> ; set when forwarding them to SCFs<br /> ; Allowed interval: 0..2147483647<br /> ; Defaults to 0 if missing or invalid<br /> ; This parameter is applied on reload for new dialogs only<br /> ;servicekey=0<br /> <br /> ; query_scf: boolean: Query for proxied SCFs update when processing initialDP<br /> ; Is enabled a 'scf.query' message will be enqueued and the module will wait<br /> ; for a 'scf.response' message to continue IDP processing<br /> ; The response must return the list of SCFs to proxy<br /> ; The list may be shorter then configured SCFs<br /> ; New SCFs, other then configured ones, will be ignored<br /> ; The following SCF parameters can be overridden: priority, servicekey, errorfatal,<br /> ; handles, waittime and all parameters starting with 'addr.' prefix<br /> ; Defaults to no<br /> ;query_scf=no<br /> <br /> ; component_ttl: integer: Component time to live in milliseconds<br /> ; Minimum allowed value is 1000<br /> ; Defaults to 15000<br /> ;component_ttl=15000<br /> <br /> ; dialog_idle_ttl: integer: Dialog idle (nothing sent/received) time to live in milliseconds<br /> ; Minimum allowed value is 1000<br /> ; It can be set to 0 to keep it alive until the remote party terminates the dialog<br /> ; Defaults to 5000<br /> ;dialog_idle_ttl=5000<br /> <br /> ; dialog_ended_ttl: integer: Ended dialog time to live in milliseconds<br /> ; Minimum allowed value is 1000.<br /> ; It can be set to 0 to remove the dialog after termination<br /> ; Defaults to 0<br /> ;dialog_ended_ttl=0<br /> <br /> ; export_xml_as: string: Specify in which way the XML will be passed along into<br /> ; Yate messages<br /> ; Allowed values are:<br /> ; - string: pass the XML as a string<br /> ; - object: pass the XML as an object<br /> ; - both: pass the XML as a string and object<br /> ; Defaults to object<br /> ;export_xml_as=object<br /> <br /> ; print_msg: boolean/string: Print sent/received messages to output if debug<br /> ; level is at least 9<br /> ; Allowed values are boolean values or 'verbose' string<br /> ; If verbose is specified, the message will be dumped on output<br /> ; Defaults to no<br /> ;print_msg=no<br /> <br /> ; print_xml: boolean/string: Print sent/received XML data to output if debug<br /> ; level is at least 9<br /> ; This parameter is ignored if print_msg is disabled<br /> ; Allowed values are boolean values or 'verbose' string<br /> ; If verbose is specified, XML elements' children, attributes or text will be<br /> ; shown on separate lines<br /> ; Defaults to no<br /> ;print_xml=no<br /> <br /> ; idp_calling_required: boolean: Calling party number is required (non empty) in initialDP<br /> ; Default to yes<br /> ;idp_calling_required=yes<br /> <br /> ; idp_called_required: boolean: Called party number is required (non empty) in initialDP<br /> ; Default to yes<br /> ;idp_called_required=yes<br /> <br /> ; dispatcher_maxthreads: integer: Maximum number of message dispatch threads to use<br /> ; Set to 0 to enqueue messages using yate engine<br /> ; Defaults to 0<br /> ; When reloaded it can't be set to 0 (e.g. once set to a non 0 value it can be changed to<br /> ; non 0 values only)<br /> ;dispatcher_maxthreads=0<br /> <br /> ;dispatcher_priority: string: Default priority of message dispatch threads<br /> ; Can be one of: lowest, low, normal, high, highest<br /> ; High priorities need superuser privileges on POSIX operating systems<br /> ; Low priorities are not recommended except for debugging<br /> ; Defaults to 'normal'<br /> ; This parameter is applied on reload for new threads only<br /> ;dispatcher_priority=normal<br /> <br /> <br /> ;[proxy appname]<br /> ; This section configures a proxied SCF<br /> ; 'appname' is the application name to be used for the SCF<br /> <br /> ; enable: boolean: Enable the SCF<br /> ; Defaults to yes<br /> ;enable=yes<br /> <br /> ; priority: integer: Priority in handling messages from SSF<br /> ; Defaults to 0<br /> ;priority=0<br /> <br /> ; servicekey: integer: Value with which the IDP serviceKey should be rewritten<br /> ; Allowed interval: 0..2147483647<br /> ; Defaults to SSF service key set in 'general' section<br /> ;servicekey=<br /> <br /> ; dp: string: Comma separated list of detection points that should match the one received in IDP<br /> ; in order to contact this SCF<br /> ; Items may be DP value or name<br /> ; Defaults to termAttemptAuthorized if empty or all DPs are invalid<br /> ;dp=termAttemptAuthorized<br /> <br /> ; endfatal: boolean: Indicate whether or not terminate the proxy dialog when this dialog ends<br /> ; Defaults to no<br /> ;endfatal=no<br /> <br /> ; errorfatal: boolean: Indicate whether or not an error or reject component from<br /> ; the SCF should terminate the whole proxy dialog<br /> ; Defaults to no<br /> ;errorfatal=no<br /> <br /> ; local: boolean: The SCF is local (a local application) or external (it passes<br /> ; through the SS7 network to reach it)<br /> ; Defaults to no (external application)<br /> ;local=no<br /> <br /> ; instances: integer: Number of local application instances<br /> ; If non 0 the module will build the required number of SCFs and will pick them using a<br /> ; round-robin algorithm<br /> ; Each application's name will be built from SCF application name concatenated with instance<br /> ; suffix startting from 1<br /> ; E.g.<br /> ; [proxy SCP]<br /> ; instances=2<br /> ; Will build 2 applications: SCP1 and SCP2<br /> ; This parameter is ignored for non local SCFs<br /> ; If non 0 it must be set to a value greater then 1<br /> ; Defaults to 0<br /> ;instance=<br /> <br /> ; handles: string: Comma separated list of operations received from the SSF<br /> ; accepted by this SCF<br /> ; NOTE: Except ERB (Event Report BCSM), which is sent to all SCFs that match the reported DP,<br /> ; all operations that are handled by a SCF should be listed, otherwise the<br /> ; proxy will report to the SSF an error<br /> ;handles=<br /> <br /> ; waittime: integer: Time, in miliseconds, to wait for a result from a SCF<br /> ; while being in Waiting For Instructions state, after which the dialog<br /> ; is aborted<br /> ; Defaults to 3000<br /> ; Minimum allowed value is 1000<br /> ;waittime=3000<br /> <br /> ; All other parameters starting with 'addr.' prefix will be put in dialog begin<br /> ; message sent for this SCF<br /> ; E.g. addr.CalledPartyAddress.route=gt will be put as CalledPartyAddress.route=gt<br /> <br /> ==Proxy Module Test==<br /> This chapter describes how the Camel Proxy module was tested.<br /> <br /> The purpose of the test was to check if the Camel BCSM Proxy module can handle 100CPS.<br /> <br /> The machine used was a Dual Intel Xeon E5620 (Quad Core with HT) = 16CPUs, 32GB RAM with CentOS 6.2<br /> <br /> The setup was:<br/><br /> Yate1 - Call generator, sending calls to Yate3 using SIP<br/><br /> Yate2 - Call generator, sending calls to Yate4 using SIP<br/><br /> Yate3 - Call handling, send initialDP to Yate5 (Proxy)<br/><br /> Yate4 - Call handling, send initialDP to Yate5 (Proxy)<br/><br /> Yate5 - Camel BCSM Proxy<br/><br /> Yate6 - CRBT script<br/><br /> Yate7 - PPS script<br/><br /> Yate8 - PPS script<br /> <br /> <br /> SIP M2PA link M2PA links<br /> Yate1 ---------> Yate3 ------------| |-----------> Yate6 (CRBT)<br /> | |<br /> |-> Yate5 |-----------> Yate7 (PPS)<br /> | |<br /> SIP M2PA link | |-----------> Yate8 (PPS)<br /> Yate2 ---------> Yate4 ------------| <br /> <br /> <br /> '''NOTES:'''<br /> * The sum of both call generators was 110CPS.<br /> * During test top reported ~250%CPU for Proxy.<br /> * All yate instances were running on the same machine.<br /> * 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.<br /> <br /> How success was checked:<br /> * On call generators all calls were answered<br /> * 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')<br /> * On Proxy instance (Yate5) there were no timeouts (this would indicate a SCF is not responding withing default 3 seconds interval)<br /> <br /> ==Configuration==<br /> <br /> ===Script side===<br /> <br /> Configuration of the "camel_proxy.php" script is done through ''config_proxy.php''. This allows setting the following parameters:<br /> <br /> * 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.<br /> <br /> * 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.<br /> <br /> * 3. '''$mynum''' - string. GTT number assigned to this SCP. <br /> <br /> * 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.<br /> <br /> * 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:<br /> ** 5.1. '''serviceKey''' - integer. It represents the service key to be used when constructing an IDP for this SCF..<br /> ** 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.<br /> ** 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).<br /> ** 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.<br /> ** 5.5. '''addr''' - array. It specifies SS7 network addressing parameters. They only need be set for external SCFs. Parameters are usually set here are:<br /> *** '''CalledPartyAddress.route''' - string. It can be set to values: gt/ssn. It specifies how the SCCP address should be routed.<br /> *** '''CalledPartyAddress.ssn''' - integer. It's the SSN number in case of SSN routing.<br /> *** '''CalledPartyAddress.gt''' - string. GTT number digits for the SCF.<br /> *** '''CalledPartyAddress.gt.encoding''' - string. It specifies the encoding for the GT digits. It is usually set to ''bcd''.<br /> *** '''CalledPartyAddress.gt.translation''' - integer. It specifies the GT translation type. It is usually set to ''0''. <br /> *** '''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.<br /> *** '''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.<br /> *** '''CallingPartyAddress.route'''<br /> *** '''CalledPartyAddress.ssn'''<br /> *** '''CallingPartyAddress.gt'''<br /> *** '''CallingPartyAddress.gt.encoding'''<br /> *** '''CallingPartyAddress.gt.translation'''<br /> *** '''CallingPartyAddress.gt.plan'''<br /> *** '''CallingPartyAddress.gt.nature''' <br /> ** 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.<br /> ** 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.<br /> ** 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.<br /> ** 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.<br /> <br /> A working configuration for ''camel_proxy.php'' looks like this:<br /> <br /> <br /> $myServiceKey = "1"; <br /> <br /> $proxyName = "camelProxy"; <br /> <br /> /** <br /> * GTT number of this SCP <br /> */ <br /> $mynum = "8820003"; <br /> <br /> /** <br /> * Transaction timeout after inactivity <br /> */ <br /> $transTimeout = 180; <br /> <br /> /** <br /> * List of configured proxied SCFs <br /> * The following parameters must be configured, all are mandatory: <br /> * serviceKey - value with which the IDP serviceKey should be rewritten <br /> * dp - detection point that should match the one received in IDP in order to contact this SCF <br /> * priority - priority in handling messages from SSF <br /> * errorFatal - whether or not an error or reject component from the SCF should terminate the whole proxy dialoque <br /> * addr - SS7 network addressing parameters. <br /> * local - whether the SCF is local (a local application) or external (it passes through the SS7 network to reach it) <br /> * handles - lists operation received from the SSF that are accepted by this SCF. <br /> * NOTE: Except ERBE, which is sent to all SCFs that match the reported DP, all operations that are handled by a <br /> * SCF should be listed, otherwise the proxy will report to the SSF an error. <br /> * context - if set, rewrites the application context for the dialog established with the SCF, otherwise leaves it as received <br /> * waitTime - time, in seconds, to wait for a result from a SCF while being in Waiting For Instructions state, after which the dialogue <br /> * is aborted. <br /> */ <br /> $scfs = array( <br /> "crbt-scp" => array( <br /> "serviceKey" => 2, <br /> "dp" => "termAttemptAuthorized", <br /> "priority" => 1, <br /> "errorFatal" => false, <br /> "addr" => array(), <br /> "local" => true, <br /> "handles" => array(), <br /> "context" => "", <br /> "waitTime" => 3, <br /> ),<br /> "pps-scp" => array( <br /> "serviceKey" => 99, <br /> "dp" => "termAttemptAuthorized", <br /> "priority" => 2, <br /> "errorFatal" => true, <br /> "addr" => array("CalledPartyAddress.gt" => "8820007", <br /> "CalledPartyAddress.route" => "gt", <br /> "CalledPartyAddress.gt.encoding" => "bcd", <br /> "CalledPartyAddress.gt.tt" => "0", <br /> "CalledPartyAddress.gt.np" => "isdn", <br /> "CalledPartyAddress.gt.nature" => "international", <br /> "CallingPartyAddress.gt" => "8820003", <br /> "CallingPartyAddress.route" => "gt", <br /> "CallingPartyAddress.gt.encoding" => "bcd", <br /> "CallingPartyAddress.gt.tt" => "0", <br /> "CallingPartyAddress.gt.np" => "isdn", <br /> "CallingPartyAddress.gt.nature" => "international", <br /> ), <br /> "local" => false, <br /> "handles" => array("applyChargingReport"), <br /> "context" => "", <br /> "waitTime" => 3, <br /> ), <br /> );<br /> <br /> ===Yate side===<br /> <br /> On the Yate side, the ''camel_map'' module must be configured through ''camel_map.conf''. <br /> <br /> In order for the module to ensure communication with the SSF, a section named <tt>[local name_of_proxy]</tt> must be configured:<br /> <br /> [local proxyName] - what comes after ''local'' will be the name of the application<br /> ;enable=no -- enable this application<br /> translator=scp - which translator should be used. A section named [tcap translatorValue] should be present in the config file.<br /> capabilities=Camel - capabilities supported by this application. CAMEL translator has only one capability and that is ''Camel''.<br /> export_xml_as=both - how to export the XML part: string, object or both?<br /> <br /> A <tt>[tcap name]</tt> section must be configured also. A section looks like this:<br /> <br /> [tcap scp] -- what comes after ''tcap'' will be the name of the translator<br /> ;enable=no -- enable this translator<br /> 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''<br /> host=0.0.0.0 -- address on which to listen for incoming applications<br /> port=0 -- port on which to listen for incoming applications. 0 means that will not build a listener, as the proxy works on messages.<br /> type=CAMEL -- type of translator (MAP/CAMEL). For the intended case, CAMEL should be set<br /> print-messages=true -- whether or not to print TCAP and XML messages in the logs<br /> add-encoding=false -- whether to add encoding attribute to data translated to XML<br /> <br /> <br /> For an external proxied SCF, additional <tt>[local scfName]</tt> and <tt>[tcap name]</tt> sections must be configured:<br /> <br /> [tcap msc]<br /> tcap=tcap-msc<br /> host=0.0.0.0<br /> port=0<br /> type=CAMEL<br /> print-messages=true<br /> add-encoding=false<br /> <br /> [local ext-scp]<br /> ;enable=no<br /> translator=msc<br /> capabilities=Camel<br /> export_xml_as=both<br /> <br /> <br /> '''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.<br /> <br /> ==Proxy Behaviour==<br /> <br /> Bellow, the behaviour of the CAMEL proxy implemented in ''camel_proxy.php'' is described.<br /> <br /> ===General===<br /> <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.<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 /> <br /> The main characteristics of the proxy behaviour are:<br /> * 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.<br /> * 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.<br /> * Invoke components from SCFs will be sent to the SSF and the proxy will keep track to which SCF each component belongs to.<br /> * Result and ReturnError components from the SSF will be passed by the proxy to the SCF that initially sent it.<br /> * 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:<br /> <br /> SSF Proxy SCF 1 SCF 2<br /> |------- Invoke 1 ----------->|WFI | | <br /> | |----- Invoke 1a ------>|WFI | <br /> | |<---- Invoke 2a -------|WFI |<br /> |<------ Invoke 2a -----------|WFI | |<br /> |------- Result 2a ---------->|WFI | |<br /> | |----- Result 2a ------>|WFI |<br /> | |<---- Invoke 3a CWA ---|MON |<br /> | |------------------------------ Invoke 1b --------->|WFI<br /> | |<----------------------------- Invoke 2b ----------|WFI<br /> | |<----------------------------- Invoke CONT 3b CONT-|MON<br /> |<------ Invoke 2b -----------| | |<br /> |<------ Invoke 3a CWA -------|MON | |<br /> | | | |<br /> | | | |<br /> |------- Invoke 4 ----------->|MON | |<br /> | |------ Invoke 4a ----->|MON |<br /> | |------------------------------ Invoke 4b --------->|MON<br /> <br /> * 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.<br /> * 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.<br /> * 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.<br /> * 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.<br /> <br /> ===InitialDP handling===<br /> <br /> The initialDP operation has special handling. Upon receiving this operation from the SSF, the proxy will take the following steps:<br /> * it will check for presence of the ''serviceKey'' parameter. If missing, it will reject the operation and end the dialogue with the SSF.<br /> * 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.<br /> * 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.<br /> * 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.<br /> * 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. <br /> <br /> ===RequestReportBCSM and EventReportBCSM handling===<br /> <br /> <br /> 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. <br /> 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.<br /> <br /> In order to prevent that, proxy does the following:<br /> * the proxy keeps track about how DPs were armed for the dialogue with the SSF, and also for the dialogues with the SCFs.<br /> * 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:<br /> ** 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.<br /> ** 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.<br /> ** 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.<br /> ** 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.<br /> * 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.<br /> <br /> '''Question:''' It may turn that SCF requested ''notify'', but got ''interrupted'' EventReportBCSM, right? Is it OK? <br/><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.<br /> <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/><br /> '''Answer:''' Yes.<br /> <br /> '''Question:''' Are CRBT scripts ready for this scenario?<br/><br /> '''Answer:''' Yes, the CRBT script when handling DPs is prepared to handle such a situation.<br /> <br /> '''Question:''' It seems better to issue CONT by proxy and change ''interrupted'' to what was originally requested by certain SCF. Not sure.<br/><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.<br /> <br /> ===Multiple Continue/ContinueWithArgument handling===<br /> <br /> <br /> 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.<br /> For that, the proxy will do the following:<br /> * 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.<br /> * if in the message there are only CONT invocations, only the last one is left, the other ones are removed before sending.<br /> * 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.<br /> * 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.<br /> <br /> '''Question:''' how does SSF handle multiple CWA?<br/><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.<br /> <br /> ===Leg ID and DP rewriting===<br /> <br /> 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:<br /> * 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.<br /> * 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.<br /> * 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)<br /> * 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.<br /> * leg rewriting handling also aplies to ApplyCharging and ApplyChargingReport operations.<br /> <br /> 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.</div>

Monica https://ss7api.null.ro/index.php/CAMEL_proxy CAMEL proxy 2013-10-28T11:45:45Z

<p>Monica: /* RequestReportBCSM and EventReportBCSM handling */</p> <hr /> <div>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.<br /> <br /> The main purpose is to be able to provide CRBT and PPS (PrePaid Service) facilities in parallel.<br /> <br /> The layout for such a scenario will look like this:<br /> <br /> [[File:CamelProxy.png]]<br /> <br /> 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.<br /> The proxy keeps an evidence of these multiple invocations and aggregates them into a single, valid dialogue with the invoking SSP.<br /> <br /> ==Camel Proxy Module Configuration==<br /> <br /> The configuration file is camel_bcsm_proxy.conf<br /> <br /> ===Module configuration===<br /> <br /> ===='general' section====<br /> <br /> '''application''': Application parameter in camel messages sent/handled for SSF dialogs.<br/><br /> This parameter is required and is not applied on reload (can't be changed after module starts).<br/><br /> <br/><br /> '''gt''': Global Title to be set in the first message sent in the SSF dialog.<br/><br /> This parameter is applied on reload.<br/><br /> TCAP address parameters to be set in the first message sent back to SSF can also be set using '''addr.''' prefix.<br/><br /> E.g. GT can be set as '''addr.CallingPartyAddress.gt''' along with other parameters like number nature '''addr.CallingPartyAddress.nature'''.<br/><br /> Setting the GT without other parameters is the same as:<br/><br /> addr.CallingPartyAddress.gt=[GT set]<br/><br /> addr.CallingPartyAddress.route=gt<br/><br /> addr.CallingPartyAddress.gt.encoding=bcd<br/><br /> addr.CallingPartyAddress.gt.translation=0<br/><br /> addr.CallingPartyAddress.gt.plan=isdn<br/><br /> addr.CallingPartyAddress.gt.nature=international<br/><br /> <br/><br /> '''servicekey''': CAMEL serviceKey to check when in received initialDP and set when forwarding them to SCFs.<br/><br /> Allowed interval: 0..2147483647.<br/><br /> Defaults to 0 if missing or invalid.<br/><br /> This parameter is applied on reload for new dialogs only.<br/><br /> <br/><br /> '''query_scf''': Boolean value indicating whether to query for proxied SCFs update when processing initialDP.<br/><br /> Is enabled a 'scf.query' message will be enqueued and the module will wait for a 'scf.response' message to continue IDP processing.<br/><br /> Defaults to no.<br/><br /> <br/><br /> '''print_msg''': boolean/string: Print sent/received messages to output if debug level is at least 9.<br/><br /> Allowed values are boolean values or 'verbose' string.<br/><br /> If verbose is specified, the message will be dumped on output.<br/><br /> Defaults to no.<br/><br /> <br/><br /> '''print_xml''': boolean/string: Print sent/received XML data to output if debug level is at least 9.<br/><br /> This parameter is ignored if print_msg is disabled.<br/><br /> Allowed values are boolean values or 'verbose' string.<br/><br /> If verbose is specified, XML elements' children, attributes or text will be shown on separate lines.<br/><br /> Defaults to no.<br/><br /> <br/><br /> '''idp_calling_required''': boolean: Calling party number is required (non empty) in initialDP.<br/><br /> Default to yes.<br/><br /> <br/><br /> '''idp_called_required''': boolean: Called party number is required (non empty) in initialDP.<br/><br /> Default to yes.<br/><br /> <br/><br /> '''dispatcher_maxthreads''': integer: Maximum number of message dispatch threads to use.<br/><br /> Set to 0 to enqueue messages using yate engine.<br/><br /> Defaults to 0.<br/><br /> 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).<br/><br /> <br/><br /> ====Proxied SCF section(s)====<br /> <br /> '''enable''': boolean: Enable the SCF.<br/><br /> Defaults to yes.<br/><br /> <br/><br /> '''priority''': integer: Priority in handling messages from SSF.<br/><br /> Defaults to 0.<br/><br /> <br/><br /> '''servicekey''': integer: Value with which the IDP serviceKey should be rewritten.<br/><br /> Allowed interval: 0..2147483647.<br/><br /> Defaults to SSF service key set in 'general' section.<br/><br /> <br/><br /> '''dp''': string: Comma separated list of detection points that should match the one received in IDP in order to contact this SCF.<br/><br /> Items may be DP value or name.<br/><br /> Defaults to termAttemptAuthorized if empty or all DPs are invalid.<br/><br /> <br/><br /> '''endfatal''': boolean: Indicate whether or not terminate the proxy dialog when this dialog ends.<br/><br /> Defaults to no.<br/><br /> <br/><br /> '''errorfatal''': boolean: Indicate whether or not an error or reject component from the SCF should terminate the whole proxy dialog.<br/><br /> Defaults to no.<br/><br /> <br/><br /> '''local''': boolean: The SCF is local (a local application) or external (it passes through the SS7 network to reach it).<br/><br /> Defaults to no (external application).<br/><br /> <br/><br /> '''instances''': integer: Number of local application instances.<br/><br /> This parameter is ignored for non local SCFs.<br/><br /> If non 0 it must be set to a value greater then 1.<br/><br /> Defaults to 0.<br/><br /> If non 0 the module will build the required number of SCFs and will pick them using a round-robin algorithm.<br/><br /> Each application's name will be built from SCF application name concatenated with instance suffix startting from 1.<br/><br /> E.g.:<br /> <br /> [proxy SCP]<br /> instances=2<br /> <br /> Will build 2 applications: SCP1 and SCP2.<br/><br /> <br/><br /> '''handles''': string: Comma separated list of operations received from the SSF accepted by this SCF.<br/><br /> 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.<br/><br /> <br/><br /> '''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.<br/><br /> Defaults to 3000.<br/><br /> Minimum allowed value is 1000.<br/><br /> <br/><br /> All other parameters starting with 'addr.' prefix will be put in dialog begin message sent for this SCF.<br/><br /> They should be set for non local SCFs.<br/><br /> Parameters:<br /> * '''addr.CalledPartyAddress.route''' - string. It can be set to values: gt/ssn. It specifies how the SCCP address should be routed.<br /> * '''addr.CalledPartyAddress.ssn''' - integer. It's the SSN number in case of SSN routing.<br /> * '''addr.CalledPartyAddress.gt''' - string. GTT number digits for the SCF.<br /> * '''addr.CalledPartyAddress.gt.encoding''' - string. It specifies the encoding for the GT digits. It is usually set to bcd.<br /> * '''addr.CalledPartyAddress.gt.tt''' - integer. It specifies the GT translation type. It is usually set to 0.<br /> * '''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.<br /> * '''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.<br /> * '''addr.CallingPartyAddress.route'''<br /> * '''addr.CalledPartyAddress.ssn'''<br /> * '''addr.CallingPartyAddress.gt'''<br /> * '''addr.CallingPartyAddress.gt.encoding'''<br /> * '''addr.CallingPartyAddress.gt.tt'''<br /> * '''addr.CallingPartyAddress.gt.np'''<br /> * '''addr.CallingPartyAddress.gt.nature''' <br /> <br /> ====Example====<br /> <br /> [general]<br /> application=camelProxy<br /> servicekey=1<br /> gt=8820003<br /> <br /> [proxy crbt-scp]<br /> servicekey=2<br /> local=true<br /> <br /> [proxy pps-scp]<br /> servicekey=99<br /> priority=2<br /> errorfatal=true<br /> handles=applyChargingReport<br /> addr.CalledPartyAddress.gt=8820007<br /> addr.CalledPartyAddress.route=gt<br /> addr.CalledPartyAddress.gt.encoding=bcd<br /> addr.CalledPartyAddress.gt.tt=0<br /> addr.CalledPartyAddress.gt.np=isdn<br /> addr.CalledPartyAddress.gt.nature=international<br /> addr.CallingPartyAddress.gt=8820003<br /> addr.CallingPartyAddress.route=gt<br /> addr.CallingPartyAddress.gt.encoding=bcd<br /> addr.CallingPartyAddress.gt.tt=0<br /> addr.CallingPartyAddress.gt.np=isdn<br /> addr.CallingPartyAddress.gt.nature=international<br /> <br /> <br /> === camel_map configuration ===<br /> <br /> [local camelProxy]<br /> translator=scp_proxy<br /> capabilities=Camel<br /> <br /> [tcap scp_proxy]<br /> type=CAMEL<br /> tcap=tcap_msc<br /> port=0<br /> <br /> [local pps-scp]<br /> translator=scp_pps<br /> capabilities=Camel<br /> <br /> [tcap scp_pps]<br /> type=CAMEL<br /> tcap=tcap_pps<br /> port=0<br /> <br /> ===camel_bcsm_proxy.conf.sample===<br /> <br /> ; NOTE: This module is not loaded automatically, it needs a line in yate.conf:<br /> ; [postload]<br /> ; ${modulepath}/sig/camel_bcsm_proxy${modsuffix}=yes<br /> <br /> [general]<br /> ; Unless explicitly specified, all parameters are applied on reload for new<br /> ; dialogs only<br /> ; All parameters starting with 'addr.' prefix will be put in the first message sent to SSF<br /> <br /> ; application: string: Application parameter in camel messages sent by the module<br /> ; This parameter is required<br /> ; This parameter is not applied on reload<br /> ;application=<br /> <br /> ; gt: string: Global Title to be set in the first message sent in the SSF dialog<br /> ; This parameter is applied on reload for new dialogs only<br /> ; If non empty other calling party address parameters will be set to default values<br /> ; This parameter can be overriden by addr.CallingPartyAddress.gt parameter<br /> ;gt=<br /> <br /> ; servicekey: integer: CAMEL serviceKey to check in received initialDP messages and<br /> ; set when forwarding them to SCFs<br /> ; Allowed interval: 0..2147483647<br /> ; Defaults to 0 if missing or invalid<br /> ; This parameter is applied on reload for new dialogs only<br /> ;servicekey=0<br /> <br /> ; query_scf: boolean: Query for proxied SCFs update when processing initialDP<br /> ; Is enabled a 'scf.query' message will be enqueued and the module will wait<br /> ; for a 'scf.response' message to continue IDP processing<br /> ; The response must return the list of SCFs to proxy<br /> ; The list may be shorter then configured SCFs<br /> ; New SCFs, other then configured ones, will be ignored<br /> ; The following SCF parameters can be overridden: priority, servicekey, errorfatal,<br /> ; handles, waittime and all parameters starting with 'addr.' prefix<br /> ; Defaults to no<br /> ;query_scf=no<br /> <br /> ; component_ttl: integer: Component time to live in milliseconds<br /> ; Minimum allowed value is 1000<br /> ; Defaults to 15000<br /> ;component_ttl=15000<br /> <br /> ; dialog_idle_ttl: integer: Dialog idle (nothing sent/received) time to live in milliseconds<br /> ; Minimum allowed value is 1000<br /> ; It can be set to 0 to keep it alive until the remote party terminates the dialog<br /> ; Defaults to 5000<br /> ;dialog_idle_ttl=5000<br /> <br /> ; dialog_ended_ttl: integer: Ended dialog time to live in milliseconds<br /> ; Minimum allowed value is 1000.<br /> ; It can be set to 0 to remove the dialog after termination<br /> ; Defaults to 0<br /> ;dialog_ended_ttl=0<br /> <br /> ; export_xml_as: string: Specify in which way the XML will be passed along into<br /> ; Yate messages<br /> ; Allowed values are:<br /> ; - string: pass the XML as a string<br /> ; - object: pass the XML as an object<br /> ; - both: pass the XML as a string and object<br /> ; Defaults to object<br /> ;export_xml_as=object<br /> <br /> ; print_msg: boolean/string: Print sent/received messages to output if debug<br /> ; level is at least 9<br /> ; Allowed values are boolean values or 'verbose' string<br /> ; If verbose is specified, the message will be dumped on output<br /> ; Defaults to no<br /> ;print_msg=no<br /> <br /> ; print_xml: boolean/string: Print sent/received XML data to output if debug<br /> ; level is at least 9<br /> ; This parameter is ignored if print_msg is disabled<br /> ; Allowed values are boolean values or 'verbose' string<br /> ; If verbose is specified, XML elements' children, attributes or text will be<br /> ; shown on separate lines<br /> ; Defaults to no<br /> ;print_xml=no<br /> <br /> ; idp_calling_required: boolean: Calling party number is required (non empty) in initialDP<br /> ; Default to yes<br /> ;idp_calling_required=yes<br /> <br /> ; idp_called_required: boolean: Called party number is required (non empty) in initialDP<br /> ; Default to yes<br /> ;idp_called_required=yes<br /> <br /> ; dispatcher_maxthreads: integer: Maximum number of message dispatch threads to use<br /> ; Set to 0 to enqueue messages using yate engine<br /> ; Defaults to 0<br /> ; When reloaded it can't be set to 0 (e.g. once set to a non 0 value it can be changed to<br /> ; non 0 values only)<br /> ;dispatcher_maxthreads=0<br /> <br /> ;dispatcher_priority: string: Default priority of message dispatch threads<br /> ; Can be one of: lowest, low, normal, high, highest<br /> ; High priorities need superuser privileges on POSIX operating systems<br /> ; Low priorities are not recommended except for debugging<br /> ; Defaults to 'normal'<br /> ; This parameter is applied on reload for new threads only<br /> ;dispatcher_priority=normal<br /> <br /> <br /> ;[proxy appname]<br /> ; This section configures a proxied SCF<br /> ; 'appname' is the application name to be used for the SCF<br /> <br /> ; enable: boolean: Enable the SCF<br /> ; Defaults to yes<br /> ;enable=yes<br /> <br /> ; priority: integer: Priority in handling messages from SSF<br /> ; Defaults to 0<br /> ;priority=0<br /> <br /> ; servicekey: integer: Value with which the IDP serviceKey should be rewritten<br /> ; Allowed interval: 0..2147483647<br /> ; Defaults to SSF service key set in 'general' section<br /> ;servicekey=<br /> <br /> ; dp: string: Comma separated list of detection points that should match the one received in IDP<br /> ; in order to contact this SCF<br /> ; Items may be DP value or name<br /> ; Defaults to termAttemptAuthorized if empty or all DPs are invalid<br /> ;dp=termAttemptAuthorized<br /> <br /> ; endfatal: boolean: Indicate whether or not terminate the proxy dialog when this dialog ends<br /> ; Defaults to no<br /> ;endfatal=no<br /> <br /> ; errorfatal: boolean: Indicate whether or not an error or reject component from<br /> ; the SCF should terminate the whole proxy dialog<br /> ; Defaults to no<br /> ;errorfatal=no<br /> <br /> ; local: boolean: The SCF is local (a local application) or external (it passes<br /> ; through the SS7 network to reach it)<br /> ; Defaults to no (external application)<br /> ;local=no<br /> <br /> ; instances: integer: Number of local application instances<br /> ; If non 0 the module will build the required number of SCFs and will pick them using a<br /> ; round-robin algorithm<br /> ; Each application's name will be built from SCF application name concatenated with instance<br /> ; suffix startting from 1<br /> ; E.g.<br /> ; [proxy SCP]<br /> ; instances=2<br /> ; Will build 2 applications: SCP1 and SCP2<br /> ; This parameter is ignored for non local SCFs<br /> ; If non 0 it must be set to a value greater then 1<br /> ; Defaults to 0<br /> ;instance=<br /> <br /> ; handles: string: Comma separated list of operations received from the SSF<br /> ; accepted by this SCF<br /> ; NOTE: Except ERB (Event Report BCSM), which is sent to all SCFs that match the reported DP,<br /> ; all operations that are handled by a SCF should be listed, otherwise the<br /> ; proxy will report to the SSF an error<br /> ;handles=<br /> <br /> ; waittime: integer: Time, in miliseconds, to wait for a result from a SCF<br /> ; while being in Waiting For Instructions state, after which the dialog<br /> ; is aborted<br /> ; Defaults to 3000<br /> ; Minimum allowed value is 1000<br /> ;waittime=3000<br /> <br /> ; All other parameters starting with 'addr.' prefix will be put in dialog begin<br /> ; message sent for this SCF<br /> ; E.g. addr.CalledPartyAddress.route=gt will be put as CalledPartyAddress.route=gt<br /> <br /> ==Proxy Module Test==<br /> This chapter describes how the Camel Proxy module was tested.<br /> <br /> The purpose of the test was to check if the Camel BCSM Proxy module can handle 100CPS.<br /> <br /> The machine used was a Dual Intel Xeon E5620 (Quad Core with HT) = 16CPUs, 32GB RAM with CentOS 6.2<br /> <br /> The setup was:<br/><br /> Yate1 - Call generator, sending calls to Yate3 using SIP<br/><br /> Yate2 - Call generator, sending calls to Yate4 using SIP<br/><br /> Yate3 - Call handling, send initialDP to Yate5 (Proxy)<br/><br /> Yate4 - Call handling, send initialDP to Yate5 (Proxy)<br/><br /> Yate5 - Camel BCSM Proxy<br/><br /> Yate6 - CRBT script<br/><br /> Yate7 - PPS script<br/><br /> Yate8 - PPS script<br /> <br /> <br /> SIP M2PA link M2PA links<br /> Yate1 ---------> Yate3 ------------| |-----------> Yate6 (CRBT)<br /> | |<br /> |-> Yate5 |-----------> Yate7 (PPS)<br /> | |<br /> SIP M2PA link | |-----------> Yate8 (PPS)<br /> Yate2 ---------> Yate4 ------------| <br /> <br /> <br /> '''NOTES:'''<br /> * The sum of both call generators was 110CPS.<br /> * During test top reported ~250%CPU for Proxy.<br /> * All yate instances were running on the same machine.<br /> * 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.<br /> <br /> How success was checked:<br /> * On call generators all calls were answered<br /> * 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')<br /> * On Proxy instance (Yate5) there were no timeouts (this would indicate a SCF is not responding withing default 3 seconds interval)<br /> <br /> ==Configuration==<br /> <br /> ===Script side===<br /> <br /> Configuration of the "camel_proxy.php" script is done through ''config_proxy.php''. This allows setting the following parameters:<br /> <br /> * 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.<br /> <br /> * 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.<br /> <br /> * 3. '''$mynum''' - string. GTT number assigned to this SCP. <br /> <br /> * 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.<br /> <br /> * 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:<br /> ** 5.1. '''serviceKey''' - integer. It represents the service key to be used when constructing an IDP for this SCF..<br /> ** 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.<br /> ** 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).<br /> ** 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.<br /> ** 5.5. '''addr''' - array. It specifies SS7 network addressing parameters. They only need be set for external SCFs. Parameters are usually set here are:<br /> *** '''CalledPartyAddress.route''' - string. It can be set to values: gt/ssn. It specifies how the SCCP address should be routed.<br /> *** '''CalledPartyAddress.ssn''' - integer. It's the SSN number in case of SSN routing.<br /> *** '''CalledPartyAddress.gt''' - string. GTT number digits for the SCF.<br /> *** '''CalledPartyAddress.gt.encoding''' - string. It specifies the encoding for the GT digits. It is usually set to ''bcd''.<br /> *** '''CalledPartyAddress.gt.translation''' - integer. It specifies the GT translation type. It is usually set to ''0''. <br /> *** '''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.<br /> *** '''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.<br /> *** '''CallingPartyAddress.route'''<br /> *** '''CalledPartyAddress.ssn'''<br /> *** '''CallingPartyAddress.gt'''<br /> *** '''CallingPartyAddress.gt.encoding'''<br /> *** '''CallingPartyAddress.gt.translation'''<br /> *** '''CallingPartyAddress.gt.plan'''<br /> *** '''CallingPartyAddress.gt.nature''' <br /> ** 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.<br /> ** 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.<br /> ** 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.<br /> ** 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.<br /> <br /> A working configuration for ''camel_proxy.php'' looks like this:<br /> <br /> <br /> $myServiceKey = "1"; <br /> <br /> $proxyName = "camelProxy"; <br /> <br /> /** <br /> * GTT number of this SCP <br /> */ <br /> $mynum = "8820003"; <br /> <br /> /** <br /> * Transaction timeout after inactivity <br /> */ <br /> $transTimeout = 180; <br /> <br /> /** <br /> * List of configured proxied SCFs <br /> * The following parameters must be configured, all are mandatory: <br /> * serviceKey - value with which the IDP serviceKey should be rewritten <br /> * dp - detection point that should match the one received in IDP in order to contact this SCF <br /> * priority - priority in handling messages from SSF <br /> * errorFatal - whether or not an error or reject component from the SCF should terminate the whole proxy dialoque <br /> * addr - SS7 network addressing parameters. <br /> * local - whether the SCF is local (a local application) or external (it passes through the SS7 network to reach it) <br /> * handles - lists operation received from the SSF that are accepted by this SCF. <br /> * NOTE: Except ERBE, which is sent to all SCFs that match the reported DP, all operations that are handled by a <br /> * SCF should be listed, otherwise the proxy will report to the SSF an error. <br /> * context - if set, rewrites the application context for the dialog established with the SCF, otherwise leaves it as received <br /> * waitTime - time, in seconds, to wait for a result from a SCF while being in Waiting For Instructions state, after which the dialogue <br /> * is aborted. <br /> */ <br /> $scfs = array( <br /> "crbt-scp" => array( <br /> "serviceKey" => 2, <br /> "dp" => "termAttemptAuthorized", <br /> "priority" => 1, <br /> "errorFatal" => false, <br /> "addr" => array(), <br /> "local" => true, <br /> "handles" => array(), <br /> "context" => "", <br /> "waitTime" => 3, <br /> ),<br /> "pps-scp" => array( <br /> "serviceKey" => 99, <br /> "dp" => "termAttemptAuthorized", <br /> "priority" => 2, <br /> "errorFatal" => true, <br /> "addr" => array("CalledPartyAddress.gt" => "8820007", <br /> "CalledPartyAddress.route" => "gt", <br /> "CalledPartyAddress.gt.encoding" => "bcd", <br /> "CalledPartyAddress.gt.tt" => "0", <br /> "CalledPartyAddress.gt.np" => "isdn", <br /> "CalledPartyAddress.gt.nature" => "international", <br /> "CallingPartyAddress.gt" => "8820003", <br /> "CallingPartyAddress.route" => "gt", <br /> "CallingPartyAddress.gt.encoding" => "bcd", <br /> "CallingPartyAddress.gt.tt" => "0", <br /> "CallingPartyAddress.gt.np" => "isdn", <br /> "CallingPartyAddress.gt.nature" => "international", <br /> ), <br /> "local" => false, <br /> "handles" => array("applyChargingReport"), <br /> "context" => "", <br /> "waitTime" => 3, <br /> ), <br /> );<br /> <br /> ===Yate side===<br /> <br /> On the Yate side, the ''camel_map'' module must be configured through ''camel_map.conf''. <br /> <br /> In order for the module to ensure communication with the SSF, a section named <tt>[local name_of_proxy]</tt> must be configured:<br /> <br /> [local proxyName] - what comes after ''local'' will be the name of the application<br /> ;enable=no -- enable this application<br /> translator=scp - which translator should be used. A section named [tcap translatorValue] should be present in the config file.<br /> capabilities=Camel - capabilities supported by this application. CAMEL translator has only one capability and that is ''Camel''.<br /> export_xml_as=both - how to export the XML part: string, object or both?<br /> <br /> A <tt>[tcap name]</tt> section must be configured also. A section looks like this:<br /> <br /> [tcap scp] -- what comes after ''tcap'' will be the name of the translator<br /> ;enable=no -- enable this translator<br /> 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''<br /> host=0.0.0.0 -- address on which to listen for incoming applications<br /> port=0 -- port on which to listen for incoming applications. 0 means that will not build a listener, as the proxy works on messages.<br /> type=CAMEL -- type of translator (MAP/CAMEL). For the intended case, CAMEL should be set<br /> print-messages=true -- whether or not to print TCAP and XML messages in the logs<br /> add-encoding=false -- whether to add encoding attribute to data translated to XML<br /> <br /> <br /> For an external proxied SCF, additional <tt>[local scfName]</tt> and <tt>[tcap name]</tt> sections must be configured:<br /> <br /> [tcap msc]<br /> tcap=tcap-msc<br /> host=0.0.0.0<br /> port=0<br /> type=CAMEL<br /> print-messages=true<br /> add-encoding=false<br /> <br /> [local ext-scp]<br /> ;enable=no<br /> translator=msc<br /> capabilities=Camel<br /> export_xml_as=both<br /> <br /> <br /> '''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.<br /> <br /> ==Proxy Behaviour==<br /> <br /> Bellow, the behaviour of the CAMEL proxy implemented in ''camel_proxy.php'' is described.<br /> <br /> ===General===<br /> <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.<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 /> <br /> The main characteristics of the proxy behaviour are:<br /> * 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.<br /> * 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.<br /> * Invoke components from SCFs will be sent to the SSF and the proxy will keep track to which SCF each component belongs to.<br /> * Result and ReturnError components from the SSF will be passed by the proxy to the SCF that initially sent it.<br /> * 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:<br /> <br /> SSF Proxy SCF 1 SCF 2<br /> |------- Invoke 1 ----------->|WFI | | <br /> | |----- Invoke 1a ------>|WFI | <br /> | |<---- Invoke 2a -------|WFI |<br /> |<------ Invoke 2a -----------|WFI | |<br /> |------- Result 2a ---------->|WFI | |<br /> | |----- Result 2a ------>|WFI |<br /> | |<---- Invoke 3a CWA ---|MON |<br /> | |------------------------------ Invoke 1b --------->|WFI<br /> | |<----------------------------- Invoke 2b ----------|WFI<br /> | |<----------------------------- Invoke CONT 3b CONT-|MON<br /> |<------ Invoke 2b -----------| | |<br /> |<------ Invoke 3a CWA -------|MON | |<br /> | | | |<br /> | | | |<br /> |------- Invoke 4 ----------->|MON | |<br /> | |------ Invoke 4a ----->|MON |<br /> | |------------------------------ Invoke 4b --------->|MON<br /> <br /> * 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.<br /> * 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.<br /> * 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.<br /> * 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.<br /> <br /> ===InitialDP handling===<br /> <br /> The initialDP operation has special handling. Upon receiving this operation from the SSF, the proxy will take the following steps:<br /> * it will check for presence of the ''serviceKey'' parameter. If missing, it will reject the operation and end the dialogue with the SSF.<br /> * 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.<br /> * 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.<br /> * 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.<br /> * 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. <br /> <br /> ===RequestReportBCSM and EventReportBCSM handling===<br /> <br /> <br /> 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. <br /> 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.<br /> <br /> In order to prevent that, proxy does the following:<br /> * the proxy keeps track about how DPs were armed for the dialogue with the SSF, and also for the dialogues with the SCFs.<br /> * 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:<br /> ** 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.<br /> ** 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.<br /> ** 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.<br /> ** 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.<br /> * 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.<br /> <br /> '''Question:''' It may turn that SCF requested ''notify'', but got ''interrupted'' EventReportBCSM, right? Is it OK? <br/><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.<br /> <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/><br /> '''Answer:''' Yes.<br /> <br /> '''Question:''' Are CRBT scripts ready for this scenario?<br/><br /> '''Answer:''' Yes, the CRBT script when handling DPs is prepared to handle such a situation.<br /> <br /> '''Question:''' It seems better to issue CONT by proxy and change ''interrupted'' to what was originally requested by certain SCF. Not sure.<br/><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.<br /> <br /> ===Multiple Continue/ContinueWithArgument handling===<br /> <br /> <br /> 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.<br /> For that, the proxy will do the following:<br /> * 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.<br /> * if in the message there are only CONT invocations, only the last one is left, the other ones are removed before sending.<br /> * 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.<br /> * 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.<br /> <br /> Question: how does SSF handle multiple CWA?<br/><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.<br /> <br /> ===Leg ID and DP rewriting===<br /> <br /> 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:<br /> * 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.<br /> * 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.<br /> * 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)<br /> * 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.<br /> * leg rewriting handling also aplies to ApplyCharging and ApplyChargingReport operations.<br /> <br /> 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.</div>

Monica https://ss7api.null.ro/index.php/CAMEL_proxy CAMEL proxy 2013-10-28T11:44:17Z

<p>Monica: /* General */</p> <hr /> <div>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.<br /> <br /> The main purpose is to be able to provide CRBT and PPS (PrePaid Service) facilities in parallel.<br /> <br /> The layout for such a scenario will look like this:<br /> <br /> [[File:CamelProxy.png]]<br /> <br /> 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.<br /> The proxy keeps an evidence of these multiple invocations and aggregates them into a single, valid dialogue with the invoking SSP.<br /> <br /> ==Camel Proxy Module Configuration==<br /> <br /> The configuration file is camel_bcsm_proxy.conf<br /> <br /> ===Module configuration===<br /> <br /> ===='general' section====<br /> <br /> '''application''': Application parameter in camel messages sent/handled for SSF dialogs.<br/><br /> This parameter is required and is not applied on reload (can't be changed after module starts).<br/><br /> <br/><br /> '''gt''': Global Title to be set in the first message sent in the SSF dialog.<br/><br /> This parameter is applied on reload.<br/><br /> TCAP address parameters to be set in the first message sent back to SSF can also be set using '''addr.''' prefix.<br/><br /> E.g. GT can be set as '''addr.CallingPartyAddress.gt''' along with other parameters like number nature '''addr.CallingPartyAddress.nature'''.<br/><br /> Setting the GT without other parameters is the same as:<br/><br /> addr.CallingPartyAddress.gt=[GT set]<br/><br /> addr.CallingPartyAddress.route=gt<br/><br /> addr.CallingPartyAddress.gt.encoding=bcd<br/><br /> addr.CallingPartyAddress.gt.translation=0<br/><br /> addr.CallingPartyAddress.gt.plan=isdn<br/><br /> addr.CallingPartyAddress.gt.nature=international<br/><br /> <br/><br /> '''servicekey''': CAMEL serviceKey to check when in received initialDP and set when forwarding them to SCFs.<br/><br /> Allowed interval: 0..2147483647.<br/><br /> Defaults to 0 if missing or invalid.<br/><br /> This parameter is applied on reload for new dialogs only.<br/><br /> <br/><br /> '''query_scf''': Boolean value indicating whether to query for proxied SCFs update when processing initialDP.<br/><br /> Is enabled a 'scf.query' message will be enqueued and the module will wait for a 'scf.response' message to continue IDP processing.<br/><br /> Defaults to no.<br/><br /> <br/><br /> '''print_msg''': boolean/string: Print sent/received messages to output if debug level is at least 9.<br/><br /> Allowed values are boolean values or 'verbose' string.<br/><br /> If verbose is specified, the message will be dumped on output.<br/><br /> Defaults to no.<br/><br /> <br/><br /> '''print_xml''': boolean/string: Print sent/received XML data to output if debug level is at least 9.<br/><br /> This parameter is ignored if print_msg is disabled.<br/><br /> Allowed values are boolean values or 'verbose' string.<br/><br /> If verbose is specified, XML elements' children, attributes or text will be shown on separate lines.<br/><br /> Defaults to no.<br/><br /> <br/><br /> '''idp_calling_required''': boolean: Calling party number is required (non empty) in initialDP.<br/><br /> Default to yes.<br/><br /> <br/><br /> '''idp_called_required''': boolean: Called party number is required (non empty) in initialDP.<br/><br /> Default to yes.<br/><br /> <br/><br /> '''dispatcher_maxthreads''': integer: Maximum number of message dispatch threads to use.<br/><br /> Set to 0 to enqueue messages using yate engine.<br/><br /> Defaults to 0.<br/><br /> 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).<br/><br /> <br/><br /> ====Proxied SCF section(s)====<br /> <br /> '''enable''': boolean: Enable the SCF.<br/><br /> Defaults to yes.<br/><br /> <br/><br /> '''priority''': integer: Priority in handling messages from SSF.<br/><br /> Defaults to 0.<br/><br /> <br/><br /> '''servicekey''': integer: Value with which the IDP serviceKey should be rewritten.<br/><br /> Allowed interval: 0..2147483647.<br/><br /> Defaults to SSF service key set in 'general' section.<br/><br /> <br/><br /> '''dp''': string: Comma separated list of detection points that should match the one received in IDP in order to contact this SCF.<br/><br /> Items may be DP value or name.<br/><br /> Defaults to termAttemptAuthorized if empty or all DPs are invalid.<br/><br /> <br/><br /> '''endfatal''': boolean: Indicate whether or not terminate the proxy dialog when this dialog ends.<br/><br /> Defaults to no.<br/><br /> <br/><br /> '''errorfatal''': boolean: Indicate whether or not an error or reject component from the SCF should terminate the whole proxy dialog.<br/><br /> Defaults to no.<br/><br /> <br/><br /> '''local''': boolean: The SCF is local (a local application) or external (it passes through the SS7 network to reach it).<br/><br /> Defaults to no (external application).<br/><br /> <br/><br /> '''instances''': integer: Number of local application instances.<br/><br /> This parameter is ignored for non local SCFs.<br/><br /> If non 0 it must be set to a value greater then 1.<br/><br /> Defaults to 0.<br/><br /> If non 0 the module will build the required number of SCFs and will pick them using a round-robin algorithm.<br/><br /> Each application's name will be built from SCF application name concatenated with instance suffix startting from 1.<br/><br /> E.g.:<br /> <br /> [proxy SCP]<br /> instances=2<br /> <br /> Will build 2 applications: SCP1 and SCP2.<br/><br /> <br/><br /> '''handles''': string: Comma separated list of operations received from the SSF accepted by this SCF.<br/><br /> 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.<br/><br /> <br/><br /> '''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.<br/><br /> Defaults to 3000.<br/><br /> Minimum allowed value is 1000.<br/><br /> <br/><br /> All other parameters starting with 'addr.' prefix will be put in dialog begin message sent for this SCF.<br/><br /> They should be set for non local SCFs.<br/><br /> Parameters:<br /> * '''addr.CalledPartyAddress.route''' - string. It can be set to values: gt/ssn. It specifies how the SCCP address should be routed.<br /> * '''addr.CalledPartyAddress.ssn''' - integer. It's the SSN number in case of SSN routing.<br /> * '''addr.CalledPartyAddress.gt''' - string. GTT number digits for the SCF.<br /> * '''addr.CalledPartyAddress.gt.encoding''' - string. It specifies the encoding for the GT digits. It is usually set to bcd.<br /> * '''addr.CalledPartyAddress.gt.tt''' - integer. It specifies the GT translation type. It is usually set to 0.<br /> * '''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.<br /> * '''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.<br /> * '''addr.CallingPartyAddress.route'''<br /> * '''addr.CalledPartyAddress.ssn'''<br /> * '''addr.CallingPartyAddress.gt'''<br /> * '''addr.CallingPartyAddress.gt.encoding'''<br /> * '''addr.CallingPartyAddress.gt.tt'''<br /> * '''addr.CallingPartyAddress.gt.np'''<br /> * '''addr.CallingPartyAddress.gt.nature''' <br /> <br /> ====Example====<br /> <br /> [general]<br /> application=camelProxy<br /> servicekey=1<br /> gt=8820003<br /> <br /> [proxy crbt-scp]<br /> servicekey=2<br /> local=true<br /> <br /> [proxy pps-scp]<br /> servicekey=99<br /> priority=2<br /> errorfatal=true<br /> handles=applyChargingReport<br /> addr.CalledPartyAddress.gt=8820007<br /> addr.CalledPartyAddress.route=gt<br /> addr.CalledPartyAddress.gt.encoding=bcd<br /> addr.CalledPartyAddress.gt.tt=0<br /> addr.CalledPartyAddress.gt.np=isdn<br /> addr.CalledPartyAddress.gt.nature=international<br /> addr.CallingPartyAddress.gt=8820003<br /> addr.CallingPartyAddress.route=gt<br /> addr.CallingPartyAddress.gt.encoding=bcd<br /> addr.CallingPartyAddress.gt.tt=0<br /> addr.CallingPartyAddress.gt.np=isdn<br /> addr.CallingPartyAddress.gt.nature=international<br /> <br /> <br /> === camel_map configuration ===<br /> <br /> [local camelProxy]<br /> translator=scp_proxy<br /> capabilities=Camel<br /> <br /> [tcap scp_proxy]<br /> type=CAMEL<br /> tcap=tcap_msc<br /> port=0<br /> <br /> [local pps-scp]<br /> translator=scp_pps<br /> capabilities=Camel<br /> <br /> [tcap scp_pps]<br /> type=CAMEL<br /> tcap=tcap_pps<br /> port=0<br /> <br /> ===camel_bcsm_proxy.conf.sample===<br /> <br /> ; NOTE: This module is not loaded automatically, it needs a line in yate.conf:<br /> ; [postload]<br /> ; ${modulepath}/sig/camel_bcsm_proxy${modsuffix}=yes<br /> <br /> [general]<br /> ; Unless explicitly specified, all parameters are applied on reload for new<br /> ; dialogs only<br /> ; All parameters starting with 'addr.' prefix will be put in the first message sent to SSF<br /> <br /> ; application: string: Application parameter in camel messages sent by the module<br /> ; This parameter is required<br /> ; This parameter is not applied on reload<br /> ;application=<br /> <br /> ; gt: string: Global Title to be set in the first message sent in the SSF dialog<br /> ; This parameter is applied on reload for new dialogs only<br /> ; If non empty other calling party address parameters will be set to default values<br /> ; This parameter can be overriden by addr.CallingPartyAddress.gt parameter<br /> ;gt=<br /> <br /> ; servicekey: integer: CAMEL serviceKey to check in received initialDP messages and<br /> ; set when forwarding them to SCFs<br /> ; Allowed interval: 0..2147483647<br /> ; Defaults to 0 if missing or invalid<br /> ; This parameter is applied on reload for new dialogs only<br /> ;servicekey=0<br /> <br /> ; query_scf: boolean: Query for proxied SCFs update when processing initialDP<br /> ; Is enabled a 'scf.query' message will be enqueued and the module will wait<br /> ; for a 'scf.response' message to continue IDP processing<br /> ; The response must return the list of SCFs to proxy<br /> ; The list may be shorter then configured SCFs<br /> ; New SCFs, other then configured ones, will be ignored<br /> ; The following SCF parameters can be overridden: priority, servicekey, errorfatal,<br /> ; handles, waittime and all parameters starting with 'addr.' prefix<br /> ; Defaults to no<br /> ;query_scf=no<br /> <br /> ; component_ttl: integer: Component time to live in milliseconds<br /> ; Minimum allowed value is 1000<br /> ; Defaults to 15000<br /> ;component_ttl=15000<br /> <br /> ; dialog_idle_ttl: integer: Dialog idle (nothing sent/received) time to live in milliseconds<br /> ; Minimum allowed value is 1000<br /> ; It can be set to 0 to keep it alive until the remote party terminates the dialog<br /> ; Defaults to 5000<br /> ;dialog_idle_ttl=5000<br /> <br /> ; dialog_ended_ttl: integer: Ended dialog time to live in milliseconds<br /> ; Minimum allowed value is 1000.<br /> ; It can be set to 0 to remove the dialog after termination<br /> ; Defaults to 0<br /> ;dialog_ended_ttl=0<br /> <br /> ; export_xml_as: string: Specify in which way the XML will be passed along into<br /> ; Yate messages<br /> ; Allowed values are:<br /> ; - string: pass the XML as a string<br /> ; - object: pass the XML as an object<br /> ; - both: pass the XML as a string and object<br /> ; Defaults to object<br /> ;export_xml_as=object<br /> <br /> ; print_msg: boolean/string: Print sent/received messages to output if debug<br /> ; level is at least 9<br /> ; Allowed values are boolean values or 'verbose' string<br /> ; If verbose is specified, the message will be dumped on output<br /> ; Defaults to no<br /> ;print_msg=no<br /> <br /> ; print_xml: boolean/string: Print sent/received XML data to output if debug<br /> ; level is at least 9<br /> ; This parameter is ignored if print_msg is disabled<br /> ; Allowed values are boolean values or 'verbose' string<br /> ; If verbose is specified, XML elements' children, attributes or text will be<br /> ; shown on separate lines<br /> ; Defaults to no<br /> ;print_xml=no<br /> <br /> ; idp_calling_required: boolean: Calling party number is required (non empty) in initialDP<br /> ; Default to yes<br /> ;idp_calling_required=yes<br /> <br /> ; idp_called_required: boolean: Called party number is required (non empty) in initialDP<br /> ; Default to yes<br /> ;idp_called_required=yes<br /> <br /> ; dispatcher_maxthreads: integer: Maximum number of message dispatch threads to use<br /> ; Set to 0 to enqueue messages using yate engine<br /> ; Defaults to 0<br /> ; When reloaded it can't be set to 0 (e.g. once set to a non 0 value it can be changed to<br /> ; non 0 values only)<br /> ;dispatcher_maxthreads=0<br /> <br /> ;dispatcher_priority: string: Default priority of message dispatch threads<br /> ; Can be one of: lowest, low, normal, high, highest<br /> ; High priorities need superuser privileges on POSIX operating systems<br /> ; Low priorities are not recommended except for debugging<br /> ; Defaults to 'normal'<br /> ; This parameter is applied on reload for new threads only<br /> ;dispatcher_priority=normal<br /> <br /> <br /> ;[proxy appname]<br /> ; This section configures a proxied SCF<br /> ; 'appname' is the application name to be used for the SCF<br /> <br /> ; enable: boolean: Enable the SCF<br /> ; Defaults to yes<br /> ;enable=yes<br /> <br /> ; priority: integer: Priority in handling messages from SSF<br /> ; Defaults to 0<br /> ;priority=0<br /> <br /> ; servicekey: integer: Value with which the IDP serviceKey should be rewritten<br /> ; Allowed interval: 0..2147483647<br /> ; Defaults to SSF service key set in 'general' section<br /> ;servicekey=<br /> <br /> ; dp: string: Comma separated list of detection points that should match the one received in IDP<br /> ; in order to contact this SCF<br /> ; Items may be DP value or name<br /> ; Defaults to termAttemptAuthorized if empty or all DPs are invalid<br /> ;dp=termAttemptAuthorized<br /> <br /> ; endfatal: boolean: Indicate whether or not terminate the proxy dialog when this dialog ends<br /> ; Defaults to no<br /> ;endfatal=no<br /> <br /> ; errorfatal: boolean: Indicate whether or not an error or reject component from<br /> ; the SCF should terminate the whole proxy dialog<br /> ; Defaults to no<br /> ;errorfatal=no<br /> <br /> ; local: boolean: The SCF is local (a local application) or external (it passes<br /> ; through the SS7 network to reach it)<br /> ; Defaults to no (external application)<br /> ;local=no<br /> <br /> ; instances: integer: Number of local application instances<br /> ; If non 0 the module will build the required number of SCFs and will pick them using a<br /> ; round-robin algorithm<br /> ; Each application's name will be built from SCF application name concatenated with instance<br /> ; suffix startting from 1<br /> ; E.g.<br /> ; [proxy SCP]<br /> ; instances=2<br /> ; Will build 2 applications: SCP1 and SCP2<br /> ; This parameter is ignored for non local SCFs<br /> ; If non 0 it must be set to a value greater then 1<br /> ; Defaults to 0<br /> ;instance=<br /> <br /> ; handles: string: Comma separated list of operations received from the SSF<br /> ; accepted by this SCF<br /> ; NOTE: Except ERB (Event Report BCSM), which is sent to all SCFs that match the reported DP,<br /> ; all operations that are handled by a SCF should be listed, otherwise the<br /> ; proxy will report to the SSF an error<br /> ;handles=<br /> <br /> ; waittime: integer: Time, in miliseconds, to wait for a result from a SCF<br /> ; while being in Waiting For Instructions state, after which the dialog<br /> ; is aborted<br /> ; Defaults to 3000<br /> ; Minimum allowed value is 1000<br /> ;waittime=3000<br /> <br /> ; All other parameters starting with 'addr.' prefix will be put in dialog begin<br /> ; message sent for this SCF<br /> ; E.g. addr.CalledPartyAddress.route=gt will be put as CalledPartyAddress.route=gt<br /> <br /> ==Proxy Module Test==<br /> This chapter describes how the Camel Proxy module was tested.<br /> <br /> The purpose of the test was to check if the Camel BCSM Proxy module can handle 100CPS.<br /> <br /> The machine used was a Dual Intel Xeon E5620 (Quad Core with HT) = 16CPUs, 32GB RAM with CentOS 6.2<br /> <br /> The setup was:<br/><br /> Yate1 - Call generator, sending calls to Yate3 using SIP<br/><br /> Yate2 - Call generator, sending calls to Yate4 using SIP<br/><br /> Yate3 - Call handling, send initialDP to Yate5 (Proxy)<br/><br /> Yate4 - Call handling, send initialDP to Yate5 (Proxy)<br/><br /> Yate5 - Camel BCSM Proxy<br/><br /> Yate6 - CRBT script<br/><br /> Yate7 - PPS script<br/><br /> Yate8 - PPS script<br /> <br /> <br /> SIP M2PA link M2PA links<br /> Yate1 ---------> Yate3 ------------| |-----------> Yate6 (CRBT)<br /> | |<br /> |-> Yate5 |-----------> Yate7 (PPS)<br /> | |<br /> SIP M2PA link | |-----------> Yate8 (PPS)<br /> Yate2 ---------> Yate4 ------------| <br /> <br /> <br /> '''NOTES:'''<br /> * The sum of both call generators was 110CPS.<br /> * During test top reported ~250%CPU for Proxy.<br /> * All yate instances were running on the same machine.<br /> * 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.<br /> <br /> How success was checked:<br /> * On call generators all calls were answered<br /> * 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')<br /> * On Proxy instance (Yate5) there were no timeouts (this would indicate a SCF is not responding withing default 3 seconds interval)<br /> <br /> ==Configuration==<br /> <br /> ===Script side===<br /> <br /> Configuration of the "camel_proxy.php" script is done through ''config_proxy.php''. This allows setting the following parameters:<br /> <br /> * 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.<br /> <br /> * 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.<br /> <br /> * 3. '''$mynum''' - string. GTT number assigned to this SCP. <br /> <br /> * 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.<br /> <br /> * 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:<br /> ** 5.1. '''serviceKey''' - integer. It represents the service key to be used when constructing an IDP for this SCF..<br /> ** 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.<br /> ** 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).<br /> ** 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.<br /> ** 5.5. '''addr''' - array. It specifies SS7 network addressing parameters. They only need be set for external SCFs. Parameters are usually set here are:<br /> *** '''CalledPartyAddress.route''' - string. It can be set to values: gt/ssn. It specifies how the SCCP address should be routed.<br /> *** '''CalledPartyAddress.ssn''' - integer. It's the SSN number in case of SSN routing.<br /> *** '''CalledPartyAddress.gt''' - string. GTT number digits for the SCF.<br /> *** '''CalledPartyAddress.gt.encoding''' - string. It specifies the encoding for the GT digits. It is usually set to ''bcd''.<br /> *** '''CalledPartyAddress.gt.translation''' - integer. It specifies the GT translation type. It is usually set to ''0''. <br /> *** '''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.<br /> *** '''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.<br /> *** '''CallingPartyAddress.route'''<br /> *** '''CalledPartyAddress.ssn'''<br /> *** '''CallingPartyAddress.gt'''<br /> *** '''CallingPartyAddress.gt.encoding'''<br /> *** '''CallingPartyAddress.gt.translation'''<br /> *** '''CallingPartyAddress.gt.plan'''<br /> *** '''CallingPartyAddress.gt.nature''' <br /> ** 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.<br /> ** 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.<br /> ** 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.<br /> ** 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.<br /> <br /> A working configuration for ''camel_proxy.php'' looks like this:<br /> <br /> <br /> $myServiceKey = "1"; <br /> <br /> $proxyName = "camelProxy"; <br /> <br /> /** <br /> * GTT number of this SCP <br /> */ <br /> $mynum = "8820003"; <br /> <br /> /** <br /> * Transaction timeout after inactivity <br /> */ <br /> $transTimeout = 180; <br /> <br /> /** <br /> * List of configured proxied SCFs <br /> * The following parameters must be configured, all are mandatory: <br /> * serviceKey - value with which the IDP serviceKey should be rewritten <br /> * dp - detection point that should match the one received in IDP in order to contact this SCF <br /> * priority - priority in handling messages from SSF <br /> * errorFatal - whether or not an error or reject component from the SCF should terminate the whole proxy dialoque <br /> * addr - SS7 network addressing parameters. <br /> * local - whether the SCF is local (a local application) or external (it passes through the SS7 network to reach it) <br /> * handles - lists operation received from the SSF that are accepted by this SCF. <br /> * NOTE: Except ERBE, which is sent to all SCFs that match the reported DP, all operations that are handled by a <br /> * SCF should be listed, otherwise the proxy will report to the SSF an error. <br /> * context - if set, rewrites the application context for the dialog established with the SCF, otherwise leaves it as received <br /> * waitTime - time, in seconds, to wait for a result from a SCF while being in Waiting For Instructions state, after which the dialogue <br /> * is aborted. <br /> */ <br /> $scfs = array( <br /> "crbt-scp" => array( <br /> "serviceKey" => 2, <br /> "dp" => "termAttemptAuthorized", <br /> "priority" => 1, <br /> "errorFatal" => false, <br /> "addr" => array(), <br /> "local" => true, <br /> "handles" => array(), <br /> "context" => "", <br /> "waitTime" => 3, <br /> ),<br /> "pps-scp" => array( <br /> "serviceKey" => 99, <br /> "dp" => "termAttemptAuthorized", <br /> "priority" => 2, <br /> "errorFatal" => true, <br /> "addr" => array("CalledPartyAddress.gt" => "8820007", <br /> "CalledPartyAddress.route" => "gt", <br /> "CalledPartyAddress.gt.encoding" => "bcd", <br /> "CalledPartyAddress.gt.tt" => "0", <br /> "CalledPartyAddress.gt.np" => "isdn", <br /> "CalledPartyAddress.gt.nature" => "international", <br /> "CallingPartyAddress.gt" => "8820003", <br /> "CallingPartyAddress.route" => "gt", <br /> "CallingPartyAddress.gt.encoding" => "bcd", <br /> "CallingPartyAddress.gt.tt" => "0", <br /> "CallingPartyAddress.gt.np" => "isdn", <br /> "CallingPartyAddress.gt.nature" => "international", <br /> ), <br /> "local" => false, <br /> "handles" => array("applyChargingReport"), <br /> "context" => "", <br /> "waitTime" => 3, <br /> ), <br /> );<br /> <br /> ===Yate side===<br /> <br /> On the Yate side, the ''camel_map'' module must be configured through ''camel_map.conf''. <br /> <br /> In order for the module to ensure communication with the SSF, a section named <tt>[local name_of_proxy]</tt> must be configured:<br /> <br /> [local proxyName] - what comes after ''local'' will be the name of the application<br /> ;enable=no -- enable this application<br /> translator=scp - which translator should be used. A section named [tcap translatorValue] should be present in the config file.<br /> capabilities=Camel - capabilities supported by this application. CAMEL translator has only one capability and that is ''Camel''.<br /> export_xml_as=both - how to export the XML part: string, object or both?<br /> <br /> A <tt>[tcap name]</tt> section must be configured also. A section looks like this:<br /> <br /> [tcap scp] -- what comes after ''tcap'' will be the name of the translator<br /> ;enable=no -- enable this translator<br /> 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''<br /> host=0.0.0.0 -- address on which to listen for incoming applications<br /> port=0 -- port on which to listen for incoming applications. 0 means that will not build a listener, as the proxy works on messages.<br /> type=CAMEL -- type of translator (MAP/CAMEL). For the intended case, CAMEL should be set<br /> print-messages=true -- whether or not to print TCAP and XML messages in the logs<br /> add-encoding=false -- whether to add encoding attribute to data translated to XML<br /> <br /> <br /> For an external proxied SCF, additional <tt>[local scfName]</tt> and <tt>[tcap name]</tt> sections must be configured:<br /> <br /> [tcap msc]<br /> tcap=tcap-msc<br /> host=0.0.0.0<br /> port=0<br /> type=CAMEL<br /> print-messages=true<br /> add-encoding=false<br /> <br /> [local ext-scp]<br /> ;enable=no<br /> translator=msc<br /> capabilities=Camel<br /> export_xml_as=both<br /> <br /> <br /> '''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.<br /> <br /> ==Proxy Behaviour==<br /> <br /> Bellow, the behaviour of the CAMEL proxy implemented in ''camel_proxy.php'' is described.<br /> <br /> ===General===<br /> <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.<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 /> <br /> The main characteristics of the proxy behaviour are:<br /> * 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.<br /> * 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.<br /> * Invoke components from SCFs will be sent to the SSF and the proxy will keep track to which SCF each component belongs to.<br /> * Result and ReturnError components from the SSF will be passed by the proxy to the SCF that initially sent it.<br /> * 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:<br /> <br /> SSF Proxy SCF 1 SCF 2<br /> |------- Invoke 1 ----------->|WFI | | <br /> | |----- Invoke 1a ------>|WFI | <br /> | |<---- Invoke 2a -------|WFI |<br /> |<------ Invoke 2a -----------|WFI | |<br /> |------- Result 2a ---------->|WFI | |<br /> | |----- Result 2a ------>|WFI |<br /> | |<---- Invoke 3a CWA ---|MON |<br /> | |------------------------------ Invoke 1b --------->|WFI<br /> | |<----------------------------- Invoke 2b ----------|WFI<br /> | |<----------------------------- Invoke CONT 3b CONT-|MON<br /> |<------ Invoke 2b -----------| | |<br /> |<------ Invoke 3a CWA -------|MON | |<br /> | | | |<br /> | | | |<br /> |------- Invoke 4 ----------->|MON | |<br /> | |------ Invoke 4a ----->|MON |<br /> | |------------------------------ Invoke 4b --------->|MON<br /> <br /> * 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.<br /> * 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.<br /> * 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.<br /> * 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.<br /> <br /> ===InitialDP handling===<br /> <br /> The initialDP operation has special handling. Upon receiving this operation from the SSF, the proxy will take the following steps:<br /> * it will check for presence of the ''serviceKey'' parameter. If missing, it will reject the operation and end the dialogue with the SSF.<br /> * 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.<br /> * 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.<br /> * 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.<br /> * 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. <br /> <br /> ===RequestReportBCSM and EventReportBCSM handling===<br /> <br /> <br /> 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. <br /> 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.<br /> <br /> In order to prevent that, proxy does the following:<br /> * the proxy keeps track about how DPs were armed for the dialogue with the SSF, and also for the dialogues with the SCFs.<br /> * 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:<br /> ** 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.<br /> ** 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.<br /> ** 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.<br /> ** 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.<br /> * 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.<br /> <br /> Question: It may turn that SCF requested ''notify'', but got ''interrupted'' EventReportBCSM, right? Is it OK? <br/><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.<br /> <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/><br /> Answer: Yes.<br /> <br /> Question: Are CRBT scripts ready for this scenario?<br/><br /> Answer: Yes, the CRBT script when handling DPs is prepared to handle such a situation.<br /> <br /> Question: It seems better to issue CONT by proxy and change ''interrupted'' to what was originally requested by certain SCF. Not sure.<br/><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.<br /> <br /> ===Multiple Continue/ContinueWithArgument handling===<br /> <br /> <br /> 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.<br /> For that, the proxy will do the following:<br /> * 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.<br /> * if in the message there are only CONT invocations, only the last one is left, the other ones are removed before sending.<br /> * 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.<br /> * 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.<br /> <br /> Question: how does SSF handle multiple CWA?<br/><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.<br /> <br /> ===Leg ID and DP rewriting===<br /> <br /> 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:<br /> * 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.<br /> * 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.<br /> * 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)<br /> * 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.<br /> * leg rewriting handling also aplies to ApplyCharging and ApplyChargingReport operations.<br /> <br /> 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.</div>

Monica https://ss7api.null.ro/index.php/CAMEL_proxy CAMEL proxy 2013-10-28T11:44:03Z

<p>Monica: /* General */</p> <hr /> <div>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.<br /> <br /> The main purpose is to be able to provide CRBT and PPS (PrePaid Service) facilities in parallel.<br /> <br /> The layout for such a scenario will look like this:<br /> <br /> [[File:CamelProxy.png]]<br /> <br /> 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.<br /> The proxy keeps an evidence of these multiple invocations and aggregates them into a single, valid dialogue with the invoking SSP.<br /> <br /> ==Camel Proxy Module Configuration==<br /> <br /> The configuration file is camel_bcsm_proxy.conf<br /> <br /> ===Module configuration===<br /> <br /> ===='general' section====<br /> <br /> '''application''': Application parameter in camel messages sent/handled for SSF dialogs.<br/><br /> This parameter is required and is not applied on reload (can't be changed after module starts).<br/><br /> <br/><br /> '''gt''': Global Title to be set in the first message sent in the SSF dialog.<br/><br /> This parameter is applied on reload.<br/><br /> TCAP address parameters to be set in the first message sent back to SSF can also be set using '''addr.''' prefix.<br/><br /> E.g. GT can be set as '''addr.CallingPartyAddress.gt''' along with other parameters like number nature '''addr.CallingPartyAddress.nature'''.<br/><br /> Setting the GT without other parameters is the same as:<br/><br /> addr.CallingPartyAddress.gt=[GT set]<br/><br /> addr.CallingPartyAddress.route=gt<br/><br /> addr.CallingPartyAddress.gt.encoding=bcd<br/><br /> addr.CallingPartyAddress.gt.translation=0<br/><br /> addr.CallingPartyAddress.gt.plan=isdn<br/><br /> addr.CallingPartyAddress.gt.nature=international<br/><br /> <br/><br /> '''servicekey''': CAMEL serviceKey to check when in received initialDP and set when forwarding them to SCFs.<br/><br /> Allowed interval: 0..2147483647.<br/><br /> Defaults to 0 if missing or invalid.<br/><br /> This parameter is applied on reload for new dialogs only.<br/><br /> <br/><br /> '''query_scf''': Boolean value indicating whether to query for proxied SCFs update when processing initialDP.<br/><br /> Is enabled a 'scf.query' message will be enqueued and the module will wait for a 'scf.response' message to continue IDP processing.<br/><br /> Defaults to no.<br/><br /> <br/><br /> '''print_msg''': boolean/string: Print sent/received messages to output if debug level is at least 9.<br/><br /> Allowed values are boolean values or 'verbose' string.<br/><br /> If verbose is specified, the message will be dumped on output.<br/><br /> Defaults to no.<br/><br /> <br/><br /> '''print_xml''': boolean/string: Print sent/received XML data to output if debug level is at least 9.<br/><br /> This parameter is ignored if print_msg is disabled.<br/><br /> Allowed values are boolean values or 'verbose' string.<br/><br /> If verbose is specified, XML elements' children, attributes or text will be shown on separate lines.<br/><br /> Defaults to no.<br/><br /> <br/><br /> '''idp_calling_required''': boolean: Calling party number is required (non empty) in initialDP.<br/><br /> Default to yes.<br/><br /> <br/><br /> '''idp_called_required''': boolean: Called party number is required (non empty) in initialDP.<br/><br /> Default to yes.<br/><br /> <br/><br /> '''dispatcher_maxthreads''': integer: Maximum number of message dispatch threads to use.<br/><br /> Set to 0 to enqueue messages using yate engine.<br/><br /> Defaults to 0.<br/><br /> 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).<br/><br /> <br/><br /> ====Proxied SCF section(s)====<br /> <br /> '''enable''': boolean: Enable the SCF.<br/><br /> Defaults to yes.<br/><br /> <br/><br /> '''priority''': integer: Priority in handling messages from SSF.<br/><br /> Defaults to 0.<br/><br /> <br/><br /> '''servicekey''': integer: Value with which the IDP serviceKey should be rewritten.<br/><br /> Allowed interval: 0..2147483647.<br/><br /> Defaults to SSF service key set in 'general' section.<br/><br /> <br/><br /> '''dp''': string: Comma separated list of detection points that should match the one received in IDP in order to contact this SCF.<br/><br /> Items may be DP value or name.<br/><br /> Defaults to termAttemptAuthorized if empty or all DPs are invalid.<br/><br /> <br/><br /> '''endfatal''': boolean: Indicate whether or not terminate the proxy dialog when this dialog ends.<br/><br /> Defaults to no.<br/><br /> <br/><br /> '''errorfatal''': boolean: Indicate whether or not an error or reject component from the SCF should terminate the whole proxy dialog.<br/><br /> Defaults to no.<br/><br /> <br/><br /> '''local''': boolean: The SCF is local (a local application) or external (it passes through the SS7 network to reach it).<br/><br /> Defaults to no (external application).<br/><br /> <br/><br /> '''instances''': integer: Number of local application instances.<br/><br /> This parameter is ignored for non local SCFs.<br/><br /> If non 0 it must be set to a value greater then 1.<br/><br /> Defaults to 0.<br/><br /> If non 0 the module will build the required number of SCFs and will pick them using a round-robin algorithm.<br/><br /> Each application's name will be built from SCF application name concatenated with instance suffix startting from 1.<br/><br /> E.g.:<br /> <br /> [proxy SCP]<br /> instances=2<br /> <br /> Will build 2 applications: SCP1 and SCP2.<br/><br /> <br/><br /> '''handles''': string: Comma separated list of operations received from the SSF accepted by this SCF.<br/><br /> 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.<br/><br /> <br/><br /> '''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.<br/><br /> Defaults to 3000.<br/><br /> Minimum allowed value is 1000.<br/><br /> <br/><br /> All other parameters starting with 'addr.' prefix will be put in dialog begin message sent for this SCF.<br/><br /> They should be set for non local SCFs.<br/><br /> Parameters:<br /> * '''addr.CalledPartyAddress.route''' - string. It can be set to values: gt/ssn. It specifies how the SCCP address should be routed.<br /> * '''addr.CalledPartyAddress.ssn''' - integer. It's the SSN number in case of SSN routing.<br /> * '''addr.CalledPartyAddress.gt''' - string. GTT number digits for the SCF.<br /> * '''addr.CalledPartyAddress.gt.encoding''' - string. It specifies the encoding for the GT digits. It is usually set to bcd.<br /> * '''addr.CalledPartyAddress.gt.tt''' - integer. It specifies the GT translation type. It is usually set to 0.<br /> * '''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.<br /> * '''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.<br /> * '''addr.CallingPartyAddress.route'''<br /> * '''addr.CalledPartyAddress.ssn'''<br /> * '''addr.CallingPartyAddress.gt'''<br /> * '''addr.CallingPartyAddress.gt.encoding'''<br /> * '''addr.CallingPartyAddress.gt.tt'''<br /> * '''addr.CallingPartyAddress.gt.np'''<br /> * '''addr.CallingPartyAddress.gt.nature''' <br /> <br /> ====Example====<br /> <br /> [general]<br /> application=camelProxy<br /> servicekey=1<br /> gt=8820003<br /> <br /> [proxy crbt-scp]<br /> servicekey=2<br /> local=true<br /> <br /> [proxy pps-scp]<br /> servicekey=99<br /> priority=2<br /> errorfatal=true<br /> handles=applyChargingReport<br /> addr.CalledPartyAddress.gt=8820007<br /> addr.CalledPartyAddress.route=gt<br /> addr.CalledPartyAddress.gt.encoding=bcd<br /> addr.CalledPartyAddress.gt.tt=0<br /> addr.CalledPartyAddress.gt.np=isdn<br /> addr.CalledPartyAddress.gt.nature=international<br /> addr.CallingPartyAddress.gt=8820003<br /> addr.CallingPartyAddress.route=gt<br /> addr.CallingPartyAddress.gt.encoding=bcd<br /> addr.CallingPartyAddress.gt.tt=0<br /> addr.CallingPartyAddress.gt.np=isdn<br /> addr.CallingPartyAddress.gt.nature=international<br /> <br /> <br /> === camel_map configuration ===<br /> <br /> [local camelProxy]<br /> translator=scp_proxy<br /> capabilities=Camel<br /> <br /> [tcap scp_proxy]<br /> type=CAMEL<br /> tcap=tcap_msc<br /> port=0<br /> <br /> [local pps-scp]<br /> translator=scp_pps<br /> capabilities=Camel<br /> <br /> [tcap scp_pps]<br /> type=CAMEL<br /> tcap=tcap_pps<br /> port=0<br /> <br /> ===camel_bcsm_proxy.conf.sample===<br /> <br /> ; NOTE: This module is not loaded automatically, it needs a line in yate.conf:<br /> ; [postload]<br /> ; ${modulepath}/sig/camel_bcsm_proxy${modsuffix}=yes<br /> <br /> [general]<br /> ; Unless explicitly specified, all parameters are applied on reload for new<br /> ; dialogs only<br /> ; All parameters starting with 'addr.' prefix will be put in the first message sent to SSF<br /> <br /> ; application: string: Application parameter in camel messages sent by the module<br /> ; This parameter is required<br /> ; This parameter is not applied on reload<br /> ;application=<br /> <br /> ; gt: string: Global Title to be set in the first message sent in the SSF dialog<br /> ; This parameter is applied on reload for new dialogs only<br /> ; If non empty other calling party address parameters will be set to default values<br /> ; This parameter can be overriden by addr.CallingPartyAddress.gt parameter<br /> ;gt=<br /> <br /> ; servicekey: integer: CAMEL serviceKey to check in received initialDP messages and<br /> ; set when forwarding them to SCFs<br /> ; Allowed interval: 0..2147483647<br /> ; Defaults to 0 if missing or invalid<br /> ; This parameter is applied on reload for new dialogs only<br /> ;servicekey=0<br /> <br /> ; query_scf: boolean: Query for proxied SCFs update when processing initialDP<br /> ; Is enabled a 'scf.query' message will be enqueued and the module will wait<br /> ; for a 'scf.response' message to continue IDP processing<br /> ; The response must return the list of SCFs to proxy<br /> ; The list may be shorter then configured SCFs<br /> ; New SCFs, other then configured ones, will be ignored<br /> ; The following SCF parameters can be overridden: priority, servicekey, errorfatal,<br /> ; handles, waittime and all parameters starting with 'addr.' prefix<br /> ; Defaults to no<br /> ;query_scf=no<br /> <br /> ; component_ttl: integer: Component time to live in milliseconds<br /> ; Minimum allowed value is 1000<br /> ; Defaults to 15000<br /> ;component_ttl=15000<br /> <br /> ; dialog_idle_ttl: integer: Dialog idle (nothing sent/received) time to live in milliseconds<br /> ; Minimum allowed value is 1000<br /> ; It can be set to 0 to keep it alive until the remote party terminates the dialog<br /> ; Defaults to 5000<br /> ;dialog_idle_ttl=5000<br /> <br /> ; dialog_ended_ttl: integer: Ended dialog time to live in milliseconds<br /> ; Minimum allowed value is 1000.<br /> ; It can be set to 0 to remove the dialog after termination<br /> ; Defaults to 0<br /> ;dialog_ended_ttl=0<br /> <br /> ; export_xml_as: string: Specify in which way the XML will be passed along into<br /> ; Yate messages<br /> ; Allowed values are:<br /> ; - string: pass the XML as a string<br /> ; - object: pass the XML as an object<br /> ; - both: pass the XML as a string and object<br /> ; Defaults to object<br /> ;export_xml_as=object<br /> <br /> ; print_msg: boolean/string: Print sent/received messages to output if debug<br /> ; level is at least 9<br /> ; Allowed values are boolean values or 'verbose' string<br /> ; If verbose is specified, the message will be dumped on output<br /> ; Defaults to no<br /> ;print_msg=no<br /> <br /> ; print_xml: boolean/string: Print sent/received XML data to output if debug<br /> ; level is at least 9<br /> ; This parameter is ignored if print_msg is disabled<br /> ; Allowed values are boolean values or 'verbose' string<br /> ; If verbose is specified, XML elements' children, attributes or text will be<br /> ; shown on separate lines<br /> ; Defaults to no<br /> ;print_xml=no<br /> <br /> ; idp_calling_required: boolean: Calling party number is required (non empty) in initialDP<br /> ; Default to yes<br /> ;idp_calling_required=yes<br /> <br /> ; idp_called_required: boolean: Called party number is required (non empty) in initialDP<br /> ; Default to yes<br /> ;idp_called_required=yes<br /> <br /> ; dispatcher_maxthreads: integer: Maximum number of message dispatch threads to use<br /> ; Set to 0 to enqueue messages using yate engine<br /> ; Defaults to 0<br /> ; When reloaded it can't be set to 0 (e.g. once set to a non 0 value it can be changed to<br /> ; non 0 values only)<br /> ;dispatcher_maxthreads=0<br /> <br /> ;dispatcher_priority: string: Default priority of message dispatch threads<br /> ; Can be one of: lowest, low, normal, high, highest<br /> ; High priorities need superuser privileges on POSIX operating systems<br /> ; Low priorities are not recommended except for debugging<br /> ; Defaults to 'normal'<br /> ; This parameter is applied on reload for new threads only<br /> ;dispatcher_priority=normal<br /> <br /> <br /> ;[proxy appname]<br /> ; This section configures a proxied SCF<br /> ; 'appname' is the application name to be used for the SCF<br /> <br /> ; enable: boolean: Enable the SCF<br /> ; Defaults to yes<br /> ;enable=yes<br /> <br /> ; priority: integer: Priority in handling messages from SSF<br /> ; Defaults to 0<br /> ;priority=0<br /> <br /> ; servicekey: integer: Value with which the IDP serviceKey should be rewritten<br /> ; Allowed interval: 0..2147483647<br /> ; Defaults to SSF service key set in 'general' section<br /> ;servicekey=<br /> <br /> ; dp: string: Comma separated list of detection points that should match the one received in IDP<br /> ; in order to contact this SCF<br /> ; Items may be DP value or name<br /> ; Defaults to termAttemptAuthorized if empty or all DPs are invalid<br /> ;dp=termAttemptAuthorized<br /> <br /> ; endfatal: boolean: Indicate whether or not terminate the proxy dialog when this dialog ends<br /> ; Defaults to no<br /> ;endfatal=no<br /> <br /> ; errorfatal: boolean: Indicate whether or not an error or reject component from<br /> ; the SCF should terminate the whole proxy dialog<br /> ; Defaults to no<br /> ;errorfatal=no<br /> <br /> ; local: boolean: The SCF is local (a local application) or external (it passes<br /> ; through the SS7 network to reach it)<br /> ; Defaults to no (external application)<br /> ;local=no<br /> <br /> ; instances: integer: Number of local application instances<br /> ; If non 0 the module will build the required number of SCFs and will pick them using a<br /> ; round-robin algorithm<br /> ; Each application's name will be built from SCF application name concatenated with instance<br /> ; suffix startting from 1<br /> ; E.g.<br /> ; [proxy SCP]<br /> ; instances=2<br /> ; Will build 2 applications: SCP1 and SCP2<br /> ; This parameter is ignored for non local SCFs<br /> ; If non 0 it must be set to a value greater then 1<br /> ; Defaults to 0<br /> ;instance=<br /> <br /> ; handles: string: Comma separated list of operations received from the SSF<br /> ; accepted by this SCF<br /> ; NOTE: Except ERB (Event Report BCSM), which is sent to all SCFs that match the reported DP,<br /> ; all operations that are handled by a SCF should be listed, otherwise the<br /> ; proxy will report to the SSF an error<br /> ;handles=<br /> <br /> ; waittime: integer: Time, in miliseconds, to wait for a result from a SCF<br /> ; while being in Waiting For Instructions state, after which the dialog<br /> ; is aborted<br /> ; Defaults to 3000<br /> ; Minimum allowed value is 1000<br /> ;waittime=3000<br /> <br /> ; All other parameters starting with 'addr.' prefix will be put in dialog begin<br /> ; message sent for this SCF<br /> ; E.g. addr.CalledPartyAddress.route=gt will be put as CalledPartyAddress.route=gt<br /> <br /> ==Proxy Module Test==<br /> This chapter describes how the Camel Proxy module was tested.<br /> <br /> The purpose of the test was to check if the Camel BCSM Proxy module can handle 100CPS.<br /> <br /> The machine used was a Dual Intel Xeon E5620 (Quad Core with HT) = 16CPUs, 32GB RAM with CentOS 6.2<br /> <br /> The setup was:<br/><br /> Yate1 - Call generator, sending calls to Yate3 using SIP<br/><br /> Yate2 - Call generator, sending calls to Yate4 using SIP<br/><br /> Yate3 - Call handling, send initialDP to Yate5 (Proxy)<br/><br /> Yate4 - Call handling, send initialDP to Yate5 (Proxy)<br/><br /> Yate5 - Camel BCSM Proxy<br/><br /> Yate6 - CRBT script<br/><br /> Yate7 - PPS script<br/><br /> Yate8 - PPS script<br /> <br /> <br /> SIP M2PA link M2PA links<br /> Yate1 ---------> Yate3 ------------| |-----------> Yate6 (CRBT)<br /> | |<br /> |-> Yate5 |-----------> Yate7 (PPS)<br /> | |<br /> SIP M2PA link | |-----------> Yate8 (PPS)<br /> Yate2 ---------> Yate4 ------------| <br /> <br /> <br /> '''NOTES:'''<br /> * The sum of both call generators was 110CPS.<br /> * During test top reported ~250%CPU for Proxy.<br /> * All yate instances were running on the same machine.<br /> * 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.<br /> <br /> How success was checked:<br /> * On call generators all calls were answered<br /> * 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')<br /> * On Proxy instance (Yate5) there were no timeouts (this would indicate a SCF is not responding withing default 3 seconds interval)<br /> <br /> ==Configuration==<br /> <br /> ===Script side===<br /> <br /> Configuration of the "camel_proxy.php" script is done through ''config_proxy.php''. This allows setting the following parameters:<br /> <br /> * 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.<br /> <br /> * 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.<br /> <br /> * 3. '''$mynum''' - string. GTT number assigned to this SCP. <br /> <br /> * 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.<br /> <br /> * 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:<br /> ** 5.1. '''serviceKey''' - integer. It represents the service key to be used when constructing an IDP for this SCF..<br /> ** 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.<br /> ** 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).<br /> ** 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.<br /> ** 5.5. '''addr''' - array. It specifies SS7 network addressing parameters. They only need be set for external SCFs. Parameters are usually set here are:<br /> *** '''CalledPartyAddress.route''' - string. It can be set to values: gt/ssn. It specifies how the SCCP address should be routed.<br /> *** '''CalledPartyAddress.ssn''' - integer. It's the SSN number in case of SSN routing.<br /> *** '''CalledPartyAddress.gt''' - string. GTT number digits for the SCF.<br /> *** '''CalledPartyAddress.gt.encoding''' - string. It specifies the encoding for the GT digits. It is usually set to ''bcd''.<br /> *** '''CalledPartyAddress.gt.translation''' - integer. It specifies the GT translation type. It is usually set to ''0''. <br /> *** '''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.<br /> *** '''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.<br /> *** '''CallingPartyAddress.route'''<br /> *** '''CalledPartyAddress.ssn'''<br /> *** '''CallingPartyAddress.gt'''<br /> *** '''CallingPartyAddress.gt.encoding'''<br /> *** '''CallingPartyAddress.gt.translation'''<br /> *** '''CallingPartyAddress.gt.plan'''<br /> *** '''CallingPartyAddress.gt.nature''' <br /> ** 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.<br /> ** 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.<br /> ** 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.<br /> ** 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.<br /> <br /> A working configuration for ''camel_proxy.php'' looks like this:<br /> <br /> <br /> $myServiceKey = "1"; <br /> <br /> $proxyName = "camelProxy"; <br /> <br /> /** <br /> * GTT number of this SCP <br /> */ <br /> $mynum = "8820003"; <br /> <br /> /** <br /> * Transaction timeout after inactivity <br /> */ <br /> $transTimeout = 180; <br /> <br /> /** <br /> * List of configured proxied SCFs <br /> * The following parameters must be configured, all are mandatory: <br /> * serviceKey - value with which the IDP serviceKey should be rewritten <br /> * dp - detection point that should match the one received in IDP in order to contact this SCF <br /> * priority - priority in handling messages from SSF <br /> * errorFatal - whether or not an error or reject component from the SCF should terminate the whole proxy dialoque <br /> * addr - SS7 network addressing parameters. <br /> * local - whether the SCF is local (a local application) or external (it passes through the SS7 network to reach it) <br /> * handles - lists operation received from the SSF that are accepted by this SCF. <br /> * NOTE: Except ERBE, which is sent to all SCFs that match the reported DP, all operations that are handled by a <br /> * SCF should be listed, otherwise the proxy will report to the SSF an error. <br /> * context - if set, rewrites the application context for the dialog established with the SCF, otherwise leaves it as received <br /> * waitTime - time, in seconds, to wait for a result from a SCF while being in Waiting For Instructions state, after which the dialogue <br /> * is aborted. <br /> */ <br /> $scfs = array( <br /> "crbt-scp" => array( <br /> "serviceKey" => 2, <br /> "dp" => "termAttemptAuthorized", <br /> "priority" => 1, <br /> "errorFatal" => false, <br /> "addr" => array(), <br /> "local" => true, <br /> "handles" => array(), <br /> "context" => "", <br /> "waitTime" => 3, <br /> ),<br /> "pps-scp" => array( <br /> "serviceKey" => 99, <br /> "dp" => "termAttemptAuthorized", <br /> "priority" => 2, <br /> "errorFatal" => true, <br /> "addr" => array("CalledPartyAddress.gt" => "8820007", <br /> "CalledPartyAddress.route" => "gt", <br /> "CalledPartyAddress.gt.encoding" => "bcd", <br /> "CalledPartyAddress.gt.tt" => "0", <br /> "CalledPartyAddress.gt.np" => "isdn", <br /> "CalledPartyAddress.gt.nature" => "international", <br /> "CallingPartyAddress.gt" => "8820003", <br /> "CallingPartyAddress.route" => "gt", <br /> "CallingPartyAddress.gt.encoding" => "bcd", <br /> "CallingPartyAddress.gt.tt" => "0", <br /> "CallingPartyAddress.gt.np" => "isdn", <br /> "CallingPartyAddress.gt.nature" => "international", <br /> ), <br /> "local" => false, <br /> "handles" => array("applyChargingReport"), <br /> "context" => "", <br /> "waitTime" => 3, <br /> ), <br /> );<br /> <br /> ===Yate side===<br /> <br /> On the Yate side, the ''camel_map'' module must be configured through ''camel_map.conf''. <br /> <br /> In order for the module to ensure communication with the SSF, a section named <tt>[local name_of_proxy]</tt> must be configured:<br /> <br /> [local proxyName] - what comes after ''local'' will be the name of the application<br /> ;enable=no -- enable this application<br /> translator=scp - which translator should be used. A section named [tcap translatorValue] should be present in the config file.<br /> capabilities=Camel - capabilities supported by this application. CAMEL translator has only one capability and that is ''Camel''.<br /> export_xml_as=both - how to export the XML part: string, object or both?<br /> <br /> A <tt>[tcap name]</tt> section must be configured also. A section looks like this:<br /> <br /> [tcap scp] -- what comes after ''tcap'' will be the name of the translator<br /> ;enable=no -- enable this translator<br /> 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''<br /> host=0.0.0.0 -- address on which to listen for incoming applications<br /> port=0 -- port on which to listen for incoming applications. 0 means that will not build a listener, as the proxy works on messages.<br /> type=CAMEL -- type of translator (MAP/CAMEL). For the intended case, CAMEL should be set<br /> print-messages=true -- whether or not to print TCAP and XML messages in the logs<br /> add-encoding=false -- whether to add encoding attribute to data translated to XML<br /> <br /> <br /> For an external proxied SCF, additional <tt>[local scfName]</tt> and <tt>[tcap name]</tt> sections must be configured:<br /> <br /> [tcap msc]<br /> tcap=tcap-msc<br /> host=0.0.0.0<br /> port=0<br /> type=CAMEL<br /> print-messages=true<br /> add-encoding=false<br /> <br /> [local ext-scp]<br /> ;enable=no<br /> translator=msc<br /> capabilities=Camel<br /> export_xml_as=both<br /> <br /> <br /> '''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.<br /> <br /> ==Proxy Behaviour==<br /> <br /> Bellow, the behaviour of the CAMEL proxy implemented in ''camel_proxy.php'' is described.<br /> <br /> ===General===<br /> <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.<br/><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 /> <br/><br /> The main characteristics of the proxy behaviour are:<br /> * 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.<br /> * 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.<br /> * Invoke components from SCFs will be sent to the SSF and the proxy will keep track to which SCF each component belongs to.<br /> * Result and ReturnError components from the SSF will be passed by the proxy to the SCF that initially sent it.<br /> * 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:<br /> <br /> SSF Proxy SCF 1 SCF 2<br /> |------- Invoke 1 ----------->|WFI | | <br /> | |----- Invoke 1a ------>|WFI | <br /> | |<---- Invoke 2a -------|WFI |<br /> |<------ Invoke 2a -----------|WFI | |<br /> |------- Result 2a ---------->|WFI | |<br /> | |----- Result 2a ------>|WFI |<br /> | |<---- Invoke 3a CWA ---|MON |<br /> | |------------------------------ Invoke 1b --------->|WFI<br /> | |<----------------------------- Invoke 2b ----------|WFI<br /> | |<----------------------------- Invoke CONT 3b CONT-|MON<br /> |<------ Invoke 2b -----------| | |<br /> |<------ Invoke 3a CWA -------|MON | |<br /> | | | |<br /> | | | |<br /> |------- Invoke 4 ----------->|MON | |<br /> | |------ Invoke 4a ----->|MON |<br /> | |------------------------------ Invoke 4b --------->|MON<br /> <br /> * 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.<br /> * 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.<br /> * 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.<br /> * 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.<br /> <br /> ===InitialDP handling===<br /> <br /> The initialDP operation has special handling. Upon receiving this operation from the SSF, the proxy will take the following steps:<br /> * it will check for presence of the ''serviceKey'' parameter. If missing, it will reject the operation and end the dialogue with the SSF.<br /> * 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.<br /> * 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.<br /> * 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.<br /> * 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. <br /> <br /> ===RequestReportBCSM and EventReportBCSM handling===<br /> <br /> <br /> 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. <br /> 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.<br /> <br /> In order to prevent that, proxy does the following:<br /> * the proxy keeps track about how DPs were armed for the dialogue with the SSF, and also for the dialogues with the SCFs.<br /> * 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:<br /> ** 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.<br /> ** 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.<br /> ** 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.<br /> ** 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.<br /> * 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.<br /> <br /> Question: It may turn that SCF requested ''notify'', but got ''interrupted'' EventReportBCSM, right? Is it OK? <br/><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.<br /> <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/><br /> Answer: Yes.<br /> <br /> Question: Are CRBT scripts ready for this scenario?<br/><br /> Answer: Yes, the CRBT script when handling DPs is prepared to handle such a situation.<br /> <br /> Question: It seems better to issue CONT by proxy and change ''interrupted'' to what was originally requested by certain SCF. Not sure.<br/><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.<br /> <br /> ===Multiple Continue/ContinueWithArgument handling===<br /> <br /> <br /> 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.<br /> For that, the proxy will do the following:<br /> * 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.<br /> * if in the message there are only CONT invocations, only the last one is left, the other ones are removed before sending.<br /> * 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.<br /> * 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.<br /> <br /> Question: how does SSF handle multiple CWA?<br/><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.<br /> <br /> ===Leg ID and DP rewriting===<br /> <br /> 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:<br /> * 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.<br /> * 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.<br /> * 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)<br /> * 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.<br /> * leg rewriting handling also aplies to ApplyCharging and ApplyChargingReport operations.<br /> <br /> 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.</div>

Monica https://ss7api.null.ro/index.php/CAMEL_proxy CAMEL proxy 2013-10-28T11:43:48Z

<p>Monica: /* General */</p> <hr /> <div>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.<br /> <br /> The main purpose is to be able to provide CRBT and PPS (PrePaid Service) facilities in parallel.<br /> <br /> The layout for such a scenario will look like this:<br /> <br /> [[File:CamelProxy.png]]<br /> <br /> 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.<br /> The proxy keeps an evidence of these multiple invocations and aggregates them into a single, valid dialogue with the invoking SSP.<br /> <br /> ==Camel Proxy Module Configuration==<br /> <br /> The configuration file is camel_bcsm_proxy.conf<br /> <br /> ===Module configuration===<br /> <br /> ===='general' section====<br /> <br /> '''application''': Application parameter in camel messages sent/handled for SSF dialogs.<br/><br /> This parameter is required and is not applied on reload (can't be changed after module starts).<br/><br /> <br/><br /> '''gt''': Global Title to be set in the first message sent in the SSF dialog.<br/><br /> This parameter is applied on reload.<br/><br /> TCAP address parameters to be set in the first message sent back to SSF can also be set using '''addr.''' prefix.<br/><br /> E.g. GT can be set as '''addr.CallingPartyAddress.gt''' along with other parameters like number nature '''addr.CallingPartyAddress.nature'''.<br/><br /> Setting the GT without other parameters is the same as:<br/><br /> addr.CallingPartyAddress.gt=[GT set]<br/><br /> addr.CallingPartyAddress.route=gt<br/><br /> addr.CallingPartyAddress.gt.encoding=bcd<br/><br /> addr.CallingPartyAddress.gt.translation=0<br/><br /> addr.CallingPartyAddress.gt.plan=isdn<br/><br /> addr.CallingPartyAddress.gt.nature=international<br/><br /> <br/><br /> '''servicekey''': CAMEL serviceKey to check when in received initialDP and set when forwarding them to SCFs.<br/><br /> Allowed interval: 0..2147483647.<br/><br /> Defaults to 0 if missing or invalid.<br/><br /> This parameter is applied on reload for new dialogs only.<br/><br /> <br/><br /> '''query_scf''': Boolean value indicating whether to query for proxied SCFs update when processing initialDP.<br/><br /> Is enabled a 'scf.query' message will be enqueued and the module will wait for a 'scf.response' message to continue IDP processing.<br/><br /> Defaults to no.<br/><br /> <br/><br /> '''print_msg''': boolean/string: Print sent/received messages to output if debug level is at least 9.<br/><br /> Allowed values are boolean values or 'verbose' string.<br/><br /> If verbose is specified, the message will be dumped on output.<br/><br /> Defaults to no.<br/><br /> <br/><br /> '''print_xml''': boolean/string: Print sent/received XML data to output if debug level is at least 9.<br/><br /> This parameter is ignored if print_msg is disabled.<br/><br /> Allowed values are boolean values or 'verbose' string.<br/><br /> If verbose is specified, XML elements' children, attributes or text will be shown on separate lines.<br/><br /> Defaults to no.<br/><br /> <br/><br /> '''idp_calling_required''': boolean: Calling party number is required (non empty) in initialDP.<br/><br /> Default to yes.<br/><br /> <br/><br /> '''idp_called_required''': boolean: Called party number is required (non empty) in initialDP.<br/><br /> Default to yes.<br/><br /> <br/><br /> '''dispatcher_maxthreads''': integer: Maximum number of message dispatch threads to use.<br/><br /> Set to 0 to enqueue messages using yate engine.<br/><br /> Defaults to 0.<br/><br /> 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).<br/><br /> <br/><br /> ====Proxied SCF section(s)====<br /> <br /> '''enable''': boolean: Enable the SCF.<br/><br /> Defaults to yes.<br/><br /> <br/><br /> '''priority''': integer: Priority in handling messages from SSF.<br/><br /> Defaults to 0.<br/><br /> <br/><br /> '''servicekey''': integer: Value with which the IDP serviceKey should be rewritten.<br/><br /> Allowed interval: 0..2147483647.<br/><br /> Defaults to SSF service key set in 'general' section.<br/><br /> <br/><br /> '''dp''': string: Comma separated list of detection points that should match the one received in IDP in order to contact this SCF.<br/><br /> Items may be DP value or name.<br/><br /> Defaults to termAttemptAuthorized if empty or all DPs are invalid.<br/><br /> <br/><br /> '''endfatal''': boolean: Indicate whether or not terminate the proxy dialog when this dialog ends.<br/><br /> Defaults to no.<br/><br /> <br/><br /> '''errorfatal''': boolean: Indicate whether or not an error or reject component from the SCF should terminate the whole proxy dialog.<br/><br /> Defaults to no.<br/><br /> <br/><br /> '''local''': boolean: The SCF is local (a local application) or external (it passes through the SS7 network to reach it).<br/><br /> Defaults to no (external application).<br/><br /> <br/><br /> '''instances''': integer: Number of local application instances.<br/><br /> This parameter is ignored for non local SCFs.<br/><br /> If non 0 it must be set to a value greater then 1.<br/><br /> Defaults to 0.<br/><br /> If non 0 the module will build the required number of SCFs and will pick them using a round-robin algorithm.<br/><br /> Each application's name will be built from SCF application name concatenated with instance suffix startting from 1.<br/><br /> E.g.:<br /> <br /> [proxy SCP]<br /> instances=2<br /> <br /> Will build 2 applications: SCP1 and SCP2.<br/><br /> <br/><br /> '''handles''': string: Comma separated list of operations received from the SSF accepted by this SCF.<br/><br /> 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.<br/><br /> <br/><br /> '''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.<br/><br /> Defaults to 3000.<br/><br /> Minimum allowed value is 1000.<br/><br /> <br/><br /> All other parameters starting with 'addr.' prefix will be put in dialog begin message sent for this SCF.<br/><br /> They should be set for non local SCFs.<br/><br /> Parameters:<br /> * '''addr.CalledPartyAddress.route''' - string. It can be set to values: gt/ssn. It specifies how the SCCP address should be routed.<br /> * '''addr.CalledPartyAddress.ssn''' - integer. It's the SSN number in case of SSN routing.<br /> * '''addr.CalledPartyAddress.gt''' - string. GTT number digits for the SCF.<br /> * '''addr.CalledPartyAddress.gt.encoding''' - string. It specifies the encoding for the GT digits. It is usually set to bcd.<br /> * '''addr.CalledPartyAddress.gt.tt''' - integer. It specifies the GT translation type. It is usually set to 0.<br /> * '''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.<br /> * '''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.<br /> * '''addr.CallingPartyAddress.route'''<br /> * '''addr.CalledPartyAddress.ssn'''<br /> * '''addr.CallingPartyAddress.gt'''<br /> * '''addr.CallingPartyAddress.gt.encoding'''<br /> * '''addr.CallingPartyAddress.gt.tt'''<br /> * '''addr.CallingPartyAddress.gt.np'''<br /> * '''addr.CallingPartyAddress.gt.nature''' <br /> <br /> ====Example====<br /> <br /> [general]<br /> application=camelProxy<br /> servicekey=1<br /> gt=8820003<br /> <br /> [proxy crbt-scp]<br /> servicekey=2<br /> local=true<br /> <br /> [proxy pps-scp]<br /> servicekey=99<br /> priority=2<br /> errorfatal=true<br /> handles=applyChargingReport<br /> addr.CalledPartyAddress.gt=8820007<br /> addr.CalledPartyAddress.route=gt<br /> addr.CalledPartyAddress.gt.encoding=bcd<br /> addr.CalledPartyAddress.gt.tt=0<br /> addr.CalledPartyAddress.gt.np=isdn<br /> addr.CalledPartyAddress.gt.nature=international<br /> addr.CallingPartyAddress.gt=8820003<br /> addr.CallingPartyAddress.route=gt<br /> addr.CallingPartyAddress.gt.encoding=bcd<br /> addr.CallingPartyAddress.gt.tt=0<br /> addr.CallingPartyAddress.gt.np=isdn<br /> addr.CallingPartyAddress.gt.nature=international<br /> <br /> <br /> === camel_map configuration ===<br /> <br /> [local camelProxy]<br /> translator=scp_proxy<br /> capabilities=Camel<br /> <br /> [tcap scp_proxy]<br /> type=CAMEL<br /> tcap=tcap_msc<br /> port=0<br /> <br /> [local pps-scp]<br /> translator=scp_pps<br /> capabilities=Camel<br /> <br /> [tcap scp_pps]<br /> type=CAMEL<br /> tcap=tcap_pps<br /> port=0<br /> <br /> ===camel_bcsm_proxy.conf.sample===<br /> <br /> ; NOTE: This module is not loaded automatically, it needs a line in yate.conf:<br /> ; [postload]<br /> ; ${modulepath}/sig/camel_bcsm_proxy${modsuffix}=yes<br /> <br /> [general]<br /> ; Unless explicitly specified, all parameters are applied on reload for new<br /> ; dialogs only<br /> ; All parameters starting with 'addr.' prefix will be put in the first message sent to SSF<br /> <br /> ; application: string: Application parameter in camel messages sent by the module<br /> ; This parameter is required<br /> ; This parameter is not applied on reload<br /> ;application=<br /> <br /> ; gt: string: Global Title to be set in the first message sent in the SSF dialog<br /> ; This parameter is applied on reload for new dialogs only<br /> ; If non empty other calling party address parameters will be set to default values<br /> ; This parameter can be overriden by addr.CallingPartyAddress.gt parameter<br /> ;gt=<br /> <br /> ; servicekey: integer: CAMEL serviceKey to check in received initialDP messages and<br /> ; set when forwarding them to SCFs<br /> ; Allowed interval: 0..2147483647<br /> ; Defaults to 0 if missing or invalid<br /> ; This parameter is applied on reload for new dialogs only<br /> ;servicekey=0<br /> <br /> ; query_scf: boolean: Query for proxied SCFs update when processing initialDP<br /> ; Is enabled a 'scf.query' message will be enqueued and the module will wait<br /> ; for a 'scf.response' message to continue IDP processing<br /> ; The response must return the list of SCFs to proxy<br /> ; The list may be shorter then configured SCFs<br /> ; New SCFs, other then configured ones, will be ignored<br /> ; The following SCF parameters can be overridden: priority, servicekey, errorfatal,<br /> ; handles, waittime and all parameters starting with 'addr.' prefix<br /> ; Defaults to no<br /> ;query_scf=no<br /> <br /> ; component_ttl: integer: Component time to live in milliseconds<br /> ; Minimum allowed value is 1000<br /> ; Defaults to 15000<br /> ;component_ttl=15000<br /> <br /> ; dialog_idle_ttl: integer: Dialog idle (nothing sent/received) time to live in milliseconds<br /> ; Minimum allowed value is 1000<br /> ; It can be set to 0 to keep it alive until the remote party terminates the dialog<br /> ; Defaults to 5000<br /> ;dialog_idle_ttl=5000<br /> <br /> ; dialog_ended_ttl: integer: Ended dialog time to live in milliseconds<br /> ; Minimum allowed value is 1000.<br /> ; It can be set to 0 to remove the dialog after termination<br /> ; Defaults to 0<br /> ;dialog_ended_ttl=0<br /> <br /> ; export_xml_as: string: Specify in which way the XML will be passed along into<br /> ; Yate messages<br /> ; Allowed values are:<br /> ; - string: pass the XML as a string<br /> ; - object: pass the XML as an object<br /> ; - both: pass the XML as a string and object<br /> ; Defaults to object<br /> ;export_xml_as=object<br /> <br /> ; print_msg: boolean/string: Print sent/received messages to output if debug<br /> ; level is at least 9<br /> ; Allowed values are boolean values or 'verbose' string<br /> ; If verbose is specified, the message will be dumped on output<br /> ; Defaults to no<br /> ;print_msg=no<br /> <br /> ; print_xml: boolean/string: Print sent/received XML data to output if debug<br /> ; level is at least 9<br /> ; This parameter is ignored if print_msg is disabled<br /> ; Allowed values are boolean values or 'verbose' string<br /> ; If verbose is specified, XML elements' children, attributes or text will be<br /> ; shown on separate lines<br /> ; Defaults to no<br /> ;print_xml=no<br /> <br /> ; idp_calling_required: boolean: Calling party number is required (non empty) in initialDP<br /> ; Default to yes<br /> ;idp_calling_required=yes<br /> <br /> ; idp_called_required: boolean: Called party number is required (non empty) in initialDP<br /> ; Default to yes<br /> ;idp_called_required=yes<br /> <br /> ; dispatcher_maxthreads: integer: Maximum number of message dispatch threads to use<br /> ; Set to 0 to enqueue messages using yate engine<br /> ; Defaults to 0<br /> ; When reloaded it can't be set to 0 (e.g. once set to a non 0 value it can be changed to<br /> ; non 0 values only)<br /> ;dispatcher_maxthreads=0<br /> <br /> ;dispatcher_priority: string: Default priority of message dispatch threads<br /> ; Can be one of: lowest, low, normal, high, highest<br /> ; High priorities need superuser privileges on POSIX operating systems<br /> ; Low priorities are not recommended except for debugging<br /> ; Defaults to 'normal'<br /> ; This parameter is applied on reload for new threads only<br /> ;dispatcher_priority=normal<br /> <br /> <br /> ;[proxy appname]<br /> ; This section configures a proxied SCF<br /> ; 'appname' is the application name to be used for the SCF<br /> <br /> ; enable: boolean: Enable the SCF<br /> ; Defaults to yes<br /> ;enable=yes<br /> <br /> ; priority: integer: Priority in handling messages from SSF<br /> ; Defaults to 0<br /> ;priority=0<br /> <br /> ; servicekey: integer: Value with which the IDP serviceKey should be rewritten<br /> ; Allowed interval: 0..2147483647<br /> ; Defaults to SSF service key set in 'general' section<br /> ;servicekey=<br /> <br /> ; dp: string: Comma separated list of detection points that should match the one received in IDP<br /> ; in order to contact this SCF<br /> ; Items may be DP value or name<br /> ; Defaults to termAttemptAuthorized if empty or all DPs are invalid<br /> ;dp=termAttemptAuthorized<br /> <br /> ; endfatal: boolean: Indicate whether or not terminate the proxy dialog when this dialog ends<br /> ; Defaults to no<br /> ;endfatal=no<br /> <br /> ; errorfatal: boolean: Indicate whether or not an error or reject component from<br /> ; the SCF should terminate the whole proxy dialog<br /> ; Defaults to no<br /> ;errorfatal=no<br /> <br /> ; local: boolean: The SCF is local (a local application) or external (it passes<br /> ; through the SS7 network to reach it)<br /> ; Defaults to no (external application)<br /> ;local=no<br /> <br /> ; instances: integer: Number of local application instances<br /> ; If non 0 the module will build the required number of SCFs and will pick them using a<br /> ; round-robin algorithm<br /> ; Each application's name will be built from SCF application name concatenated with instance<br /> ; suffix startting from 1<br /> ; E.g.<br /> ; [proxy SCP]<br /> ; instances=2<br /> ; Will build 2 applications: SCP1 and SCP2<br /> ; This parameter is ignored for non local SCFs<br /> ; If non 0 it must be set to a value greater then 1<br /> ; Defaults to 0<br /> ;instance=<br /> <br /> ; handles: string: Comma separated list of operations received from the SSF<br /> ; accepted by this SCF<br /> ; NOTE: Except ERB (Event Report BCSM), which is sent to all SCFs that match the reported DP,<br /> ; all operations that are handled by a SCF should be listed, otherwise the<br /> ; proxy will report to the SSF an error<br /> ;handles=<br /> <br /> ; waittime: integer: Time, in miliseconds, to wait for a result from a SCF<br /> ; while being in Waiting For Instructions state, after which the dialog<br /> ; is aborted<br /> ; Defaults to 3000<br /> ; Minimum allowed value is 1000<br /> ;waittime=3000<br /> <br /> ; All other parameters starting with 'addr.' prefix will be put in dialog begin<br /> ; message sent for this SCF<br /> ; E.g. addr.CalledPartyAddress.route=gt will be put as CalledPartyAddress.route=gt<br /> <br /> ==Proxy Module Test==<br /> This chapter describes how the Camel Proxy module was tested.<br /> <br /> The purpose of the test was to check if the Camel BCSM Proxy module can handle 100CPS.<br /> <br /> The machine used was a Dual Intel Xeon E5620 (Quad Core with HT) = 16CPUs, 32GB RAM with CentOS 6.2<br /> <br /> The setup was:<br/><br /> Yate1 - Call generator, sending calls to Yate3 using SIP<br/><br /> Yate2 - Call generator, sending calls to Yate4 using SIP<br/><br /> Yate3 - Call handling, send initialDP to Yate5 (Proxy)<br/><br /> Yate4 - Call handling, send initialDP to Yate5 (Proxy)<br/><br /> Yate5 - Camel BCSM Proxy<br/><br /> Yate6 - CRBT script<br/><br /> Yate7 - PPS script<br/><br /> Yate8 - PPS script<br /> <br /> <br /> SIP M2PA link M2PA links<br /> Yate1 ---------> Yate3 ------------| |-----------> Yate6 (CRBT)<br /> | |<br /> |-> Yate5 |-----------> Yate7 (PPS)<br /> | |<br /> SIP M2PA link | |-----------> Yate8 (PPS)<br /> Yate2 ---------> Yate4 ------------| <br /> <br /> <br /> '''NOTES:'''<br /> * The sum of both call generators was 110CPS.<br /> * During test top reported ~250%CPU for Proxy.<br /> * All yate instances were running on the same machine.<br /> * 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.<br /> <br /> How success was checked:<br /> * On call generators all calls were answered<br /> * 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')<br /> * On Proxy instance (Yate5) there were no timeouts (this would indicate a SCF is not responding withing default 3 seconds interval)<br /> <br /> ==Configuration==<br /> <br /> ===Script side===<br /> <br /> Configuration of the "camel_proxy.php" script is done through ''config_proxy.php''. This allows setting the following parameters:<br /> <br /> * 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.<br /> <br /> * 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.<br /> <br /> * 3. '''$mynum''' - string. GTT number assigned to this SCP. <br /> <br /> * 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.<br /> <br /> * 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:<br /> ** 5.1. '''serviceKey''' - integer. It represents the service key to be used when constructing an IDP for this SCF..<br /> ** 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.<br /> ** 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).<br /> ** 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.<br /> ** 5.5. '''addr''' - array. It specifies SS7 network addressing parameters. They only need be set for external SCFs. Parameters are usually set here are:<br /> *** '''CalledPartyAddress.route''' - string. It can be set to values: gt/ssn. It specifies how the SCCP address should be routed.<br /> *** '''CalledPartyAddress.ssn''' - integer. It's the SSN number in case of SSN routing.<br /> *** '''CalledPartyAddress.gt''' - string. GTT number digits for the SCF.<br /> *** '''CalledPartyAddress.gt.encoding''' - string. It specifies the encoding for the GT digits. It is usually set to ''bcd''.<br /> *** '''CalledPartyAddress.gt.translation''' - integer. It specifies the GT translation type. It is usually set to ''0''. <br /> *** '''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.<br /> *** '''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.<br /> *** '''CallingPartyAddress.route'''<br /> *** '''CalledPartyAddress.ssn'''<br /> *** '''CallingPartyAddress.gt'''<br /> *** '''CallingPartyAddress.gt.encoding'''<br /> *** '''CallingPartyAddress.gt.translation'''<br /> *** '''CallingPartyAddress.gt.plan'''<br /> *** '''CallingPartyAddress.gt.nature''' <br /> ** 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.<br /> ** 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.<br /> ** 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.<br /> ** 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.<br /> <br /> A working configuration for ''camel_proxy.php'' looks like this:<br /> <br /> <br /> $myServiceKey = "1"; <br /> <br /> $proxyName = "camelProxy"; <br /> <br /> /** <br /> * GTT number of this SCP <br /> */ <br /> $mynum = "8820003"; <br /> <br /> /** <br /> * Transaction timeout after inactivity <br /> */ <br /> $transTimeout = 180; <br /> <br /> /** <br /> * List of configured proxied SCFs <br /> * The following parameters must be configured, all are mandatory: <br /> * serviceKey - value with which the IDP serviceKey should be rewritten <br /> * dp - detection point that should match the one received in IDP in order to contact this SCF <br /> * priority - priority in handling messages from SSF <br /> * errorFatal - whether or not an error or reject component from the SCF should terminate the whole proxy dialoque <br /> * addr - SS7 network addressing parameters. <br /> * local - whether the SCF is local (a local application) or external (it passes through the SS7 network to reach it) <br /> * handles - lists operation received from the SSF that are accepted by this SCF. <br /> * NOTE: Except ERBE, which is sent to all SCFs that match the reported DP, all operations that are handled by a <br /> * SCF should be listed, otherwise the proxy will report to the SSF an error. <br /> * context - if set, rewrites the application context for the dialog established with the SCF, otherwise leaves it as received <br /> * waitTime - time, in seconds, to wait for a result from a SCF while being in Waiting For Instructions state, after which the dialogue <br /> * is aborted. <br /> */ <br /> $scfs = array( <br /> "crbt-scp" => array( <br /> "serviceKey" => 2, <br /> "dp" => "termAttemptAuthorized", <br /> "priority" => 1, <br /> "errorFatal" => false, <br /> "addr" => array(), <br /> "local" => true, <br /> "handles" => array(), <br /> "context" => "", <br /> "waitTime" => 3, <br /> ),<br /> "pps-scp" => array( <br /> "serviceKey" => 99, <br /> "dp" => "termAttemptAuthorized", <br /> "priority" => 2, <br /> "errorFatal" => true, <br /> "addr" => array("CalledPartyAddress.gt" => "8820007", <br /> "CalledPartyAddress.route" => "gt", <br /> "CalledPartyAddress.gt.encoding" => "bcd", <br /> "CalledPartyAddress.gt.tt" => "0", <br /> "CalledPartyAddress.gt.np" => "isdn", <br /> "CalledPartyAddress.gt.nature" => "international", <br /> "CallingPartyAddress.gt" => "8820003", <br /> "CallingPartyAddress.route" => "gt", <br /> "CallingPartyAddress.gt.encoding" => "bcd", <br /> "CallingPartyAddress.gt.tt" => "0", <br /> "CallingPartyAddress.gt.np" => "isdn", <br /> "CallingPartyAddress.gt.nature" => "international", <br /> ), <br /> "local" => false, <br /> "handles" => array("applyChargingReport"), <br /> "context" => "", <br /> "waitTime" => 3, <br /> ), <br /> );<br /> <br /> ===Yate side===<br /> <br /> On the Yate side, the ''camel_map'' module must be configured through ''camel_map.conf''. <br /> <br /> In order for the module to ensure communication with the SSF, a section named <tt>[local name_of_proxy]</tt> must be configured:<br /> <br /> [local proxyName] - what comes after ''local'' will be the name of the application<br /> ;enable=no -- enable this application<br /> translator=scp - which translator should be used. A section named [tcap translatorValue] should be present in the config file.<br /> capabilities=Camel - capabilities supported by this application. CAMEL translator has only one capability and that is ''Camel''.<br /> export_xml_as=both - how to export the XML part: string, object or both?<br /> <br /> A <tt>[tcap name]</tt> section must be configured also. A section looks like this:<br /> <br /> [tcap scp] -- what comes after ''tcap'' will be the name of the translator<br /> ;enable=no -- enable this translator<br /> 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''<br /> host=0.0.0.0 -- address on which to listen for incoming applications<br /> port=0 -- port on which to listen for incoming applications. 0 means that will not build a listener, as the proxy works on messages.<br /> type=CAMEL -- type of translator (MAP/CAMEL). For the intended case, CAMEL should be set<br /> print-messages=true -- whether or not to print TCAP and XML messages in the logs<br /> add-encoding=false -- whether to add encoding attribute to data translated to XML<br /> <br /> <br /> For an external proxied SCF, additional <tt>[local scfName]</tt> and <tt>[tcap name]</tt> sections must be configured:<br /> <br /> [tcap msc]<br /> tcap=tcap-msc<br /> host=0.0.0.0<br /> port=0<br /> type=CAMEL<br /> print-messages=true<br /> add-encoding=false<br /> <br /> [local ext-scp]<br /> ;enable=no<br /> translator=msc<br /> capabilities=Camel<br /> export_xml_as=both<br /> <br /> <br /> '''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.<br /> <br /> ==Proxy Behaviour==<br /> <br /> Bellow, the behaviour of the CAMEL proxy implemented in ''camel_proxy.php'' is described.<br /> <br /> ===General===<br /> <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.<br/><br /> <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 /> <br/><br /> The main characteristics of the proxy behaviour are:<br /> * 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.<br /> * 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.<br /> * Invoke components from SCFs will be sent to the SSF and the proxy will keep track to which SCF each component belongs to.<br /> * Result and ReturnError components from the SSF will be passed by the proxy to the SCF that initially sent it.<br /> * 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:<br /> <br /> SSF Proxy SCF 1 SCF 2<br /> |------- Invoke 1 ----------->|WFI | | <br /> | |----- Invoke 1a ------>|WFI | <br /> | |<---- Invoke 2a -------|WFI |<br /> |<------ Invoke 2a -----------|WFI | |<br /> |------- Result 2a ---------->|WFI | |<br /> | |----- Result 2a ------>|WFI |<br /> | |<---- Invoke 3a CWA ---|MON |<br /> | |------------------------------ Invoke 1b --------->|WFI<br /> | |<----------------------------- Invoke 2b ----------|WFI<br /> | |<----------------------------- Invoke CONT 3b CONT-|MON<br /> |<------ Invoke 2b -----------| | |<br /> |<------ Invoke 3a CWA -------|MON | |<br /> | | | |<br /> | | | |<br /> |------- Invoke 4 ----------->|MON | |<br /> | |------ Invoke 4a ----->|MON |<br /> | |------------------------------ Invoke 4b --------->|MON<br /> <br /> * 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.<br /> * 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.<br /> * 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.<br /> * 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.<br /> <br /> ===InitialDP handling===<br /> <br /> The initialDP operation has special handling. Upon receiving this operation from the SSF, the proxy will take the following steps:<br /> * it will check for presence of the ''serviceKey'' parameter. If missing, it will reject the operation and end the dialogue with the SSF.<br /> * 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.<br /> * 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.<br /> * 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.<br /> * 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. <br /> <br /> ===RequestReportBCSM and EventReportBCSM handling===<br /> <br /> <br /> 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. <br /> 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.<br /> <br /> In order to prevent that, proxy does the following:<br /> * the proxy keeps track about how DPs were armed for the dialogue with the SSF, and also for the dialogues with the SCFs.<br /> * 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:<br /> ** 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.<br /> ** 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.<br /> ** 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.<br /> ** 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.<br /> * 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.<br /> <br /> Question: It may turn that SCF requested ''notify'', but got ''interrupted'' EventReportBCSM, right? Is it OK? <br/><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.<br /> <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/><br /> Answer: Yes.<br /> <br /> Question: Are CRBT scripts ready for this scenario?<br/><br /> Answer: Yes, the CRBT script when handling DPs is prepared to handle such a situation.<br /> <br /> Question: It seems better to issue CONT by proxy and change ''interrupted'' to what was originally requested by certain SCF. Not sure.<br/><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.<br /> <br /> ===Multiple Continue/ContinueWithArgument handling===<br /> <br /> <br /> 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.<br /> For that, the proxy will do the following:<br /> * 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.<br /> * if in the message there are only CONT invocations, only the last one is left, the other ones are removed before sending.<br /> * 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.<br /> * 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.<br /> <br /> Question: how does SSF handle multiple CWA?<br/><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.<br /> <br /> ===Leg ID and DP rewriting===<br /> <br /> 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:<br /> * 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.<br /> * 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.<br /> * 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)<br /> * 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.<br /> * leg rewriting handling also aplies to ApplyCharging and ApplyChargingReport operations.<br /> <br /> 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.</div>

Monica https://ss7api.null.ro/index.php/CAMEL_proxy CAMEL proxy 2013-10-28T11:43:07Z

<p>Monica: /* RequestReportBCSM and EventReportBCSM handling */</p> <hr /> <div>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.<br /> <br /> The main purpose is to be able to provide CRBT and PPS (PrePaid Service) facilities in parallel.<br /> <br /> The layout for such a scenario will look like this:<br /> <br /> [[File:CamelProxy.png]]<br /> <br /> 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.<br /> The proxy keeps an evidence of these multiple invocations and aggregates them into a single, valid dialogue with the invoking SSP.<br /> <br /> ==Camel Proxy Module Configuration==<br /> <br /> The configuration file is camel_bcsm_proxy.conf<br /> <br /> ===Module configuration===<br /> <br /> ===='general' section====<br /> <br /> '''application''': Application parameter in camel messages sent/handled for SSF dialogs.<br/><br /> This parameter is required and is not applied on reload (can't be changed after module starts).<br/><br /> <br/><br /> '''gt''': Global Title to be set in the first message sent in the SSF dialog.<br/><br /> This parameter is applied on reload.<br/><br /> TCAP address parameters to be set in the first message sent back to SSF can also be set using '''addr.''' prefix.<br/><br /> E.g. GT can be set as '''addr.CallingPartyAddress.gt''' along with other parameters like number nature '''addr.CallingPartyAddress.nature'''.<br/><br /> Setting the GT without other parameters is the same as:<br/><br /> addr.CallingPartyAddress.gt=[GT set]<br/><br /> addr.CallingPartyAddress.route=gt<br/><br /> addr.CallingPartyAddress.gt.encoding=bcd<br/><br /> addr.CallingPartyAddress.gt.translation=0<br/><br /> addr.CallingPartyAddress.gt.plan=isdn<br/><br /> addr.CallingPartyAddress.gt.nature=international<br/><br /> <br/><br /> '''servicekey''': CAMEL serviceKey to check when in received initialDP and set when forwarding them to SCFs.<br/><br /> Allowed interval: 0..2147483647.<br/><br /> Defaults to 0 if missing or invalid.<br/><br /> This parameter is applied on reload for new dialogs only.<br/><br /> <br/><br /> '''query_scf''': Boolean value indicating whether to query for proxied SCFs update when processing initialDP.<br/><br /> Is enabled a 'scf.query' message will be enqueued and the module will wait for a 'scf.response' message to continue IDP processing.<br/><br /> Defaults to no.<br/><br /> <br/><br /> '''print_msg''': boolean/string: Print sent/received messages to output if debug level is at least 9.<br/><br /> Allowed values are boolean values or 'verbose' string.<br/><br /> If verbose is specified, the message will be dumped on output.<br/><br /> Defaults to no.<br/><br /> <br/><br /> '''print_xml''': boolean/string: Print sent/received XML data to output if debug level is at least 9.<br/><br /> This parameter is ignored if print_msg is disabled.<br/><br /> Allowed values are boolean values or 'verbose' string.<br/><br /> If verbose is specified, XML elements' children, attributes or text will be shown on separate lines.<br/><br /> Defaults to no.<br/><br /> <br/><br /> '''idp_calling_required''': boolean: Calling party number is required (non empty) in initialDP.<br/><br /> Default to yes.<br/><br /> <br/><br /> '''idp_called_required''': boolean: Called party number is required (non empty) in initialDP.<br/><br /> Default to yes.<br/><br /> <br/><br /> '''dispatcher_maxthreads''': integer: Maximum number of message dispatch threads to use.<br/><br /> Set to 0 to enqueue messages using yate engine.<br/><br /> Defaults to 0.<br/><br /> 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).<br/><br /> <br/><br /> ====Proxied SCF section(s)====<br /> <br /> '''enable''': boolean: Enable the SCF.<br/><br /> Defaults to yes.<br/><br /> <br/><br /> '''priority''': integer: Priority in handling messages from SSF.<br/><br /> Defaults to 0.<br/><br /> <br/><br /> '''servicekey''': integer: Value with which the IDP serviceKey should be rewritten.<br/><br /> Allowed interval: 0..2147483647.<br/><br /> Defaults to SSF service key set in 'general' section.<br/><br /> <br/><br /> '''dp''': string: Comma separated list of detection points that should match the one received in IDP in order to contact this SCF.<br/><br /> Items may be DP value or name.<br/><br /> Defaults to termAttemptAuthorized if empty or all DPs are invalid.<br/><br /> <br/><br /> '''endfatal''': boolean: Indicate whether or not terminate the proxy dialog when this dialog ends.<br/><br /> Defaults to no.<br/><br /> <br/><br /> '''errorfatal''': boolean: Indicate whether or not an error or reject component from the SCF should terminate the whole proxy dialog.<br/><br /> Defaults to no.<br/><br /> <br/><br /> '''local''': boolean: The SCF is local (a local application) or external (it passes through the SS7 network to reach it).<br/><br /> Defaults to no (external application).<br/><br /> <br/><br /> '''instances''': integer: Number of local application instances.<br/><br /> This parameter is ignored for non local SCFs.<br/><br /> If non 0 it must be set to a value greater then 1.<br/><br /> Defaults to 0.<br/><br /> If non 0 the module will build the required number of SCFs and will pick them using a round-robin algorithm.<br/><br /> Each application's name will be built from SCF application name concatenated with instance suffix startting from 1.<br/><br /> E.g.:<br /> <br /> [proxy SCP]<br /> instances=2<br /> <br /> Will build 2 applications: SCP1 and SCP2.<br/><br /> <br/><br /> '''handles''': string: Comma separated list of operations received from the SSF accepted by this SCF.<br/><br /> 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.<br/><br /> <br/><br /> '''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.<br/><br /> Defaults to 3000.<br/><br /> Minimum allowed value is 1000.<br/><br /> <br/><br /> All other parameters starting with 'addr.' prefix will be put in dialog begin message sent for this SCF.<br/><br /> They should be set for non local SCFs.<br/><br /> Parameters:<br /> * '''addr.CalledPartyAddress.route''' - string. It can be set to values: gt/ssn. It specifies how the SCCP address should be routed.<br /> * '''addr.CalledPartyAddress.ssn''' - integer. It's the SSN number in case of SSN routing.<br /> * '''addr.CalledPartyAddress.gt''' - string. GTT number digits for the SCF.<br /> * '''addr.CalledPartyAddress.gt.encoding''' - string. It specifies the encoding for the GT digits. It is usually set to bcd.<br /> * '''addr.CalledPartyAddress.gt.tt''' - integer. It specifies the GT translation type. It is usually set to 0.<br /> * '''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.<br /> * '''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.<br /> * '''addr.CallingPartyAddress.route'''<br /> * '''addr.CalledPartyAddress.ssn'''<br /> * '''addr.CallingPartyAddress.gt'''<br /> * '''addr.CallingPartyAddress.gt.encoding'''<br /> * '''addr.CallingPartyAddress.gt.tt'''<br /> * '''addr.CallingPartyAddress.gt.np'''<br /> * '''addr.CallingPartyAddress.gt.nature''' <br /> <br /> ====Example====<br /> <br /> [general]<br /> application=camelProxy<br /> servicekey=1<br /> gt=8820003<br /> <br /> [proxy crbt-scp]<br /> servicekey=2<br /> local=true<br /> <br /> [proxy pps-scp]<br /> servicekey=99<br /> priority=2<br /> errorfatal=true<br /> handles=applyChargingReport<br /> addr.CalledPartyAddress.gt=8820007<br /> addr.CalledPartyAddress.route=gt<br /> addr.CalledPartyAddress.gt.encoding=bcd<br /> addr.CalledPartyAddress.gt.tt=0<br /> addr.CalledPartyAddress.gt.np=isdn<br /> addr.CalledPartyAddress.gt.nature=international<br /> addr.CallingPartyAddress.gt=8820003<br /> addr.CallingPartyAddress.route=gt<br /> addr.CallingPartyAddress.gt.encoding=bcd<br /> addr.CallingPartyAddress.gt.tt=0<br /> addr.CallingPartyAddress.gt.np=isdn<br /> addr.CallingPartyAddress.gt.nature=international<br /> <br /> <br /> === camel_map configuration ===<br /> <br /> [local camelProxy]<br /> translator=scp_proxy<br /> capabilities=Camel<br /> <br /> [tcap scp_proxy]<br /> type=CAMEL<br /> tcap=tcap_msc<br /> port=0<br /> <br /> [local pps-scp]<br /> translator=scp_pps<br /> capabilities=Camel<br /> <br /> [tcap scp_pps]<br /> type=CAMEL<br /> tcap=tcap_pps<br /> port=0<br /> <br /> ===camel_bcsm_proxy.conf.sample===<br /> <br /> ; NOTE: This module is not loaded automatically, it needs a line in yate.conf:<br /> ; [postload]<br /> ; ${modulepath}/sig/camel_bcsm_proxy${modsuffix}=yes<br /> <br /> [general]<br /> ; Unless explicitly specified, all parameters are applied on reload for new<br /> ; dialogs only<br /> ; All parameters starting with 'addr.' prefix will be put in the first message sent to SSF<br /> <br /> ; application: string: Application parameter in camel messages sent by the module<br /> ; This parameter is required<br /> ; This parameter is not applied on reload<br /> ;application=<br /> <br /> ; gt: string: Global Title to be set in the first message sent in the SSF dialog<br /> ; This parameter is applied on reload for new dialogs only<br /> ; If non empty other calling party address parameters will be set to default values<br /> ; This parameter can be overriden by addr.CallingPartyAddress.gt parameter<br /> ;gt=<br /> <br /> ; servicekey: integer: CAMEL serviceKey to check in received initialDP messages and<br /> ; set when forwarding them to SCFs<br /> ; Allowed interval: 0..2147483647<br /> ; Defaults to 0 if missing or invalid<br /> ; This parameter is applied on reload for new dialogs only<br /> ;servicekey=0<br /> <br /> ; query_scf: boolean: Query for proxied SCFs update when processing initialDP<br /> ; Is enabled a 'scf.query' message will be enqueued and the module will wait<br /> ; for a 'scf.response' message to continue IDP processing<br /> ; The response must return the list of SCFs to proxy<br /> ; The list may be shorter then configured SCFs<br /> ; New SCFs, other then configured ones, will be ignored<br /> ; The following SCF parameters can be overridden: priority, servicekey, errorfatal,<br /> ; handles, waittime and all parameters starting with 'addr.' prefix<br /> ; Defaults to no<br /> ;query_scf=no<br /> <br /> ; component_ttl: integer: Component time to live in milliseconds<br /> ; Minimum allowed value is 1000<br /> ; Defaults to 15000<br /> ;component_ttl=15000<br /> <br /> ; dialog_idle_ttl: integer: Dialog idle (nothing sent/received) time to live in milliseconds<br /> ; Minimum allowed value is 1000<br /> ; It can be set to 0 to keep it alive until the remote party terminates the dialog<br /> ; Defaults to 5000<br /> ;dialog_idle_ttl=5000<br /> <br /> ; dialog_ended_ttl: integer: Ended dialog time to live in milliseconds<br /> ; Minimum allowed value is 1000.<br /> ; It can be set to 0 to remove the dialog after termination<br /> ; Defaults to 0<br /> ;dialog_ended_ttl=0<br /> <br /> ; export_xml_as: string: Specify in which way the XML will be passed along into<br /> ; Yate messages<br /> ; Allowed values are:<br /> ; - string: pass the XML as a string<br /> ; - object: pass the XML as an object<br /> ; - both: pass the XML as a string and object<br /> ; Defaults to object<br /> ;export_xml_as=object<br /> <br /> ; print_msg: boolean/string: Print sent/received messages to output if debug<br /> ; level is at least 9<br /> ; Allowed values are boolean values or 'verbose' string<br /> ; If verbose is specified, the message will be dumped on output<br /> ; Defaults to no<br /> ;print_msg=no<br /> <br /> ; print_xml: boolean/string: Print sent/received XML data to output if debug<br /> ; level is at least 9<br /> ; This parameter is ignored if print_msg is disabled<br /> ; Allowed values are boolean values or 'verbose' string<br /> ; If verbose is specified, XML elements' children, attributes or text will be<br /> ; shown on separate lines<br /> ; Defaults to no<br /> ;print_xml=no<br /> <br /> ; idp_calling_required: boolean: Calling party number is required (non empty) in initialDP<br /> ; Default to yes<br /> ;idp_calling_required=yes<br /> <br /> ; idp_called_required: boolean: Called party number is required (non empty) in initialDP<br /> ; Default to yes<br /> ;idp_called_required=yes<br /> <br /> ; dispatcher_maxthreads: integer: Maximum number of message dispatch threads to use<br /> ; Set to 0 to enqueue messages using yate engine<br /> ; Defaults to 0<br /> ; When reloaded it can't be set to 0 (e.g. once set to a non 0 value it can be changed to<br /> ; non 0 values only)<br /> ;dispatcher_maxthreads=0<br /> <br /> ;dispatcher_priority: string: Default priority of message dispatch threads<br /> ; Can be one of: lowest, low, normal, high, highest<br /> ; High priorities need superuser privileges on POSIX operating systems<br /> ; Low priorities are not recommended except for debugging<br /> ; Defaults to 'normal'<br /> ; This parameter is applied on reload for new threads only<br /> ;dispatcher_priority=normal<br /> <br /> <br /> ;[proxy appname]<br /> ; This section configures a proxied SCF<br /> ; 'appname' is the application name to be used for the SCF<br /> <br /> ; enable: boolean: Enable the SCF<br /> ; Defaults to yes<br /> ;enable=yes<br /> <br /> ; priority: integer: Priority in handling messages from SSF<br /> ; Defaults to 0<br /> ;priority=0<br /> <br /> ; servicekey: integer: Value with which the IDP serviceKey should be rewritten<br /> ; Allowed interval: 0..2147483647<br /> ; Defaults to SSF service key set in 'general' section<br /> ;servicekey=<br /> <br /> ; dp: string: Comma separated list of detection points that should match the one received in IDP<br /> ; in order to contact this SCF<br /> ; Items may be DP value or name<br /> ; Defaults to termAttemptAuthorized if empty or all DPs are invalid<br /> ;dp=termAttemptAuthorized<br /> <br /> ; endfatal: boolean: Indicate whether or not terminate the proxy dialog when this dialog ends<br /> ; Defaults to no<br /> ;endfatal=no<br /> <br /> ; errorfatal: boolean: Indicate whether or not an error or reject component from<br /> ; the SCF should terminate the whole proxy dialog<br /> ; Defaults to no<br /> ;errorfatal=no<br /> <br /> ; local: boolean: The SCF is local (a local application) or external (it passes<br /> ; through the SS7 network to reach it)<br /> ; Defaults to no (external application)<br /> ;local=no<br /> <br /> ; instances: integer: Number of local application instances<br /> ; If non 0 the module will build the required number of SCFs and will pick them using a<br /> ; round-robin algorithm<br /> ; Each application's name will be built from SCF application name concatenated with instance<br /> ; suffix startting from 1<br /> ; E.g.<br /> ; [proxy SCP]<br /> ; instances=2<br /> ; Will build 2 applications: SCP1 and SCP2<br /> ; This parameter is ignored for non local SCFs<br /> ; If non 0 it must be set to a value greater then 1<br /> ; Defaults to 0<br /> ;instance=<br /> <br /> ; handles: string: Comma separated list of operations received from the SSF<br /> ; accepted by this SCF<br /> ; NOTE: Except ERB (Event Report BCSM), which is sent to all SCFs that match the reported DP,<br /> ; all operations that are handled by a SCF should be listed, otherwise the<br /> ; proxy will report to the SSF an error<br /> ;handles=<br /> <br /> ; waittime: integer: Time, in miliseconds, to wait for a result from a SCF<br /> ; while being in Waiting For Instructions state, after which the dialog<br /> ; is aborted<br /> ; Defaults to 3000<br /> ; Minimum allowed value is 1000<br /> ;waittime=3000<br /> <br /> ; All other parameters starting with 'addr.' prefix will be put in dialog begin<br /> ; message sent for this SCF<br /> ; E.g. addr.CalledPartyAddress.route=gt will be put as CalledPartyAddress.route=gt<br /> <br /> ==Proxy Module Test==<br /> This chapter describes how the Camel Proxy module was tested.<br /> <br /> The purpose of the test was to check if the Camel BCSM Proxy module can handle 100CPS.<br /> <br /> The machine used was a Dual Intel Xeon E5620 (Quad Core with HT) = 16CPUs, 32GB RAM with CentOS 6.2<br /> <br /> The setup was:<br/><br /> Yate1 - Call generator, sending calls to Yate3 using SIP<br/><br /> Yate2 - Call generator, sending calls to Yate4 using SIP<br/><br /> Yate3 - Call handling, send initialDP to Yate5 (Proxy)<br/><br /> Yate4 - Call handling, send initialDP to Yate5 (Proxy)<br/><br /> Yate5 - Camel BCSM Proxy<br/><br /> Yate6 - CRBT script<br/><br /> Yate7 - PPS script<br/><br /> Yate8 - PPS script<br /> <br /> <br /> SIP M2PA link M2PA links<br /> Yate1 ---------> Yate3 ------------| |-----------> Yate6 (CRBT)<br /> | |<br /> |-> Yate5 |-----------> Yate7 (PPS)<br /> | |<br /> SIP M2PA link | |-----------> Yate8 (PPS)<br /> Yate2 ---------> Yate4 ------------| <br /> <br /> <br /> '''NOTES:'''<br /> * The sum of both call generators was 110CPS.<br /> * During test top reported ~250%CPU for Proxy.<br /> * All yate instances were running on the same machine.<br /> * 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.<br /> <br /> How success was checked:<br /> * On call generators all calls were answered<br /> * 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')<br /> * On Proxy instance (Yate5) there were no timeouts (this would indicate a SCF is not responding withing default 3 seconds interval)<br /> <br /> ==Configuration==<br /> <br /> ===Script side===<br /> <br /> Configuration of the "camel_proxy.php" script is done through ''config_proxy.php''. This allows setting the following parameters:<br /> <br /> * 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.<br /> <br /> * 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.<br /> <br /> * 3. '''$mynum''' - string. GTT number assigned to this SCP. <br /> <br /> * 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.<br /> <br /> * 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:<br /> ** 5.1. '''serviceKey''' - integer. It represents the service key to be used when constructing an IDP for this SCF..<br /> ** 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.<br /> ** 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).<br /> ** 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.<br /> ** 5.5. '''addr''' - array. It specifies SS7 network addressing parameters. They only need be set for external SCFs. Parameters are usually set here are:<br /> *** '''CalledPartyAddress.route''' - string. It can be set to values: gt/ssn. It specifies how the SCCP address should be routed.<br /> *** '''CalledPartyAddress.ssn''' - integer. It's the SSN number in case of SSN routing.<br /> *** '''CalledPartyAddress.gt''' - string. GTT number digits for the SCF.<br /> *** '''CalledPartyAddress.gt.encoding''' - string. It specifies the encoding for the GT digits. It is usually set to ''bcd''.<br /> *** '''CalledPartyAddress.gt.translation''' - integer. It specifies the GT translation type. It is usually set to ''0''. <br /> *** '''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.<br /> *** '''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.<br /> *** '''CallingPartyAddress.route'''<br /> *** '''CalledPartyAddress.ssn'''<br /> *** '''CallingPartyAddress.gt'''<br /> *** '''CallingPartyAddress.gt.encoding'''<br /> *** '''CallingPartyAddress.gt.translation'''<br /> *** '''CallingPartyAddress.gt.plan'''<br /> *** '''CallingPartyAddress.gt.nature''' <br /> ** 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.<br /> ** 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.<br /> ** 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.<br /> ** 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.<br /> <br /> A working configuration for ''camel_proxy.php'' looks like this:<br /> <br /> <br /> $myServiceKey = "1"; <br /> <br /> $proxyName = "camelProxy"; <br /> <br /> /** <br /> * GTT number of this SCP <br /> */ <br /> $mynum = "8820003"; <br /> <br /> /** <br /> * Transaction timeout after inactivity <br /> */ <br /> $transTimeout = 180; <br /> <br /> /** <br /> * List of configured proxied SCFs <br /> * The following parameters must be configured, all are mandatory: <br /> * serviceKey - value with which the IDP serviceKey should be rewritten <br /> * dp - detection point that should match the one received in IDP in order to contact this SCF <br /> * priority - priority in handling messages from SSF <br /> * errorFatal - whether or not an error or reject component from the SCF should terminate the whole proxy dialoque <br /> * addr - SS7 network addressing parameters. <br /> * local - whether the SCF is local (a local application) or external (it passes through the SS7 network to reach it) <br /> * handles - lists operation received from the SSF that are accepted by this SCF. <br /> * NOTE: Except ERBE, which is sent to all SCFs that match the reported DP, all operations that are handled by a <br /> * SCF should be listed, otherwise the proxy will report to the SSF an error. <br /> * context - if set, rewrites the application context for the dialog established with the SCF, otherwise leaves it as received <br /> * waitTime - time, in seconds, to wait for a result from a SCF while being in Waiting For Instructions state, after which the dialogue <br /> * is aborted. <br /> */ <br /> $scfs = array( <br /> "crbt-scp" => array( <br /> "serviceKey" => 2, <br /> "dp" => "termAttemptAuthorized", <br /> "priority" => 1, <br /> "errorFatal" => false, <br /> "addr" => array(), <br /> "local" => true, <br /> "handles" => array(), <br /> "context" => "", <br /> "waitTime" => 3, <br /> ),<br /> "pps-scp" => array( <br /> "serviceKey" => 99, <br /> "dp" => "termAttemptAuthorized", <br /> "priority" => 2, <br /> "errorFatal" => true, <br /> "addr" => array("CalledPartyAddress.gt" => "8820007", <br /> "CalledPartyAddress.route" => "gt", <br /> "CalledPartyAddress.gt.encoding" => "bcd", <br /> "CalledPartyAddress.gt.tt" => "0", <br /> "CalledPartyAddress.gt.np" => "isdn", <br /> "CalledPartyAddress.gt.nature" => "international", <br /> "CallingPartyAddress.gt" => "8820003", <br /> "CallingPartyAddress.route" => "gt", <br /> "CallingPartyAddress.gt.encoding" => "bcd", <br /> "CallingPartyAddress.gt.tt" => "0", <br /> "CallingPartyAddress.gt.np" => "isdn", <br /> "CallingPartyAddress.gt.nature" => "international", <br /> ), <br /> "local" => false, <br /> "handles" => array("applyChargingReport"), <br /> "context" => "", <br /> "waitTime" => 3, <br /> ), <br /> );<br /> <br /> ===Yate side===<br /> <br /> On the Yate side, the ''camel_map'' module must be configured through ''camel_map.conf''. <br /> <br /> In order for the module to ensure communication with the SSF, a section named <tt>[local name_of_proxy]</tt> must be configured:<br /> <br /> [local proxyName] - what comes after ''local'' will be the name of the application<br /> ;enable=no -- enable this application<br /> translator=scp - which translator should be used. A section named [tcap translatorValue] should be present in the config file.<br /> capabilities=Camel - capabilities supported by this application. CAMEL translator has only one capability and that is ''Camel''.<br /> export_xml_as=both - how to export the XML part: string, object or both?<br /> <br /> A <tt>[tcap name]</tt> section must be configured also. A section looks like this:<br /> <br /> [tcap scp] -- what comes after ''tcap'' will be the name of the translator<br /> ;enable=no -- enable this translator<br /> 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''<br /> host=0.0.0.0 -- address on which to listen for incoming applications<br /> port=0 -- port on which to listen for incoming applications. 0 means that will not build a listener, as the proxy works on messages.<br /> type=CAMEL -- type of translator (MAP/CAMEL). For the intended case, CAMEL should be set<br /> print-messages=true -- whether or not to print TCAP and XML messages in the logs<br /> add-encoding=false -- whether to add encoding attribute to data translated to XML<br /> <br /> <br /> For an external proxied SCF, additional <tt>[local scfName]</tt> and <tt>[tcap name]</tt> sections must be configured:<br /> <br /> [tcap msc]<br /> tcap=tcap-msc<br /> host=0.0.0.0<br /> port=0<br /> type=CAMEL<br /> print-messages=true<br /> add-encoding=false<br /> <br /> [local ext-scp]<br /> ;enable=no<br /> translator=msc<br /> capabilities=Camel<br /> export_xml_as=both<br /> <br /> <br /> '''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.<br /> <br /> ==Proxy Behaviour==<br /> <br /> Bellow, the behaviour of the CAMEL proxy implemented in ''camel_proxy.php'' is described.<br /> <br /> ===General===<br /> <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.<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 /> <br /> The main characteristics of the proxy behaviour are:<br /> * 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.<br /> * 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.<br /> * Invoke components from SCFs will be sent to the SSF and the proxy will keep track to which SCF each component belongs to.<br /> * Result and ReturnError components from the SSF will be passed by the proxy to the SCF that initially sent it.<br /> * 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:<br /> <br /> SSF Proxy SCF 1 SCF 2<br /> |------- Invoke 1 ----------->|WFI | | <br /> | |----- Invoke 1a ------>|WFI | <br /> | |<---- Invoke 2a -------|WFI |<br /> |<------ Invoke 2a -----------|WFI | |<br /> |------- Result 2a ---------->|WFI | |<br /> | |----- Result 2a ------>|WFI |<br /> | |<---- Invoke 3a CWA ---|MON |<br /> | |------------------------------ Invoke 1b --------->|WFI<br /> | |<----------------------------- Invoke 2b ----------|WFI<br /> | |<----------------------------- Invoke CONT 3b CONT-|MON<br /> |<------ Invoke 2b -----------| | |<br /> |<------ Invoke 3a CWA -------|MON | |<br /> | | | |<br /> | | | |<br /> |------- Invoke 4 ----------->|MON | |<br /> | |------ Invoke 4a ----->|MON |<br /> | |------------------------------ Invoke 4b --------->|MON<br /> <br /> * 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.<br /> * 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.<br /> * 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.<br /> * 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.<br /> <br /> <br /> ===InitialDP handling===<br /> <br /> The initialDP operation has special handling. Upon receiving this operation from the SSF, the proxy will take the following steps:<br /> * it will check for presence of the ''serviceKey'' parameter. If missing, it will reject the operation and end the dialogue with the SSF.<br /> * 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.<br /> * 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.<br /> * 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.<br /> * 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. <br /> <br /> ===RequestReportBCSM and EventReportBCSM handling===<br /> <br /> <br /> 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. <br /> 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.<br /> <br /> In order to prevent that, proxy does the following:<br /> * the proxy keeps track about how DPs were armed for the dialogue with the SSF, and also for the dialogues with the SCFs.<br /> * 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:<br /> ** 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.<br /> ** 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.<br /> ** 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.<br /> ** 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.<br /> * 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.<br /> <br /> Question: It may turn that SCF requested ''notify'', but got ''interrupted'' EventReportBCSM, right? Is it OK? <br/><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.<br /> <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/><br /> Answer: Yes.<br /> <br /> Question: Are CRBT scripts ready for this scenario?<br/><br /> Answer: Yes, the CRBT script when handling DPs is prepared to handle such a situation.<br /> <br /> Question: It seems better to issue CONT by proxy and change ''interrupted'' to what was originally requested by certain SCF. Not sure.<br/><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.<br /> <br /> ===Multiple Continue/ContinueWithArgument handling===<br /> <br /> <br /> 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.<br /> For that, the proxy will do the following:<br /> * 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.<br /> * if in the message there are only CONT invocations, only the last one is left, the other ones are removed before sending.<br /> * 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.<br /> * 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.<br /> <br /> Question: how does SSF handle multiple CWA?<br/><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.<br /> <br /> ===Leg ID and DP rewriting===<br /> <br /> 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:<br /> * 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.<br /> * 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.<br /> * 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)<br /> * 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.<br /> * leg rewriting handling also aplies to ApplyCharging and ApplyChargingReport operations.<br /> <br /> 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.</div>

Monica https://ss7api.null.ro/index.php/CAMEL_proxy CAMEL proxy 2013-10-28T11:42:25Z

<p>Monica: /* Yate side */</p> <hr /> <div>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.<br /> <br /> The main purpose is to be able to provide CRBT and PPS (PrePaid Service) facilities in parallel.<br /> <br /> The layout for such a scenario will look like this:<br /> <br /> [[File:CamelProxy.png]]<br /> <br /> 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.<br /> The proxy keeps an evidence of these multiple invocations and aggregates them into a single, valid dialogue with the invoking SSP.<br /> <br /> ==Camel Proxy Module Configuration==<br /> <br /> The configuration file is camel_bcsm_proxy.conf<br /> <br /> ===Module configuration===<br /> <br /> ===='general' section====<br /> <br /> '''application''': Application parameter in camel messages sent/handled for SSF dialogs.<br/><br /> This parameter is required and is not applied on reload (can't be changed after module starts).<br/><br /> <br/><br /> '''gt''': Global Title to be set in the first message sent in the SSF dialog.<br/><br /> This parameter is applied on reload.<br/><br /> TCAP address parameters to be set in the first message sent back to SSF can also be set using '''addr.''' prefix.<br/><br /> E.g. GT can be set as '''addr.CallingPartyAddress.gt''' along with other parameters like number nature '''addr.CallingPartyAddress.nature'''.<br/><br /> Setting the GT without other parameters is the same as:<br/><br /> addr.CallingPartyAddress.gt=[GT set]<br/><br /> addr.CallingPartyAddress.route=gt<br/><br /> addr.CallingPartyAddress.gt.encoding=bcd<br/><br /> addr.CallingPartyAddress.gt.translation=0<br/><br /> addr.CallingPartyAddress.gt.plan=isdn<br/><br /> addr.CallingPartyAddress.gt.nature=international<br/><br /> <br/><br /> '''servicekey''': CAMEL serviceKey to check when in received initialDP and set when forwarding them to SCFs.<br/><br /> Allowed interval: 0..2147483647.<br/><br /> Defaults to 0 if missing or invalid.<br/><br /> This parameter is applied on reload for new dialogs only.<br/><br /> <br/><br /> '''query_scf''': Boolean value indicating whether to query for proxied SCFs update when processing initialDP.<br/><br /> Is enabled a 'scf.query' message will be enqueued and the module will wait for a 'scf.response' message to continue IDP processing.<br/><br /> Defaults to no.<br/><br /> <br/><br /> '''print_msg''': boolean/string: Print sent/received messages to output if debug level is at least 9.<br/><br /> Allowed values are boolean values or 'verbose' string.<br/><br /> If verbose is specified, the message will be dumped on output.<br/><br /> Defaults to no.<br/><br /> <br/><br /> '''print_xml''': boolean/string: Print sent/received XML data to output if debug level is at least 9.<br/><br /> This parameter is ignored if print_msg is disabled.<br/><br /> Allowed values are boolean values or 'verbose' string.<br/><br /> If verbose is specified, XML elements' children, attributes or text will be shown on separate lines.<br/><br /> Defaults to no.<br/><br /> <br/><br /> '''idp_calling_required''': boolean: Calling party number is required (non empty) in initialDP.<br/><br /> Default to yes.<br/><br /> <br/><br /> '''idp_called_required''': boolean: Called party number is required (non empty) in initialDP.<br/><br /> Default to yes.<br/><br /> <br/><br /> '''dispatcher_maxthreads''': integer: Maximum number of message dispatch threads to use.<br/><br /> Set to 0 to enqueue messages using yate engine.<br/><br /> Defaults to 0.<br/><br /> 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).<br/><br /> <br/><br /> ====Proxied SCF section(s)====<br /> <br /> '''enable''': boolean: Enable the SCF.<br/><br /> Defaults to yes.<br/><br /> <br/><br /> '''priority''': integer: Priority in handling messages from SSF.<br/><br /> Defaults to 0.<br/><br /> <br/><br /> '''servicekey''': integer: Value with which the IDP serviceKey should be rewritten.<br/><br /> Allowed interval: 0..2147483647.<br/><br /> Defaults to SSF service key set in 'general' section.<br/><br /> <br/><br /> '''dp''': string: Comma separated list of detection points that should match the one received in IDP in order to contact this SCF.<br/><br /> Items may be DP value or name.<br/><br /> Defaults to termAttemptAuthorized if empty or all DPs are invalid.<br/><br /> <br/><br /> '''endfatal''': boolean: Indicate whether or not terminate the proxy dialog when this dialog ends.<br/><br /> Defaults to no.<br/><br /> <br/><br /> '''errorfatal''': boolean: Indicate whether or not an error or reject component from the SCF should terminate the whole proxy dialog.<br/><br /> Defaults to no.<br/><br /> <br/><br /> '''local''': boolean: The SCF is local (a local application) or external (it passes through the SS7 network to reach it).<br/><br /> Defaults to no (external application).<br/><br /> <br/><br /> '''instances''': integer: Number of local application instances.<br/><br /> This parameter is ignored for non local SCFs.<br/><br /> If non 0 it must be set to a value greater then 1.<br/><br /> Defaults to 0.<br/><br /> If non 0 the module will build the required number of SCFs and will pick them using a round-robin algorithm.<br/><br /> Each application's name will be built from SCF application name concatenated with instance suffix startting from 1.<br/><br /> E.g.:<br /> <br /> [proxy SCP]<br /> instances=2<br /> <br /> Will build 2 applications: SCP1 and SCP2.<br/><br /> <br/><br /> '''handles''': string: Comma separated list of operations received from the SSF accepted by this SCF.<br/><br /> 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.<br/><br /> <br/><br /> '''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.<br/><br /> Defaults to 3000.<br/><br /> Minimum allowed value is 1000.<br/><br /> <br/><br /> All other parameters starting with 'addr.' prefix will be put in dialog begin message sent for this SCF.<br/><br /> They should be set for non local SCFs.<br/><br /> Parameters:<br /> * '''addr.CalledPartyAddress.route''' - string. It can be set to values: gt/ssn. It specifies how the SCCP address should be routed.<br /> * '''addr.CalledPartyAddress.ssn''' - integer. It's the SSN number in case of SSN routing.<br /> * '''addr.CalledPartyAddress.gt''' - string. GTT number digits for the SCF.<br /> * '''addr.CalledPartyAddress.gt.encoding''' - string. It specifies the encoding for the GT digits. It is usually set to bcd.<br /> * '''addr.CalledPartyAddress.gt.tt''' - integer. It specifies the GT translation type. It is usually set to 0.<br /> * '''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.<br /> * '''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.<br /> * '''addr.CallingPartyAddress.route'''<br /> * '''addr.CalledPartyAddress.ssn'''<br /> * '''addr.CallingPartyAddress.gt'''<br /> * '''addr.CallingPartyAddress.gt.encoding'''<br /> * '''addr.CallingPartyAddress.gt.tt'''<br /> * '''addr.CallingPartyAddress.gt.np'''<br /> * '''addr.CallingPartyAddress.gt.nature''' <br /> <br /> ====Example====<br /> <br /> [general]<br /> application=camelProxy<br /> servicekey=1<br /> gt=8820003<br /> <br /> [proxy crbt-scp]<br /> servicekey=2<br /> local=true<br /> <br /> [proxy pps-scp]<br /> servicekey=99<br /> priority=2<br /> errorfatal=true<br /> handles=applyChargingReport<br /> addr.CalledPartyAddress.gt=8820007<br /> addr.CalledPartyAddress.route=gt<br /> addr.CalledPartyAddress.gt.encoding=bcd<br /> addr.CalledPartyAddress.gt.tt=0<br /> addr.CalledPartyAddress.gt.np=isdn<br /> addr.CalledPartyAddress.gt.nature=international<br /> addr.CallingPartyAddress.gt=8820003<br /> addr.CallingPartyAddress.route=gt<br /> addr.CallingPartyAddress.gt.encoding=bcd<br /> addr.CallingPartyAddress.gt.tt=0<br /> addr.CallingPartyAddress.gt.np=isdn<br /> addr.CallingPartyAddress.gt.nature=international<br /> <br /> <br /> === camel_map configuration ===<br /> <br /> [local camelProxy]<br /> translator=scp_proxy<br /> capabilities=Camel<br /> <br /> [tcap scp_proxy]<br /> type=CAMEL<br /> tcap=tcap_msc<br /> port=0<br /> <br /> [local pps-scp]<br /> translator=scp_pps<br /> capabilities=Camel<br /> <br /> [tcap scp_pps]<br /> type=CAMEL<br /> tcap=tcap_pps<br /> port=0<br /> <br /> ===camel_bcsm_proxy.conf.sample===<br /> <br /> ; NOTE: This module is not loaded automatically, it needs a line in yate.conf:<br /> ; [postload]<br /> ; ${modulepath}/sig/camel_bcsm_proxy${modsuffix}=yes<br /> <br /> [general]<br /> ; Unless explicitly specified, all parameters are applied on reload for new<br /> ; dialogs only<br /> ; All parameters starting with 'addr.' prefix will be put in the first message sent to SSF<br /> <br /> ; application: string: Application parameter in camel messages sent by the module<br /> ; This parameter is required<br /> ; This parameter is not applied on reload<br /> ;application=<br /> <br /> ; gt: string: Global Title to be set in the first message sent in the SSF dialog<br /> ; This parameter is applied on reload for new dialogs only<br /> ; If non empty other calling party address parameters will be set to default values<br /> ; This parameter can be overriden by addr.CallingPartyAddress.gt parameter<br /> ;gt=<br /> <br /> ; servicekey: integer: CAMEL serviceKey to check in received initialDP messages and<br /> ; set when forwarding them to SCFs<br /> ; Allowed interval: 0..2147483647<br /> ; Defaults to 0 if missing or invalid<br /> ; This parameter is applied on reload for new dialogs only<br /> ;servicekey=0<br /> <br /> ; query_scf: boolean: Query for proxied SCFs update when processing initialDP<br /> ; Is enabled a 'scf.query' message will be enqueued and the module will wait<br /> ; for a 'scf.response' message to continue IDP processing<br /> ; The response must return the list of SCFs to proxy<br /> ; The list may be shorter then configured SCFs<br /> ; New SCFs, other then configured ones, will be ignored<br /> ; The following SCF parameters can be overridden: priority, servicekey, errorfatal,<br /> ; handles, waittime and all parameters starting with 'addr.' prefix<br /> ; Defaults to no<br /> ;query_scf=no<br /> <br /> ; component_ttl: integer: Component time to live in milliseconds<br /> ; Minimum allowed value is 1000<br /> ; Defaults to 15000<br /> ;component_ttl=15000<br /> <br /> ; dialog_idle_ttl: integer: Dialog idle (nothing sent/received) time to live in milliseconds<br /> ; Minimum allowed value is 1000<br /> ; It can be set to 0 to keep it alive until the remote party terminates the dialog<br /> ; Defaults to 5000<br /> ;dialog_idle_ttl=5000<br /> <br /> ; dialog_ended_ttl: integer: Ended dialog time to live in milliseconds<br /> ; Minimum allowed value is 1000.<br /> ; It can be set to 0 to remove the dialog after termination<br /> ; Defaults to 0<br /> ;dialog_ended_ttl=0<br /> <br /> ; export_xml_as: string: Specify in which way the XML will be passed along into<br /> ; Yate messages<br /> ; Allowed values are:<br /> ; - string: pass the XML as a string<br /> ; - object: pass the XML as an object<br /> ; - both: pass the XML as a string and object<br /> ; Defaults to object<br /> ;export_xml_as=object<br /> <br /> ; print_msg: boolean/string: Print sent/received messages to output if debug<br /> ; level is at least 9<br /> ; Allowed values are boolean values or 'verbose' string<br /> ; If verbose is specified, the message will be dumped on output<br /> ; Defaults to no<br /> ;print_msg=no<br /> <br /> ; print_xml: boolean/string: Print sent/received XML data to output if debug<br /> ; level is at least 9<br /> ; This parameter is ignored if print_msg is disabled<br /> ; Allowed values are boolean values or 'verbose' string<br /> ; If verbose is specified, XML elements' children, attributes or text will be<br /> ; shown on separate lines<br /> ; Defaults to no<br /> ;print_xml=no<br /> <br /> ; idp_calling_required: boolean: Calling party number is required (non empty) in initialDP<br /> ; Default to yes<br /> ;idp_calling_required=yes<br /> <br /> ; idp_called_required: boolean: Called party number is required (non empty) in initialDP<br /> ; Default to yes<br /> ;idp_called_required=yes<br /> <br /> ; dispatcher_maxthreads: integer: Maximum number of message dispatch threads to use<br /> ; Set to 0 to enqueue messages using yate engine<br /> ; Defaults to 0<br /> ; When reloaded it can't be set to 0 (e.g. once set to a non 0 value it can be changed to<br /> ; non 0 values only)<br /> ;dispatcher_maxthreads=0<br /> <br /> ;dispatcher_priority: string: Default priority of message dispatch threads<br /> ; Can be one of: lowest, low, normal, high, highest<br /> ; High priorities need superuser privileges on POSIX operating systems<br /> ; Low priorities are not recommended except for debugging<br /> ; Defaults to 'normal'<br /> ; This parameter is applied on reload for new threads only<br /> ;dispatcher_priority=normal<br /> <br /> <br /> ;[proxy appname]<br /> ; This section configures a proxied SCF<br /> ; 'appname' is the application name to be used for the SCF<br /> <br /> ; enable: boolean: Enable the SCF<br /> ; Defaults to yes<br /> ;enable=yes<br /> <br /> ; priority: integer: Priority in handling messages from SSF<br /> ; Defaults to 0<br /> ;priority=0<br /> <br /> ; servicekey: integer: Value with which the IDP serviceKey should be rewritten<br /> ; Allowed interval: 0..2147483647<br /> ; Defaults to SSF service key set in 'general' section<br /> ;servicekey=<br /> <br /> ; dp: string: Comma separated list of detection points that should match the one received in IDP<br /> ; in order to contact this SCF<br /> ; Items may be DP value or name<br /> ; Defaults to termAttemptAuthorized if empty or all DPs are invalid<br /> ;dp=termAttemptAuthorized<br /> <br /> ; endfatal: boolean: Indicate whether or not terminate the proxy dialog when this dialog ends<br /> ; Defaults to no<br /> ;endfatal=no<br /> <br /> ; errorfatal: boolean: Indicate whether or not an error or reject component from<br /> ; the SCF should terminate the whole proxy dialog<br /> ; Defaults to no<br /> ;errorfatal=no<br /> <br /> ; local: boolean: The SCF is local (a local application) or external (it passes<br /> ; through the SS7 network to reach it)<br /> ; Defaults to no (external application)<br /> ;local=no<br /> <br /> ; instances: integer: Number of local application instances<br /> ; If non 0 the module will build the required number of SCFs and will pick them using a<br /> ; round-robin algorithm<br /> ; Each application's name will be built from SCF application name concatenated with instance<br /> ; suffix startting from 1<br /> ; E.g.<br /> ; [proxy SCP]<br /> ; instances=2<br /> ; Will build 2 applications: SCP1 and SCP2<br /> ; This parameter is ignored for non local SCFs<br /> ; If non 0 it must be set to a value greater then 1<br /> ; Defaults to 0<br /> ;instance=<br /> <br /> ; handles: string: Comma separated list of operations received from the SSF<br /> ; accepted by this SCF<br /> ; NOTE: Except ERB (Event Report BCSM), which is sent to all SCFs that match the reported DP,<br /> ; all operations that are handled by a SCF should be listed, otherwise the<br /> ; proxy will report to the SSF an error<br /> ;handles=<br /> <br /> ; waittime: integer: Time, in miliseconds, to wait for a result from a SCF<br /> ; while being in Waiting For Instructions state, after which the dialog<br /> ; is aborted<br /> ; Defaults to 3000<br /> ; Minimum allowed value is 1000<br /> ;waittime=3000<br /> <br /> ; All other parameters starting with 'addr.' prefix will be put in dialog begin<br /> ; message sent for this SCF<br /> ; E.g. addr.CalledPartyAddress.route=gt will be put as CalledPartyAddress.route=gt<br /> <br /> ==Proxy Module Test==<br /> This chapter describes how the Camel Proxy module was tested.<br /> <br /> The purpose of the test was to check if the Camel BCSM Proxy module can handle 100CPS.<br /> <br /> The machine used was a Dual Intel Xeon E5620 (Quad Core with HT) = 16CPUs, 32GB RAM with CentOS 6.2<br /> <br /> The setup was:<br/><br /> Yate1 - Call generator, sending calls to Yate3 using SIP<br/><br /> Yate2 - Call generator, sending calls to Yate4 using SIP<br/><br /> Yate3 - Call handling, send initialDP to Yate5 (Proxy)<br/><br /> Yate4 - Call handling, send initialDP to Yate5 (Proxy)<br/><br /> Yate5 - Camel BCSM Proxy<br/><br /> Yate6 - CRBT script<br/><br /> Yate7 - PPS script<br/><br /> Yate8 - PPS script<br /> <br /> <br /> SIP M2PA link M2PA links<br /> Yate1 ---------> Yate3 ------------| |-----------> Yate6 (CRBT)<br /> | |<br /> |-> Yate5 |-----------> Yate7 (PPS)<br /> | |<br /> SIP M2PA link | |-----------> Yate8 (PPS)<br /> Yate2 ---------> Yate4 ------------| <br /> <br /> <br /> '''NOTES:'''<br /> * The sum of both call generators was 110CPS.<br /> * During test top reported ~250%CPU for Proxy.<br /> * All yate instances were running on the same machine.<br /> * 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.<br /> <br /> How success was checked:<br /> * On call generators all calls were answered<br /> * 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')<br /> * On Proxy instance (Yate5) there were no timeouts (this would indicate a SCF is not responding withing default 3 seconds interval)<br /> <br /> ==Configuration==<br /> <br /> ===Script side===<br /> <br /> Configuration of the "camel_proxy.php" script is done through ''config_proxy.php''. This allows setting the following parameters:<br /> <br /> * 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.<br /> <br /> * 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.<br /> <br /> * 3. '''$mynum''' - string. GTT number assigned to this SCP. <br /> <br /> * 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.<br /> <br /> * 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:<br /> ** 5.1. '''serviceKey''' - integer. It represents the service key to be used when constructing an IDP for this SCF..<br /> ** 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.<br /> ** 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).<br /> ** 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.<br /> ** 5.5. '''addr''' - array. It specifies SS7 network addressing parameters. They only need be set for external SCFs. Parameters are usually set here are:<br /> *** '''CalledPartyAddress.route''' - string. It can be set to values: gt/ssn. It specifies how the SCCP address should be routed.<br /> *** '''CalledPartyAddress.ssn''' - integer. It's the SSN number in case of SSN routing.<br /> *** '''CalledPartyAddress.gt''' - string. GTT number digits for the SCF.<br /> *** '''CalledPartyAddress.gt.encoding''' - string. It specifies the encoding for the GT digits. It is usually set to ''bcd''.<br /> *** '''CalledPartyAddress.gt.translation''' - integer. It specifies the GT translation type. It is usually set to ''0''. <br /> *** '''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.<br /> *** '''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.<br /> *** '''CallingPartyAddress.route'''<br /> *** '''CalledPartyAddress.ssn'''<br /> *** '''CallingPartyAddress.gt'''<br /> *** '''CallingPartyAddress.gt.encoding'''<br /> *** '''CallingPartyAddress.gt.translation'''<br /> *** '''CallingPartyAddress.gt.plan'''<br /> *** '''CallingPartyAddress.gt.nature''' <br /> ** 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.<br /> ** 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.<br /> ** 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.<br /> ** 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.<br /> <br /> A working configuration for ''camel_proxy.php'' looks like this:<br /> <br /> <br /> $myServiceKey = "1"; <br /> <br /> $proxyName = "camelProxy"; <br /> <br /> /** <br /> * GTT number of this SCP <br /> */ <br /> $mynum = "8820003"; <br /> <br /> /** <br /> * Transaction timeout after inactivity <br /> */ <br /> $transTimeout = 180; <br /> <br /> /** <br /> * List of configured proxied SCFs <br /> * The following parameters must be configured, all are mandatory: <br /> * serviceKey - value with which the IDP serviceKey should be rewritten <br /> * dp - detection point that should match the one received in IDP in order to contact this SCF <br /> * priority - priority in handling messages from SSF <br /> * errorFatal - whether or not an error or reject component from the SCF should terminate the whole proxy dialoque <br /> * addr - SS7 network addressing parameters. <br /> * local - whether the SCF is local (a local application) or external (it passes through the SS7 network to reach it) <br /> * handles - lists operation received from the SSF that are accepted by this SCF. <br /> * NOTE: Except ERBE, which is sent to all SCFs that match the reported DP, all operations that are handled by a <br /> * SCF should be listed, otherwise the proxy will report to the SSF an error. <br /> * context - if set, rewrites the application context for the dialog established with the SCF, otherwise leaves it as received <br /> * waitTime - time, in seconds, to wait for a result from a SCF while being in Waiting For Instructions state, after which the dialogue <br /> * is aborted. <br /> */ <br /> $scfs = array( <br /> "crbt-scp" => array( <br /> "serviceKey" => 2, <br /> "dp" => "termAttemptAuthorized", <br /> "priority" => 1, <br /> "errorFatal" => false, <br /> "addr" => array(), <br /> "local" => true, <br /> "handles" => array(), <br /> "context" => "", <br /> "waitTime" => 3, <br /> ),<br /> "pps-scp" => array( <br /> "serviceKey" => 99, <br /> "dp" => "termAttemptAuthorized", <br /> "priority" => 2, <br /> "errorFatal" => true, <br /> "addr" => array("CalledPartyAddress.gt" => "8820007", <br /> "CalledPartyAddress.route" => "gt", <br /> "CalledPartyAddress.gt.encoding" => "bcd", <br /> "CalledPartyAddress.gt.tt" => "0", <br /> "CalledPartyAddress.gt.np" => "isdn", <br /> "CalledPartyAddress.gt.nature" => "international", <br /> "CallingPartyAddress.gt" => "8820003", <br /> "CallingPartyAddress.route" => "gt", <br /> "CallingPartyAddress.gt.encoding" => "bcd", <br /> "CallingPartyAddress.gt.tt" => "0", <br /> "CallingPartyAddress.gt.np" => "isdn", <br /> "CallingPartyAddress.gt.nature" => "international", <br /> ), <br /> "local" => false, <br /> "handles" => array("applyChargingReport"), <br /> "context" => "", <br /> "waitTime" => 3, <br /> ), <br /> );<br /> <br /> ===Yate side===<br /> <br /> On the Yate side, the ''camel_map'' module must be configured through ''camel_map.conf''. <br /> <br /> In order for the module to ensure communication with the SSF, a section named <tt>[local name_of_proxy]</tt> must be configured:<br /> <br /> [local proxyName] - what comes after ''local'' will be the name of the application<br /> ;enable=no -- enable this application<br /> translator=scp - which translator should be used. A section named [tcap translatorValue] should be present in the config file.<br /> capabilities=Camel - capabilities supported by this application. CAMEL translator has only one capability and that is ''Camel''.<br /> export_xml_as=both - how to export the XML part: string, object or both?<br /> <br /> A <tt>[tcap name]</tt> section must be configured also. A section looks like this:<br /> <br /> [tcap scp] -- what comes after ''tcap'' will be the name of the translator<br /> ;enable=no -- enable this translator<br /> 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''<br /> host=0.0.0.0 -- address on which to listen for incoming applications<br /> port=0 -- port on which to listen for incoming applications. 0 means that will not build a listener, as the proxy works on messages.<br /> type=CAMEL -- type of translator (MAP/CAMEL). For the intended case, CAMEL should be set<br /> print-messages=true -- whether or not to print TCAP and XML messages in the logs<br /> add-encoding=false -- whether to add encoding attribute to data translated to XML<br /> <br /> <br /> For an external proxied SCF, additional <tt>[local scfName]</tt> and <tt>[tcap name]</tt> sections must be configured:<br /> <br /> [tcap msc]<br /> tcap=tcap-msc<br /> host=0.0.0.0<br /> port=0<br /> type=CAMEL<br /> print-messages=true<br /> add-encoding=false<br /> <br /> [local ext-scp]<br /> ;enable=no<br /> translator=msc<br /> capabilities=Camel<br /> export_xml_as=both<br /> <br /> <br /> '''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.<br /> <br /> ==Proxy Behaviour==<br /> <br /> Bellow, the behaviour of the CAMEL proxy implemented in ''camel_proxy.php'' is described.<br /> <br /> ===General===<br /> <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.<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 /> <br /> The main characteristics of the proxy behaviour are:<br /> * 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.<br /> * 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.<br /> * Invoke components from SCFs will be sent to the SSF and the proxy will keep track to which SCF each component belongs to.<br /> * Result and ReturnError components from the SSF will be passed by the proxy to the SCF that initially sent it.<br /> * 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:<br /> <br /> SSF Proxy SCF 1 SCF 2<br /> |------- Invoke 1 ----------->|WFI | | <br /> | |----- Invoke 1a ------>|WFI | <br /> | |<---- Invoke 2a -------|WFI |<br /> |<------ Invoke 2a -----------|WFI | |<br /> |------- Result 2a ---------->|WFI | |<br /> | |----- Result 2a ------>|WFI |<br /> | |<---- Invoke 3a CWA ---|MON |<br /> | |------------------------------ Invoke 1b --------->|WFI<br /> | |<----------------------------- Invoke 2b ----------|WFI<br /> | |<----------------------------- Invoke CONT 3b CONT-|MON<br /> |<------ Invoke 2b -----------| | |<br /> |<------ Invoke 3a CWA -------|MON | |<br /> | | | |<br /> | | | |<br /> |------- Invoke 4 ----------->|MON | |<br /> | |------ Invoke 4a ----->|MON |<br /> | |------------------------------ Invoke 4b --------->|MON<br /> <br /> * 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.<br /> * 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.<br /> * 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.<br /> * 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.<br /> <br /> <br /> ===InitialDP handling===<br /> <br /> The initialDP operation has special handling. Upon receiving this operation from the SSF, the proxy will take the following steps:<br /> * it will check for presence of the ''serviceKey'' parameter. If missing, it will reject the operation and end the dialogue with the SSF.<br /> * 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.<br /> * 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.<br /> * 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.<br /> * 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. <br /> <br /> ===RequestReportBCSM and EventReportBCSM handling===<br /> <br /> <br /> 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. <br /> 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.<br /> <br /> In order to prevent that, proxy does the following:<br /> * the proxy keeps track about how DPs were armed for the dialogue with the SSF, and also for the dialogues with the SCFs.<br /> * 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:<br /> ** 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.<br /> ** 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.<br /> ** 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.<br /> ** 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.<br /> * 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.<br /> <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.<br /> <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.<br /> <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.<br /> <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.<br /> <br /> ===Multiple Continue/ContinueWithArgument handling===<br /> <br /> <br /> 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.<br /> For that, the proxy will do the following:<br /> * 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.<br /> * if in the message there are only CONT invocations, only the last one is left, the other ones are removed before sending.<br /> * 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.<br /> * 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.<br /> <br /> Question: how does SSF handle multiple CWA?<br/><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.<br /> <br /> ===Leg ID and DP rewriting===<br /> <br /> 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:<br /> * 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.<br /> * 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.<br /> * 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)<br /> * 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.<br /> * leg rewriting handling also aplies to ApplyCharging and ApplyChargingReport operations.<br /> <br /> 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.</div>

Monica https://ss7api.null.ro/index.php/CAMEL_proxy CAMEL proxy 2013-10-28T11:40:51Z

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

Monica https://ss7api.null.ro/index.php/CAMEL_proxy CAMEL proxy 2013-10-28T11:40:34Z

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

Monica https://ss7api.null.ro/index.php/CAMEL_proxy CAMEL proxy 2013-10-28T11:39:15Z

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

Monica https://ss7api.null.ro/index.php/CAMEL_proxy CAMEL proxy 2013-10-28T11:38:36Z

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

Monica https://ss7api.null.ro/index.php/CAMEL_proxy CAMEL proxy 2013-10-28T11:37:14Z

<p>Monica: /* camel_bcsm_proxy.conf.sample */</p> <hr /> <div>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.<br /> <br /> The main purpose is to be able to provide CRBT and PPS (PrePaid Service) facilities in parallel.<br /> <br /> The layout for such a scenario will look like this:<br /> <br /> [[File:CamelProxy.png]]<br /> <br /> 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.<br /> The proxy keeps an evidence of these multiple invocations and aggregates them into a single, valid dialogue with the invoking SSP.<br /> <br /> ==Camel Proxy Module Configuration==<br /> <br /> The configuration file is camel_bcsm_proxy.conf<br /> <br /> ===Module configuration===<br /> <br /> ===='general' section====<br /> <br /> '''application''': Application parameter in camel messages sent/handled for SSF dialogs.<br/><br /> This parameter is required and is not applied on reload (can't be changed after module starts).<br/><br /> <br/><br /> '''gt''': Global Title to be set in the first message sent in the SSF dialog.<br/><br /> This parameter is applied on reload.<br/><br /> TCAP address parameters to be set in the first message sent back to SSF can also be set using '''addr.''' prefix.<br/><br /> E.g. GT can be set as '''addr.CallingPartyAddress.gt''' along with other parameters like number nature '''addr.CallingPartyAddress.nature'''.<br/><br /> Setting the GT without other parameters is the same as:<br/><br /> addr.CallingPartyAddress.gt=[GT set]<br/><br /> addr.CallingPartyAddress.route=gt<br/><br /> addr.CallingPartyAddress.gt.encoding=bcd<br/><br /> addr.CallingPartyAddress.gt.translation=0<br/><br /> addr.CallingPartyAddress.gt.plan=isdn<br/><br /> addr.CallingPartyAddress.gt.nature=international<br/><br /> <br/><br /> '''servicekey''': CAMEL serviceKey to check when in received initialDP and set when forwarding them to SCFs.<br/><br /> Allowed interval: 0..2147483647.<br/><br /> Defaults to 0 if missing or invalid.<br/><br /> This parameter is applied on reload for new dialogs only.<br/><br /> <br/><br /> '''query_scf''': Boolean value indicating whether to query for proxied SCFs update when processing initialDP.<br/><br /> Is enabled a 'scf.query' message will be enqueued and the module will wait for a 'scf.response' message to continue IDP processing.<br/><br /> Defaults to no.<br/><br /> <br/><br /> '''print_msg''': boolean/string: Print sent/received messages to output if debug level is at least 9.<br/><br /> Allowed values are boolean values or 'verbose' string.<br/><br /> If verbose is specified, the message will be dumped on output.<br/><br /> Defaults to no.<br/><br /> <br/><br /> '''print_xml''': boolean/string: Print sent/received XML data to output if debug level is at least 9.<br/><br /> This parameter is ignored if print_msg is disabled.<br/><br /> Allowed values are boolean values or 'verbose' string.<br/><br /> If verbose is specified, XML elements' children, attributes or text will be shown on separate lines.<br/><br /> Defaults to no.<br/><br /> <br/><br /> '''idp_calling_required''': boolean: Calling party number is required (non empty) in initialDP.<br/><br /> Default to yes.<br/><br /> <br/><br /> '''idp_called_required''': boolean: Called party number is required (non empty) in initialDP.<br/><br /> Default to yes.<br/><br /> <br/><br /> '''dispatcher_maxthreads''': integer: Maximum number of message dispatch threads to use.<br/><br /> Set to 0 to enqueue messages using yate engine.<br/><br /> Defaults to 0.<br/><br /> 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).<br/><br /> <br/><br /> ====Proxied SCF section(s)====<br /> <br /> '''enable''': boolean: Enable the SCF.<br/><br /> Defaults to yes.<br/><br /> <br/><br /> '''priority''': integer: Priority in handling messages from SSF.<br/><br /> Defaults to 0.<br/><br /> <br/><br /> '''servicekey''': integer: Value with which the IDP serviceKey should be rewritten.<br/><br /> Allowed interval: 0..2147483647.<br/><br /> Defaults to SSF service key set in 'general' section.<br/><br /> <br/><br /> '''dp''': string: Comma separated list of detection points that should match the one received in IDP in order to contact this SCF.<br/><br /> Items may be DP value or name.<br/><br /> Defaults to termAttemptAuthorized if empty or all DPs are invalid.<br/><br /> <br/><br /> '''endfatal''': boolean: Indicate whether or not terminate the proxy dialog when this dialog ends.<br/><br /> Defaults to no.<br/><br /> <br/><br /> '''errorfatal''': boolean: Indicate whether or not an error or reject component from the SCF should terminate the whole proxy dialog.<br/><br /> Defaults to no.<br/><br /> <br/><br /> '''local''': boolean: The SCF is local (a local application) or external (it passes through the SS7 network to reach it).<br/><br /> Defaults to no (external application).<br/><br /> <br/><br /> '''instances''': integer: Number of local application instances.<br/><br /> This parameter is ignored for non local SCFs.<br/><br /> If non 0 it must be set to a value greater then 1.<br/><br /> Defaults to 0.<br/><br /> If non 0 the module will build the required number of SCFs and will pick them using a round-robin algorithm.<br/><br /> Each application's name will be built from SCF application name concatenated with instance suffix startting from 1.<br/><br /> E.g.:<br /> <br /> [proxy SCP]<br /> instances=2<br /> <br /> Will build 2 applications: SCP1 and SCP2.<br/><br /> <br/><br /> '''handles''': string: Comma separated list of operations received from the SSF accepted by this SCF.<br/><br /> 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.<br/><br /> <br/><br /> '''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.<br/><br /> Defaults to 3000.<br/><br /> Minimum allowed value is 1000.<br/><br /> <br/><br /> All other parameters starting with 'addr.' prefix will be put in dialog begin message sent for this SCF.<br/><br /> They should be set for non local SCFs.<br/><br /> Parameters:<br /> * '''addr.CalledPartyAddress.route''' - string. It can be set to values: gt/ssn. It specifies how the SCCP address should be routed.<br /> * '''addr.CalledPartyAddress.ssn''' - integer. It's the SSN number in case of SSN routing.<br /> * '''addr.CalledPartyAddress.gt''' - string. GTT number digits for the SCF.<br /> * '''addr.CalledPartyAddress.gt.encoding''' - string. It specifies the encoding for the GT digits. It is usually set to bcd.<br /> * '''addr.CalledPartyAddress.gt.tt''' - integer. It specifies the GT translation type. It is usually set to 0.<br /> * '''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.<br /> * '''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.<br /> * '''addr.CallingPartyAddress.route'''<br /> * '''addr.CalledPartyAddress.ssn'''<br /> * '''addr.CallingPartyAddress.gt'''<br /> * '''addr.CallingPartyAddress.gt.encoding'''<br /> * '''addr.CallingPartyAddress.gt.tt'''<br /> * '''addr.CallingPartyAddress.gt.np'''<br /> * '''addr.CallingPartyAddress.gt.nature''' <br /> <br /> ====Example====<br /> <br /> [general]<br /> application=camelProxy<br /> servicekey=1<br /> gt=8820003<br /> <br /> [proxy crbt-scp]<br /> servicekey=2<br /> local=true<br /> <br /> [proxy pps-scp]<br /> servicekey=99<br /> priority=2<br /> errorfatal=true<br /> handles=applyChargingReport<br /> addr.CalledPartyAddress.gt=8820007<br /> addr.CalledPartyAddress.route=gt<br /> addr.CalledPartyAddress.gt.encoding=bcd<br /> addr.CalledPartyAddress.gt.tt=0<br /> addr.CalledPartyAddress.gt.np=isdn<br /> addr.CalledPartyAddress.gt.nature=international<br /> addr.CallingPartyAddress.gt=8820003<br /> addr.CallingPartyAddress.route=gt<br /> addr.CallingPartyAddress.gt.encoding=bcd<br /> addr.CallingPartyAddress.gt.tt=0<br /> addr.CallingPartyAddress.gt.np=isdn<br /> addr.CallingPartyAddress.gt.nature=international<br /> <br /> <br /> === camel_map configuration ===<br /> <br /> [local camelProxy]<br /> translator=scp_proxy<br /> capabilities=Camel<br /> <br /> [tcap scp_proxy]<br /> type=CAMEL<br /> tcap=tcap_msc<br /> port=0<br /> <br /> [local pps-scp]<br /> translator=scp_pps<br /> capabilities=Camel<br /> <br /> [tcap scp_pps]<br /> type=CAMEL<br /> tcap=tcap_pps<br /> port=0<br /> <br /> ===camel_bcsm_proxy.conf.sample===<br /> <br /> ; NOTE: This module is not loaded automatically, it needs a line in yate.conf:<br /> ; [postload]<br /> ; ${modulepath}/sig/camel_bcsm_proxy${modsuffix}=yes<br /> <br /> [general]<br /> ; Unless explicitly specified, all parameters are applied on reload for new<br /> ; dialogs only<br /> ; All parameters starting with 'addr.' prefix will be put in the first message sent to SSF<br /> <br /> ; application: string: Application parameter in camel messages sent by the module<br /> ; This parameter is required<br /> ; This parameter is not applied on reload<br /> ;application=<br /> <br /> ; gt: string: Global Title to be set in the first message sent in the SSF dialog<br /> ; This parameter is applied on reload for new dialogs only<br /> ; If non empty other calling party address parameters will be set to default values<br /> ; This parameter can be overriden by addr.CallingPartyAddress.gt parameter<br /> ;gt=<br /> <br /> ; servicekey: integer: CAMEL serviceKey to check in received initialDP messages and<br /> ; set when forwarding them to SCFs<br /> ; Allowed interval: 0..2147483647<br /> ; Defaults to 0 if missing or invalid<br /> ; This parameter is applied on reload for new dialogs only<br /> ;servicekey=0<br /> <br /> ; query_scf: boolean: Query for proxied SCFs update when processing initialDP<br /> ; Is enabled a 'scf.query' message will be enqueued and the module will wait<br /> ; for a 'scf.response' message to continue IDP processing<br /> ; The response must return the list of SCFs to proxy<br /> ; The list may be shorter then configured SCFs<br /> ; New SCFs, other then configured ones, will be ignored<br /> ; The following SCF parameters can be overridden: priority, servicekey, errorfatal,<br /> ; handles, waittime and all parameters starting with 'addr.' prefix<br /> ; Defaults to no<br /> ;query_scf=no<br /> <br /> ; component_ttl: integer: Component time to live in milliseconds<br /> ; Minimum allowed value is 1000<br /> ; Defaults to 15000<br /> ;component_ttl=15000<br /> <br /> ; dialog_idle_ttl: integer: Dialog idle (nothing sent/received) time to live in milliseconds<br /> ; Minimum allowed value is 1000<br /> ; It can be set to 0 to keep it alive until the remote party terminates the dialog<br /> ; Defaults to 5000<br /> ;dialog_idle_ttl=5000<br /> <br /> ; dialog_ended_ttl: integer: Ended dialog time to live in milliseconds<br /> ; Minimum allowed value is 1000.<br /> ; It can be set to 0 to remove the dialog after termination<br /> ; Defaults to 0<br /> ;dialog_ended_ttl=0<br /> <br /> ; export_xml_as: string: Specify in which way the XML will be passed along into<br /> ; Yate messages<br /> ; Allowed values are:<br /> ; - string: pass the XML as a string<br /> ; - object: pass the XML as an object<br /> ; - both: pass the XML as a string and object<br /> ; Defaults to object<br /> ;export_xml_as=object<br /> <br /> ; print_msg: boolean/string: Print sent/received messages to output if debug<br /> ; level is at least 9<br /> ; Allowed values are boolean values or 'verbose' string<br /> ; If verbose is specified, the message will be dumped on output<br /> ; Defaults to no<br /> ;print_msg=no<br /> <br /> ; print_xml: boolean/string: Print sent/received XML data to output if debug<br /> ; level is at least 9<br /> ; This parameter is ignored if print_msg is disabled<br /> ; Allowed values are boolean values or 'verbose' string<br /> ; If verbose is specified, XML elements' children, attributes or text will be<br /> ; shown on separate lines<br /> ; Defaults to no<br /> ;print_xml=no<br /> <br /> ; idp_calling_required: boolean: Calling party number is required (non empty) in initialDP<br /> ; Default to yes<br /> ;idp_calling_required=yes<br /> <br /> ; idp_called_required: boolean: Called party number is required (non empty) in initialDP<br /> ; Default to yes<br /> ;idp_called_required=yes<br /> <br /> ; dispatcher_maxthreads: integer: Maximum number of message dispatch threads to use<br /> ; Set to 0 to enqueue messages using yate engine<br /> ; Defaults to 0<br /> ; When reloaded it can't be set to 0 (e.g. once set to a non 0 value it can be changed to<br /> ; non 0 values only)<br /> ;dispatcher_maxthreads=0<br /> <br /> ;dispatcher_priority: string: Default priority of message dispatch threads<br /> ; Can be one of: lowest, low, normal, high, highest<br /> ; High priorities need superuser privileges on POSIX operating systems<br /> ; Low priorities are not recommended except for debugging<br /> ; Defaults to 'normal'<br /> ; This parameter is applied on reload for new threads only<br /> ;dispatcher_priority=normal<br /> <br /> <br /> ;[proxy appname]<br /> ; This section configures a proxied SCF<br /> ; 'appname' is the application name to be used for the SCF<br /> <br /> ; enable: boolean: Enable the SCF<br /> ; Defaults to yes<br /> ;enable=yes<br /> <br /> ; priority: integer: Priority in handling messages from SSF<br /> ; Defaults to 0<br /> ;priority=0<br /> <br /> ; servicekey: integer: Value with which the IDP serviceKey should be rewritten<br /> ; Allowed interval: 0..2147483647<br /> ; Defaults to SSF service key set in 'general' section<br /> ;servicekey=<br /> <br /> ; dp: string: Comma separated list of detection points that should match the one received in IDP<br /> ; in order to contact this SCF<br /> ; Items may be DP value or name<br /> ; Defaults to termAttemptAuthorized if empty or all DPs are invalid<br /> ;dp=termAttemptAuthorized<br /> <br /> ; endfatal: boolean: Indicate whether or not terminate the proxy dialog when this dialog ends<br /> ; Defaults to no<br /> ;endfatal=no<br /> <br /> ; errorfatal: boolean: Indicate whether or not an error or reject component from<br /> ; the SCF should terminate the whole proxy dialog<br /> ; Defaults to no<br /> ;errorfatal=no<br /> <br /> ; local: boolean: The SCF is local (a local application) or external (it passes<br /> ; through the SS7 network to reach it)<br /> ; Defaults to no (external application)<br /> ;local=no<br /> <br /> ; instances: integer: Number of local application instances<br /> ; If non 0 the module will build the required number of SCFs and will pick them using a<br /> ; round-robin algorithm<br /> ; Each application's name will be built from SCF application name concatenated with instance<br /> ; suffix startting from 1<br /> ; E.g.<br /> ; [proxy SCP]<br /> ; instances=2<br /> ; Will build 2 applications: SCP1 and SCP2<br /> ; This parameter is ignored for non local SCFs<br /> ; If non 0 it must be set to a value greater then 1<br /> ; Defaults to 0<br /> ;instance=<br /> <br /> ; handles: string: Comma separated list of operations received from the SSF<br /> ; accepted by this SCF<br /> ; NOTE: Except ERB (Event Report BCSM), which is sent to all SCFs that match the reported DP,<br /> ; all operations that are handled by a SCF should be listed, otherwise the<br /> ; proxy will report to the SSF an error<br /> ;handles=<br /> <br /> ; waittime: integer: Time, in miliseconds, to wait for a result from a SCF<br /> ; while being in Waiting For Instructions state, after which the dialog<br /> ; is aborted<br /> ; Defaults to 3000<br /> ; Minimum allowed value is 1000<br /> ;waittime=3000<br /> <br /> ; All other parameters starting with 'addr.' prefix will be put in dialog begin<br /> ; message sent for this SCF<br /> ; E.g. addr.CalledPartyAddress.route=gt will be put as CalledPartyAddress.route=gt<br /> <br /> ==Proxy Module Test==<br /> This chapter describes how the Camel Proxy module was tested.<br /> <br /> The purpose of the test was to check if the Camel BCSM Proxy module can handle 100CPS.<br /> <br /> The machine used was a Dual Intel Xeon E5620 (Quad Core with HT) = 16CPUs, 32GB RAM with CentOS 6.2<br /> <br /> The setup was:<br/><br /> Yate1 - Call generator, sending calls to Yate3 using SIP<br/><br /> Yate2 - Call generator, sending calls to Yate4 using SIP<br/><br /> Yate3 - Call handling, send initialDP to Yate5 (Proxy)<br/><br /> Yate4 - Call handling, send initialDP to Yate5 (Proxy)<br/><br /> Yate5 - Camel BCSM Proxy<br/><br /> Yate6 - CRBT script<br/><br /> Yate7 - PPS script<br/><br /> Yate8 - PPS script<br /> <br /> <br /> SIP M2PA link M2PA links<br /> Yate1 ---------> Yate3 ------------| |-----------> Yate6 (CRBT)<br /> | |<br /> |-> Yate5 |-----------> Yate7 (PPS)<br /> | |<br /> SIP M2PA link | |-----------> Yate8 (PPS)<br /> Yate2 ---------> Yate4 ------------| <br /> <br /> <br /> '''NOTES:'''<br /> * The sum of both call generators was 110CPS.<br /> * During test top reported ~250%CPU for Proxy.<br /> * All yate instances were running on the same machine.<br /> * 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.<br /> <br /> How success was checked:<br /> * On call generators all calls were answered<br /> * 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')<br /> * On Proxy instance (Yate5) there were no timeouts (this would indicate a SCF is not responding withing default 3 seconds interval)</div>

Monica https://ss7api.null.ro/index.php/CAMEL_proxy CAMEL proxy 2013-10-28T11:34:16Z

<p>Monica: </p> <hr /> <div>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.<br /> <br /> The main purpose is to be able to provide CRBT and PPS (PrePaid Service) facilities in parallel.<br /> <br /> The layout for such a scenario will look like this:<br /> <br /> [[File:CamelProxy.png]]<br /> <br /> 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.<br /> The proxy keeps an evidence of these multiple invocations and aggregates them into a single, valid dialogue with the invoking SSP.<br /> <br /> ==Camel Proxy Module Configuration==<br /> <br /> The configuration file is camel_bcsm_proxy.conf<br /> <br /> ===Module configuration===<br /> <br /> ===='general' section====<br /> <br /> '''application''': Application parameter in camel messages sent/handled for SSF dialogs.<br/><br /> This parameter is required and is not applied on reload (can't be changed after module starts).<br/><br /> <br/><br /> '''gt''': Global Title to be set in the first message sent in the SSF dialog.<br/><br /> This parameter is applied on reload.<br/><br /> TCAP address parameters to be set in the first message sent back to SSF can also be set using '''addr.''' prefix.<br/><br /> E.g. GT can be set as '''addr.CallingPartyAddress.gt''' along with other parameters like number nature '''addr.CallingPartyAddress.nature'''.<br/><br /> Setting the GT without other parameters is the same as:<br/><br /> addr.CallingPartyAddress.gt=[GT set]<br/><br /> addr.CallingPartyAddress.route=gt<br/><br /> addr.CallingPartyAddress.gt.encoding=bcd<br/><br /> addr.CallingPartyAddress.gt.translation=0<br/><br /> addr.CallingPartyAddress.gt.plan=isdn<br/><br /> addr.CallingPartyAddress.gt.nature=international<br/><br /> <br/><br /> '''servicekey''': CAMEL serviceKey to check when in received initialDP and set when forwarding them to SCFs.<br/><br /> Allowed interval: 0..2147483647.<br/><br /> Defaults to 0 if missing or invalid.<br/><br /> This parameter is applied on reload for new dialogs only.<br/><br /> <br/><br /> '''query_scf''': Boolean value indicating whether to query for proxied SCFs update when processing initialDP.<br/><br /> Is enabled a 'scf.query' message will be enqueued and the module will wait for a 'scf.response' message to continue IDP processing.<br/><br /> Defaults to no.<br/><br /> <br/><br /> '''print_msg''': boolean/string: Print sent/received messages to output if debug level is at least 9.<br/><br /> Allowed values are boolean values or 'verbose' string.<br/><br /> If verbose is specified, the message will be dumped on output.<br/><br /> Defaults to no.<br/><br /> <br/><br /> '''print_xml''': boolean/string: Print sent/received XML data to output if debug level is at least 9.<br/><br /> This parameter is ignored if print_msg is disabled.<br/><br /> Allowed values are boolean values or 'verbose' string.<br/><br /> If verbose is specified, XML elements' children, attributes or text will be shown on separate lines.<br/><br /> Defaults to no.<br/><br /> <br/><br /> '''idp_calling_required''': boolean: Calling party number is required (non empty) in initialDP.<br/><br /> Default to yes.<br/><br /> <br/><br /> '''idp_called_required''': boolean: Called party number is required (non empty) in initialDP.<br/><br /> Default to yes.<br/><br /> <br/><br /> '''dispatcher_maxthreads''': integer: Maximum number of message dispatch threads to use.<br/><br /> Set to 0 to enqueue messages using yate engine.<br/><br /> Defaults to 0.<br/><br /> 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).<br/><br /> <br/><br /> ====Proxied SCF section(s)====<br /> <br /> '''enable''': boolean: Enable the SCF.<br/><br /> Defaults to yes.<br/><br /> <br/><br /> '''priority''': integer: Priority in handling messages from SSF.<br/><br /> Defaults to 0.<br/><br /> <br/><br /> '''servicekey''': integer: Value with which the IDP serviceKey should be rewritten.<br/><br /> Allowed interval: 0..2147483647.<br/><br /> Defaults to SSF service key set in 'general' section.<br/><br /> <br/><br /> '''dp''': string: Comma separated list of detection points that should match the one received in IDP in order to contact this SCF.<br/><br /> Items may be DP value or name.<br/><br /> Defaults to termAttemptAuthorized if empty or all DPs are invalid.<br/><br /> <br/><br /> '''endfatal''': boolean: Indicate whether or not terminate the proxy dialog when this dialog ends.<br/><br /> Defaults to no.<br/><br /> <br/><br /> '''errorfatal''': boolean: Indicate whether or not an error or reject component from the SCF should terminate the whole proxy dialog.<br/><br /> Defaults to no.<br/><br /> <br/><br /> '''local''': boolean: The SCF is local (a local application) or external (it passes through the SS7 network to reach it).<br/><br /> Defaults to no (external application).<br/><br /> <br/><br /> '''instances''': integer: Number of local application instances.<br/><br /> This parameter is ignored for non local SCFs.<br/><br /> If non 0 it must be set to a value greater then 1.<br/><br /> Defaults to 0.<br/><br /> If non 0 the module will build the required number of SCFs and will pick them using a round-robin algorithm.<br/><br /> Each application's name will be built from SCF application name concatenated with instance suffix startting from 1.<br/><br /> E.g.:<br /> <br /> [proxy SCP]<br /> instances=2<br /> <br /> Will build 2 applications: SCP1 and SCP2.<br/><br /> <br/><br /> '''handles''': string: Comma separated list of operations received from the SSF accepted by this SCF.<br/><br /> 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.<br/><br /> <br/><br /> '''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.<br/><br /> Defaults to 3000.<br/><br /> Minimum allowed value is 1000.<br/><br /> <br/><br /> All other parameters starting with 'addr.' prefix will be put in dialog begin message sent for this SCF.<br/><br /> They should be set for non local SCFs.<br/><br /> Parameters:<br /> * '''addr.CalledPartyAddress.route''' - string. It can be set to values: gt/ssn. It specifies how the SCCP address should be routed.<br /> * '''addr.CalledPartyAddress.ssn''' - integer. It's the SSN number in case of SSN routing.<br /> * '''addr.CalledPartyAddress.gt''' - string. GTT number digits for the SCF.<br /> * '''addr.CalledPartyAddress.gt.encoding''' - string. It specifies the encoding for the GT digits. It is usually set to bcd.<br /> * '''addr.CalledPartyAddress.gt.tt''' - integer. It specifies the GT translation type. It is usually set to 0.<br /> * '''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.<br /> * '''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.<br /> * '''addr.CallingPartyAddress.route'''<br /> * '''addr.CalledPartyAddress.ssn'''<br /> * '''addr.CallingPartyAddress.gt'''<br /> * '''addr.CallingPartyAddress.gt.encoding'''<br /> * '''addr.CallingPartyAddress.gt.tt'''<br /> * '''addr.CallingPartyAddress.gt.np'''<br /> * '''addr.CallingPartyAddress.gt.nature''' <br /> <br /> ====Example====<br /> <br /> [general]<br /> application=camelProxy<br /> servicekey=1<br /> gt=8820003<br /> <br /> [proxy crbt-scp]<br /> servicekey=2<br /> local=true<br /> <br /> [proxy pps-scp]<br /> servicekey=99<br /> priority=2<br /> errorfatal=true<br /> handles=applyChargingReport<br /> addr.CalledPartyAddress.gt=8820007<br /> addr.CalledPartyAddress.route=gt<br /> addr.CalledPartyAddress.gt.encoding=bcd<br /> addr.CalledPartyAddress.gt.tt=0<br /> addr.CalledPartyAddress.gt.np=isdn<br /> addr.CalledPartyAddress.gt.nature=international<br /> addr.CallingPartyAddress.gt=8820003<br /> addr.CallingPartyAddress.route=gt<br /> addr.CallingPartyAddress.gt.encoding=bcd<br /> addr.CallingPartyAddress.gt.tt=0<br /> addr.CallingPartyAddress.gt.np=isdn<br /> addr.CallingPartyAddress.gt.nature=international<br /> <br /> <br /> === camel_map configuration ===<br /> <br /> [local camelProxy]<br /> translator=scp_proxy<br /> capabilities=Camel<br /> <br /> [tcap scp_proxy]<br /> type=CAMEL<br /> tcap=tcap_msc<br /> port=0<br /> <br /> [local pps-scp]<br /> translator=scp_pps<br /> capabilities=Camel<br /> <br /> [tcap scp_pps]<br /> type=CAMEL<br /> tcap=tcap_pps<br /> port=0<br /> <br /> ===camel_bcsm_proxy.conf.sample===<br /> <br /> ; NOTE: This module is not loaded automatically, it needs a line in yate.conf:<br /> ; [postload]<br /> ; ${modulepath}/sig/camel_bcsm_proxy${modsuffix}=yes<br /> <br /> [general]<br /> ; Unless explicitly specified, all parameters are applied on reload for new<br /> ; dialogs only<br /> ; All parameters starting with 'addr.' prefix will be put in the first message sent to SSF<br /> <br /> ; application: string: Application parameter in camel messages sent by the module<br /> ; This parameter is required<br /> ; This parameter is not applied on reload<br /> ;application=<br /> <br /> ; gt: string: Global Title to be set in the first message sent in the SSF dialog<br /> ; This parameter is applied on reload for new dialogs only<br /> ; If non empty other calling party address parameters will be set to default values<br /> ; This parameter can be overriden by addr.CallingPartyAddress.gt parameter<br /> ;gt=<br /> <br /> ; servicekey: integer: CAMEL serviceKey to check in received initialDP messages and<br /> ; set when forwarding them to SCFs<br /> ; Allowed interval: 0..2147483647<br /> ; Defaults to 0 if missing or invalid<br /> ; This parameter is applied on reload for new dialogs only<br /> ;servicekey=0<br /> <br /> ; query_scf: boolean: Query for proxied SCFs update when processing initialDP<br /> ; Is enabled a 'scf.query' message will be enqueued and the module will wait<br /> ; for a 'scf.response' message to continue IDP processing<br /> ; The response must return the list of SCFs to proxy<br /> ; The list may be shorter then configured SCFs<br /> ; New SCFs, other then configured ones, will be ignored<br /> ; The following SCF parameters can be overridden: priority, servicekey, errorfatal,<br /> ; handles, waittime and all parameters starting with 'addr.' prefix<br /> ; Defaults to no<br /> ;query_scf=no<br /> <br /> ; component_ttl: integer: Component time to live in milliseconds<br /> ; Minimum allowed value is 1000<br /> ; Defaults to 15000<br /> ;component_ttl=15000<br /> <br /> ; dialog_idle_ttl: integer: Dialog idle (nothing sent/received) time to live in milliseconds<br /> ; Minimum allowed value is 1000<br /> ; It can be set to 0 to keep it alive until the remote party terminates the dialog<br /> ; Defaults to 5000<br /> ;dialog_idle_ttl=5000<br /> <br /> ; dialog_ended_ttl: integer: Ended dialog time to live in milliseconds<br /> ; Minimum allowed value is 1000.<br /> ; It can be set to 0 to remove the dialog after termination<br /> ; Defaults to 0<br /> ;dialog_ended_ttl=0<br /> <br /> ; export_xml_as: string: Specify in which way the XML will be passed along into<br /> ; Yate messages<br /> ; Allowed values are:<br /> ; - string: pass the XML as a string<br /> ; - object: pass the XML as an object<br /> ; - both: pass the XML as a string and object<br /> ; Defaults to object<br /> ;export_xml_as=object<br /> <br /> ; print_msg: boolean/string: Print sent/received messages to output if debug<br /> ; level is at least 9<br /> ; Allowed values are boolean values or 'verbose' string<br /> ; If verbose is specified, the message will be dumped on output<br /> ; Defaults to no<br /> ;print_msg=no<br /> <br /> ; print_xml: boolean/string: Print sent/received XML data to output if debug<br /> ; level is at least 9<br /> ; This parameter is ignored if print_msg is disabled<br /> ; Allowed values are boolean values or 'verbose' string<br /> ; If verbose is specified, XML elements' children, attributes or text will be<br /> ; shown on separate lines<br /> ; Defaults to no<br /> ;print_xml=no<br /> <br /> ; idp_calling_required: boolean: Calling party number is required (non empty) in initialDP<br /> ; Default to yes<br /> ;idp_calling_required=yes<br /> <br /> ; idp_called_required: boolean: Called party number is required (non empty) in initialDP<br /> ; Default to yes<br /> ;idp_called_required=yes<br /> <br /> ; dispatcher_maxthreads: integer: Maximum number of message dispatch threads to use<br /> ; Set to 0 to enqueue messages using yate engine<br /> ; Defaults to 0<br /> ; When reloaded it can't be set to 0 (e.g. once set to a non 0 value it can be changed to<br /> ; non 0 values only)<br /> ;dispatcher_maxthreads=0<br /> <br /> ;dispatcher_priority: string: Default priority of message dispatch threads<br /> ; Can be one of: lowest, low, normal, high, highest<br /> ; High priorities need superuser privileges on POSIX operating systems<br /> ; Low priorities are not recommended except for debugging<br /> ; Defaults to 'normal'<br /> ; This parameter is applied on reload for new threads only<br /> ;dispatcher_priority=normal<br /> <br /> <br /> ;[proxy appname]<br /> ; This section configures a proxied SCF<br /> ; 'appname' is the application name to be used for the SCF<br /> <br /> ; enable: boolean: Enable the SCF<br /> ; Defaults to yes<br /> ;enable=yes<br /> <br /> ; priority: integer: Priority in handling messages from SSF<br /> ; Defaults to 0<br /> ;priority=0<br /> <br /> ; servicekey: integer: Value with which the IDP serviceKey should be rewritten<br /> ; Allowed interval: 0..2147483647<br /> ; Defaults to SSF service key set in 'general' section<br /> ;servicekey=<br /> <br /> ; dp: string: Comma separated list of detection points that should match the one received in IDP<br /> ; in order to contact this SCF<br /> ; Items may be DP value or name<br /> ; Defaults to termAttemptAuthorized if empty or all DPs are invalid<br /> ;dp=termAttemptAuthorized<br /> <br /> ; endfatal: boolean: Indicate whether or not terminate the proxy dialog when this dialog ends<br /> ; Defaults to no<br /> ;endfatal=no<br /> <br /> ; errorfatal: boolean: Indicate whether or not an error or reject component from<br /> ; the SCF should terminate the whole proxy dialog<br /> ; Defaults to no<br /> ;errorfatal=no<br /> <br /> ; local: boolean: The SCF is local (a local application) or external (it passes<br /> ; through the SS7 network to reach it)<br /> ; Defaults to no (external application)<br /> ;local=no<br /> <br /> ; instances: integer: Number of local application instances<br /> ; If non 0 the module will build the required number of SCFs and will pick them using a<br /> ; round-robin algorithm<br /> ; Each application's name will be built from SCF application name concatenated with instance<br /> ; suffix startting from 1<br /> ; E.g.<br /> ; [proxy SCP]<br /> ; instances=2<br /> ; Will build 2 applications: SCP1 and SCP2<br /> ; This parameter is ignored for non local SCFs<br /> ; If non 0 it must be set to a value greater then 1<br /> ; Defaults to 0<br /> ;instance=<br /> <br /> ; handles: string: Comma separated list of operations received from the SSF<br /> ; accepted by this SCF<br /> ; NOTE: Except ERB (Event Report BCSM), which is sent to all SCFs that match the reported DP,<br /> ; all operations that are handled by a SCF should be listed, otherwise the<br /> ; proxy will report to the SSF an error<br /> ;handles=<br /> <br /> ; waittime: integer: Time, in miliseconds, to wait for a result from a SCF<br /> ; while being in Waiting For Instructions state, after which the dialog<br /> ; is aborted<br /> ; Defaults to 3000<br /> ; Minimum allowed value is 1000<br /> ;waittime=3000<br /> <br /> ; All other parameters starting with 'addr.' prefix will be put in dialog begin<br /> ; message sent for this SCF<br /> ; E.g. addr.CalledPartyAddress.route=gt will be put as CalledPartyAddress.route=gt</div>

Monica https://ss7api.null.ro/index.php/CAMEL_proxy CAMEL proxy 2013-10-28T11:25:52Z

<p>Monica: </p> <hr /> <div>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.<br /> <br /> The main purpose is to be able to provide CRBT and PPS (PrePaid Service) facilities in parallel.<br /> <br /> The layout for such a scenario will look like this:<br /> <br /> [[File:CamelProxy.png]]<br /> <br /> 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.<br /> The proxy keeps an evidence of these multiple invocations and aggregates them into a single, valid dialogue with the invoking SSP.<br /> <br /> ==Camel Proxy Module Configuration==<br /> <br /> The configuration file is camel_bcsm_proxy.conf<br /> <br /> ===Module configuration===<br /> <br /> ===='general' section====<br /> <br /> '''application''': Application parameter in camel messages sent/handled for SSF dialogs.\\<br /> This parameter is required and is not applied on reload (can't be changed after module starts).\\<br /> \\<br /> '''gt''': Global Title to be set in the first message sent in the SSF dialog.\\<br /> This parameter is applied on reload.\\<br /> TCAP address parameters to be set in the first message sent back to SSF can also be set using '''addr.''' prefix.\\<br /> E.g. GT can be set as '''addr.CallingPartyAddress.gt''' along with other parameters like number nature '''addr.CallingPartyAddress.nature'''.\\<br /> Setting the GT without other parameters is the same as:\\<br /> addr.CallingPartyAddress.gt=[GT set]\\<br /> addr.CallingPartyAddress.route=gt\\<br /> addr.CallingPartyAddress.gt.encoding=bcd\\<br /> addr.CallingPartyAddress.gt.translation=0\\<br /> addr.CallingPartyAddress.gt.plan=isdn\\<br /> addr.CallingPartyAddress.gt.nature=international\\<br /> \\<br /> '''servicekey''': CAMEL serviceKey to check when in received initialDP and set when forwarding them to SCFs.\\<br /> Allowed interval: 0..2147483647.\\<br /> Defaults to 0 if missing or invalid.\\<br /> This parameter is applied on reload for new dialogs only.\\<br /> \\<br /> '''query_scf''': Boolean value indicating whether to query for proxied SCFs update when processing initialDP.\\<br /> Is enabled a 'scf.query' message will be enqueued and the module will wait for a 'scf.response' message to continue IDP processing.\\<br /> Defaults to no.\\<br /> \\<br /> '''print_msg''': boolean/string: Print sent/received messages to output if debug level is at least 9.\\<br /> Allowed values are boolean values or 'verbose' string.\\<br /> If verbose is specified, the message will be dumped on output.\\<br /> Defaults to no.\\<br /> \\<br /> '''print_xml''': boolean/string: Print sent/received XML data to output if debug level is at least 9.\\<br /> This parameter is ignored if print_msg is disabled.\\<br /> Allowed values are boolean values or 'verbose' string.\\<br /> If verbose is specified, XML elements' children, attributes or text will be shown on separate lines.\\<br /> Defaults to no.\\<br /> \\<br /> '''idp_calling_required''': boolean: Calling party number is required (non empty) in initialDP.\\<br /> Default to yes.\\<br /> \\<br /> '''idp_called_required''': boolean: Called party number is required (non empty) in initialDP.\\<br /> Default to yes.\\<br /> \\<br /> '''dispatcher_maxthreads''': integer: Maximum number of message dispatch threads to use.\\<br /> Set to 0 to enqueue messages using yate engine.\\<br /> Defaults to 0.\\<br /> 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).\\<br /> \\<br /> ====Proxied SCF section(s)====<br /> <br /> '''enable''': boolean: Enable the SCF.\\<br /> Defaults to yes.\\<br /> \\<br /> '''priority''': integer: Priority in handling messages from SSF.\\<br /> Defaults to 0.\\<br /> \\<br /> '''servicekey''': integer: Value with which the IDP serviceKey should be rewritten.\\<br /> Allowed interval: 0..2147483647.\\<br /> Defaults to SSF service key set in 'general' section.\\<br /> \\<br /> '''dp''': string: Comma separated list of detection points that should match the one received in IDP in order to contact this SCF.\\<br /> Items may be DP value or name.\\<br /> Defaults to termAttemptAuthorized if empty or all DPs are invalid.\\<br /> \\<br /> '''endfatal''': boolean: Indicate whether or not terminate the proxy dialog when this dialog ends.\\<br /> Defaults to no.\\<br /> \\<br /> '''errorfatal''': boolean: Indicate whether or not an error or reject component from the SCF should terminate the whole proxy dialog.\\<br /> Defaults to no.\\<br /> \\<br /> '''local''': boolean: The SCF is local (a local application) or external (it passes through the SS7 network to reach it).\\<br /> Defaults to no (external application).\\<br /> \\<br /> '''instances''': integer: Number of local application instances.\\<br /> This parameter is ignored for non local SCFs.\\<br /> If non 0 it must be set to a value greater then 1.\\<br /> Defaults to 0.\\<br /> If non 0 the module will build the required number of SCFs and will pick them using a round-robin algorithm.\\<br /> Each application's name will be built from SCF application name concatenated with instance suffix startting from 1.\\<br /> E.g.:<br /> [=<br /> [proxy SCP]<br /> instances=2<br /> =]<br /> Will build 2 applications: SCP1 and SCP2.\\<br /> \\<br /> '''handles''': string: Comma separated list of operations received from the SSF accepted by this SCF.\\<br /> 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.\\<br /> \\<br /> '''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.\\<br /> Defaults to 3000.\\<br /> Minimum allowed value is 1000.\\<br /> \\<br /> All other parameters starting with 'addr.' prefix will be put in dialog begin message sent for this SCF.\\<br /> They should be set for non local SCFs.\\<br /> Parameters:<br /> * '''addr.CalledPartyAddress.route''' - string. It can be set to values: gt/ssn. It specifies how the SCCP address should be routed.<br /> * '''addr.CalledPartyAddress.ssn''' - integer. It's the SSN number in case of SSN routing.<br /> * '''addr.CalledPartyAddress.gt''' - string. GTT number digits for the SCF.<br /> * '''addr.CalledPartyAddress.gt.encoding''' - string. It specifies the encoding for the GT digits. It is usually set to bcd.<br /> * '''addr.CalledPartyAddress.gt.tt''' - integer. It specifies the GT translation type. It is usually set to 0.<br /> * '''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.<br /> * '''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.<br /> * '''addr.CallingPartyAddress.route'''<br /> * '''addr.CalledPartyAddress.ssn'''<br /> * '''addr.CallingPartyAddress.gt'''<br /> * '''addr.CallingPartyAddress.gt.encoding'''<br /> * '''addr.CallingPartyAddress.gt.tt'''<br /> * '''addr.CallingPartyAddress.gt.np'''<br /> * '''addr.CallingPartyAddress.gt.nature''' <br /> <br /> ====Example====<br /> [=<br /> [general]<br /> application=camelProxy<br /> servicekey=1<br /> gt=8820003<br /> <br /> [proxy crbt-scp]<br /> servicekey=2<br /> local=true<br /> <br /> [proxy pps-scp]<br /> servicekey=99<br /> priority=2<br /> errorfatal=true<br /> handles=applyChargingReport<br /> addr.CalledPartyAddress.gt=8820007<br /> addr.CalledPartyAddress.route=gt<br /> addr.CalledPartyAddress.gt.encoding=bcd<br /> addr.CalledPartyAddress.gt.tt=0<br /> addr.CalledPartyAddress.gt.np=isdn<br /> addr.CalledPartyAddress.gt.nature=international<br /> addr.CallingPartyAddress.gt=8820003<br /> addr.CallingPartyAddress.route=gt<br /> addr.CallingPartyAddress.gt.encoding=bcd<br /> addr.CallingPartyAddress.gt.tt=0<br /> addr.CallingPartyAddress.gt.np=isdn<br /> addr.CallingPartyAddress.gt.nature=international<br /> =]<br /> <br /> === camel_map configuration ===<br /> [=<br /> [local camelProxy]<br /> translator=scp_proxy<br /> capabilities=Camel<br /> <br /> [tcap scp_proxy]<br /> type=CAMEL<br /> tcap=tcap_msc<br /> port=0<br /> <br /> [local pps-scp]<br /> translator=scp_pps<br /> capabilities=Camel<br /> <br /> [tcap scp_pps]<br /> type=CAMEL<br /> tcap=tcap_pps<br /> port=0<br /> =]<br /> ===camel_bcsm_proxy.conf.sample===<br /> [=<br /> ; NOTE: This module is not loaded automatically, it needs a line in yate.conf:<br /> ; [postload]<br /> ; ${modulepath}/sig/camel_bcsm_proxy${modsuffix}=yes<br /> <br /> [general]<br /> ; Unless explicitly specified, all parameters are applied on reload for new<br /> ; dialogs only<br /> ; All parameters starting with 'addr.' prefix will be put in the first message sent to SSF<br /> <br /> ; application: string: Application parameter in camel messages sent by the module<br /> ; This parameter is required<br /> ; This parameter is not applied on reload<br /> ;application=<br /> <br /> ; gt: string: Global Title to be set in the first message sent in the SSF dialog<br /> ; This parameter is applied on reload for new dialogs only<br /> ; If non empty other calling party address parameters will be set to default values<br /> ; This parameter can be overriden by addr.CallingPartyAddress.gt parameter<br /> ;gt=<br /> <br /> ; servicekey: integer: CAMEL serviceKey to check in received initialDP messages and<br /> ; set when forwarding them to SCFs<br /> ; Allowed interval: 0..2147483647<br /> ; Defaults to 0 if missing or invalid<br /> ; This parameter is applied on reload for new dialogs only<br /> ;servicekey=0<br /> <br /> ; query_scf: boolean: Query for proxied SCFs update when processing initialDP<br /> ; Is enabled a 'scf.query' message will be enqueued and the module will wait<br /> ; for a 'scf.response' message to continue IDP processing<br /> ; The response must return the list of SCFs to proxy<br /> ; The list may be shorter then configured SCFs<br /> ; New SCFs, other then configured ones, will be ignored<br /> ; The following SCF parameters can be overridden: priority, servicekey, errorfatal,<br /> ; handles, waittime and all parameters starting with 'addr.' prefix<br /> ; Defaults to no<br /> ;query_scf=no<br /> <br /> ; component_ttl: integer: Component time to live in milliseconds<br /> ; Minimum allowed value is 1000<br /> ; Defaults to 15000<br /> ;component_ttl=15000<br /> <br /> ; dialog_idle_ttl: integer: Dialog idle (nothing sent/received) time to live in milliseconds<br /> ; Minimum allowed value is 1000<br /> ; It can be set to 0 to keep it alive until the remote party terminates the dialog<br /> ; Defaults to 5000<br /> ;dialog_idle_ttl=5000<br /> <br /> ; dialog_ended_ttl: integer: Ended dialog time to live in milliseconds<br /> ; Minimum allowed value is 1000.<br /> ; It can be set to 0 to remove the dialog after termination<br /> ; Defaults to 0<br /> ;dialog_ended_ttl=0<br /> <br /> ; export_xml_as: string: Specify in which way the XML will be passed along into<br /> ; Yate messages<br /> ; Allowed values are:<br /> ; - string: pass the XML as a string<br /> ; - object: pass the XML as an object<br /> ; - both: pass the XML as a string and object<br /> ; Defaults to object<br /> ;export_xml_as=object<br /> <br /> ; print_msg: boolean/string: Print sent/received messages to output if debug<br /> ; level is at least 9<br /> ; Allowed values are boolean values or 'verbose' string<br /> ; If verbose is specified, the message will be dumped on output<br /> ; Defaults to no<br /> ;print_msg=no<br /> <br /> ; print_xml: boolean/string: Print sent/received XML data to output if debug<br /> ; level is at least 9<br /> ; This parameter is ignored if print_msg is disabled<br /> ; Allowed values are boolean values or 'verbose' string<br /> ; If verbose is specified, XML elements' children, attributes or text will be<br /> ; shown on separate lines<br /> ; Defaults to no<br /> ;print_xml=no<br /> <br /> ; idp_calling_required: boolean: Calling party number is required (non empty) in initialDP<br /> ; Default to yes<br /> ;idp_calling_required=yes<br /> <br /> ; idp_called_required: boolean: Called party number is required (non empty) in initialDP<br /> ; Default to yes<br /> ;idp_called_required=yes<br /> <br /> ; dispatcher_maxthreads: integer: Maximum number of message dispatch threads to use<br /> ; Set to 0 to enqueue messages using yate engine<br /> ; Defaults to 0<br /> ; When reloaded it can't be set to 0 (e.g. once set to a non 0 value it can be changed to<br /> ; non 0 values only)<br /> ;dispatcher_maxthreads=0<br /> <br /> ;dispatcher_priority: string: Default priority of message dispatch threads<br /> ; Can be one of: lowest, low, normal, high, highest<br /> ; High priorities need superuser privileges on POSIX operating systems<br /> ; Low priorities are not recommended except for debugging<br /> ; Defaults to 'normal'<br /> ; This parameter is applied on reload for new threads only<br /> ;dispatcher_priority=normal<br /> <br /> <br /> ;[proxy appname]<br /> ; This section configures a proxied SCF<br /> ; 'appname' is the application name to be used for the SCF<br /> <br /> ; enable: boolean: Enable the SCF<br /> ; Defaults to yes<br /> ;enable=yes<br /> <br /> ; priority: integer: Priority in handling messages from SSF<br /> ; Defaults to 0<br /> ;priority=0<br /> <br /> ; servicekey: integer: Value with which the IDP serviceKey should be rewritten<br /> ; Allowed interval: 0..2147483647<br /> ; Defaults to SSF service key set in 'general' section<br /> ;servicekey=<br /> <br /> ; dp: string: Comma separated list of detection points that should match the one received in IDP<br /> ; in order to contact this SCF<br /> ; Items may be DP value or name<br /> ; Defaults to termAttemptAuthorized if empty or all DPs are invalid<br /> ;dp=termAttemptAuthorized<br /> <br /> ; endfatal: boolean: Indicate whether or not terminate the proxy dialog when this dialog ends<br /> ; Defaults to no<br /> ;endfatal=no<br /> <br /> ; errorfatal: boolean: Indicate whether or not an error or reject component from<br /> ; the SCF should terminate the whole proxy dialog<br /> ; Defaults to no<br /> ;errorfatal=no<br /> <br /> ; local: boolean: The SCF is local (a local application) or external (it passes<br /> ; through the SS7 network to reach it)<br /> ; Defaults to no (external application)<br /> ;local=no<br /> <br /> ; instances: integer: Number of local application instances<br /> ; If non 0 the module will build the required number of SCFs and will pick them using a<br /> ; round-robin algorithm<br /> ; Each application's name will be built from SCF application name concatenated with instance<br /> ; suffix startting from 1<br /> ; E.g.<br /> ; [proxy SCP]<br /> ; instances=2<br /> ; Will build 2 applications: SCP1 and SCP2<br /> ; This parameter is ignored for non local SCFs<br /> ; If non 0 it must be set to a value greater then 1<br /> ; Defaults to 0<br /> ;instance=<br /> <br /> ; handles: string: Comma separated list of operations received from the SSF<br /> ; accepted by this SCF<br /> ; NOTE: Except ERB (Event Report BCSM), which is sent to all SCFs that match the reported DP,<br /> ; all operations that are handled by a SCF should be listed, otherwise the<br /> ; proxy will report to the SSF an error<br /> ;handles=<br /> <br /> ; waittime: integer: Time, in miliseconds, to wait for a result from a SCF<br /> ; while being in Waiting For Instructions state, after which the dialog<br /> ; is aborted<br /> ; Defaults to 3000<br /> ; Minimum allowed value is 1000<br /> ;waittime=3000<br /> <br /> ; All other parameters starting with 'addr.' prefix will be put in dialog begin<br /> ; message sent for this SCF<br /> ; E.g. addr.CalledPartyAddress.route=gt will be put as CalledPartyAddress.route=gt<br /> <br /> =]</div>

Monica https://ss7api.null.ro/index.php/CAMEL_proxy CAMEL proxy 2013-10-28T11:22:13Z

<p>Monica: Created page with "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..."</p> <hr /> <div>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.<br /> <br /> The main purpose is to be able to provide CRBT and PPS (PrePaid Service) facilities in parallel.<br /> <br /> The layout for such a scenario will look like this:<br /> <br /> [[File:CamelProxy.png]]<br /> <br /> 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.<br /> The proxy keeps an evidence of these multiple invocations and aggregates them into a single, valid dialogue with the invoking SSP.</div>

Monica https://ss7api.null.ro/index.php/CRBT_logic CRBT logic 2013-10-28T11:16:15Z

<p>Monica: /* Abnormal procedures */</p> <hr /> <div>The crbt_scp.php is an implementation for a CAMEL gsmSCP application which provides a Colourful Ring Back Tone service by interfacing with a CAMEL gsmSSF.<br /> <br /> Upon service invocation, this script implements the required actions in order to instruct the gsmSSF to provide the required ringback tone.<br /> <br /> ==Configuration==<br /> <br /> ===Script side===<br /> <br /> The CRBT script supports two ways of communicating with Yate:<br /> # One based on the XML protocol, communication being realized through a TCP socket.<br /> # The other one based done through Yate messages, using ''extmodule''.<br /> The way which the script will use is chosen according to configuration - in particular, through the ''$ioType'' setting.<br /> <br /> <br /> Configuration of this script is done through ''config.php''. This allows setting the following parameters:<br /> <br /> * 1. '''$appName'''- value of the ''application'' parameters set in the ''camel.message''. This value is used to check that the message is indeed intented for this script.<br /> <br /> * 2. '''$ioType''' - type of I/O to use to communicate with Yate. The script recognizes these two values:<br /> ** ''TCP'' - use the configured TCP socket to communicate with Yate.<br /> ** ''MSG'' - use messages through exmodule protocol for communication.<br /> <br /> * 3. '''$host''','''$port''' - host and port where the application should connect to in order to communicate with Yate if ''$ioType'' is set to ''TCP''.<br /> <br /> * 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.<br /> <br /> * 5. '''$findMelodyID''' - boolean. It specifies whether the gsmSCF should take the necessary steps in order to find out the required ringtone for the called user. Its default value is false, meaning that the gsmSCF will assume that all requests reaching it are requests for subscribers which have the service activated<br /> <br /> * 6. '''$httpRequest''' - string. It's the HTTP request to be made in order to find out the ringtone associated with the user.<br /> <br /> * 7. '''$myServiceKey''' - integer. The ID of the service provided by this gsmSCF application and which should come in IDP in order to accept the request.<br /> <br /> * 8. '''$myDP''' - string. The DP for which this SCP should be triggered and which should come in IDP in order to accept the request.<br /> <br /> * 9. '''$sendAll''' - bool. If true, it will send all response components batched in a single TCAP message, otherwise it will send them each with its own TCAP message. It is set by default to true.<br /> <br /> * 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:<br /> ** ''prefix_called'' - build the gsmSRF address following this rule <tt>$srfNumber.$srfSeparator.$correlationID.$srfSeparator.$sfcID</tt>.<br /> ** ''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.<br /> <br /> When instructing the SSF to establish a temporary connection to a SRF through an ETC operation, the SCF must provide addressing information to the SSF in regards to the SRF. This information requires:<br /> * the address of the SRF - a routable number<br /> * a correlation ID - that can mean whatever the operators want, but that, according to specification, can be used by the SRF if/when contacting the SCF in order to associate the SSF -> SCF dialogue with the SRF ->SCF dialogue.<br /> * a scfID - an ID for the contacting SCF. This could be used by the SRF to know where to contact the SCF.<br /> <br /> The script provides this information in an ETC operation in 2 ways:<br /> * providing all the above information in the assistingSSPIPAddress. This is done by concatenating the SRF number, correlation ID and scfID -according to an agreement between the SSF and SCF operators. The script simply concatenates these parameters, putting between them the configured separator.<br /> * providing the information in 3 separated parameters:<br /> ** assistingSSPIPAddress - the SRF Number<br /> ** correlationID - the script will set this parameter to either the melody ID or the called party number, encoded in hexified BCD form.<br /> ** scfID - the script will set this parameter to the hexified BCD form of the SCP's GT number.<br /> <br /> Listed bellow are the parameters that need to be configured for the gsmSRF number:<br /> <br /> * '''$srfNumber''' - string. It specifies a number at which the gsmSRF is found.<br /> <br /> * '''$srfSeparator''' - string. Digit(s) used as separator between SRF number, correlationID and sfcID when the assistingSSPIPAddress contains all of them.<br /> <br /> * '''$srfNumber_qualifier''' - string. It specifies the GenericNumber qualifier. It can be one of the following values:<br /> ** ''dialed-digits''<br /> ** ''called-additional''<br /> ** ''caller-failed''<br /> ** ''caller-not-screened''<br /> ** ''terminating''<br /> ** ''connected-additional''<br /> ** ''caller-additional''<br /> ** ''called-original''<br /> ** ''redirecting''<br /> ** ''redirection''<br /> <br /> * '''$srfNumber_complete''' - boolean. It specifies whether the called number is complete or not. It should be complete.<br /> <br /> * '''$srfNumber_nature''' - string. Nature of number. It can have one of the following values:<br /> ** ''unknown''<br /> ** ''international''<br /> ** ''national''<br /> ** ''network-specific''<br /> ** ''subscriber''<br /> ** ''reserved''<br /> ** ''abbreviated''<br /> ** ''extension-reserved''<br /> <br /> * '''$srfNumber_plan''' - string. It's the used numbering plan. It can have one of the following values:<br /> ** ''unknown''<br /> ** ''isdn''<br /> ** ''data''<br /> ** ''telex''<br /> ** ''land-mobile''<br /> ** ''isdn-mobile''<br /> ** ''national''<br /> ** ''private''<br /> ** ''extension-reserved''<br /> <br /> * '''$srfNumber_restrict''' - string. It specifies the presentation of the number. Possible values are:<br /> ** ''allowed''<br /> ** ''restricted''<br /> ** ''unavailable''<br /> ** ''no''<br /> ** ''false''<br /> ** ''yes''<br /> ** ''true''<br /> <br /> * '''$srfNumber_screened''' - string. It specifies the screening indicator for the number. Possible values are:<br /> ** ''user-provided''<br /> ** ''user-provided-passed''<br /> ** ''user-provided-failed''<br /> ** ''network-provided''<br /> ** ''no''<br /> ** ''false''<br /> ** ''yes''<br /> ** ''true''<br /> <br /> * 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.<br /> <br /> * 12. '''$maxPhase''' - integer.Represents the maximum CAMEL phase allowed for CAMEL interaction. If not set, it will default to 4, meaning that all supported CAMEL phases are allowed.<br /> <br /> * 13. '''$msStateNotAllowed''' - array. List of states received for the subscriber in IDP for which the SCP will abandon CRBT handling and will continue with the call. Recognized values are:<br /> ** ''assumedIdle''<br /> ** ''camelBusy''<br /> ** ''netDetNotReachable''<br /> ** ''notProvidedFromVLR''<br /> It has no default, meaning that it will do CRBT handling ignoring the subscriber state.<br /> <br /> * 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.<br /> <br /> * 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.<br /> <br /> '''Note''' - The following parameters need not be set usually:<br /> * ''$host'', ''$port'' - set only if you intend to use TCP communication.<br /> * ''$transTimeout''<br /> * ''$sendAll''<br /> * ''$shortTimer'', ''$mediumTimer'', ''$longTimer''<br /> * ''$maxPhase''<br /> * ''$msStateNotAllowed''<br /> * ''$prearrangedEndOn'' - if there is no prearranged end agreement between operator, this doesn't need to be configured.<br /> <br /> * 16. '''$mynum''' - string. GTT number assigned to this SCP.<br /> <br /> ===Yate side===<br /> <br /> On the Yate side, the ''camel_map'' module must be configured through ''camel_map.conf''. <br /> <br /> For functionality provided through a TCP socket, a <tt>[tcap name]</tt> section should be configured. A section looks like this:<br /> <br /> [tcap camel] -- what comes after ''tcap'' will be the name of the translator<br /> ;enable=no -- enable this translator<br /> tcap=tcap-test-itu -- TCAP to be used by the translator for SS7 network communication, a section with that name should be configured in ''ysigchan.conf''<br /> host=0.0.0.0 -- address on which to listen for incoming applications<br /> port=16101 -- port on which to listen for incoming applications<br /> type=CAMEL -- type of translator (MAP/CAMEL). For the intended case, CAMEL should be set<br /> print-messages=true -- whether or not to print TCAP and XML messages in the logs<br /> add-encoding=false -- whether to add encoding attribute to data translated to XML<br /> <br /> <br /> For functionality through Yate messages, an additional section, named <tt>[local appName]</tt> should be configured:<br /> <br /> [local camelLocal] - what comes after ''local'' will be the name of the application<br /> ;enable=no -- enable this application<br /> translator=camel - which translator should be used. A section named [tcap translatorValue] should be present in the config file.<br /> capabilities=Camel - capabilities supported by this application. CAMEL translator have only one capability and that is ''Camel''.<br /> export_xml_as=both - how to export the XML part: string, object or both?<br /> <br /> '''Note:'''<br /> * setting port to 0 will disable the support for TCP applications<br /> * the name of the local application should match the name set in ''$appName'' for the script<br /> <br /> <br /> ==Script behaviour==<br /> <br /> This is a global script that awaits dialog beginnings from SSFs and it is able to handle CAMEL phases 2, 3 and 4.<br /> The phase used for handling the call will be determined using the information provided in the InitialDP operation using the following rules:<br /> * first, an application context check will be done. As seeing that every phase has a different context assigned, phase will be first determined at this stage.<br /> * if the application context determined a phase 4 handling, in the handling of the InitialDP operation these additional checks will be made:<br /> ** the value for ''supportedCamelPhases'' will be checked. In this parameter, the MSC advertises the CAMEL phases that it can handle. From that list, the SCP will choose the highest phase advertised.<br /> ** the value for ''offeredCamel4Functionalities'' will be checked. SCP will verify that all the CAMEL 4 functionalities required for doing CRBT handling in phase 4 are supported. If that is not so, the SCP will downgrade the phase to phase 2 as seeing that the presence of this parameter implied phase 4 functionality and phase 4 functionality implies, by convention, prior phases support also.<br /> <br /> In case of phase 1 detection, the SCP will end the dialogue either with an Abort with application-context-not-supported, either with a Continue operation for CAMEL.<br /> <br /> An configuration parameter was added (''$maxPhase'') - mainly for testing purposes - in order to limit what phase the SCP will accept.<br /> <br /> <br /> Bellow there is detailed description of how the script will act in different scenarios.<br /> <br /> ===Behaviour CAMEL phase 4===<br /> <br /> <br /> ====Normal procedure for dialogue====<br /> <br /> In case of a normal, error free dialogue, things will proceed according to the describing flow below:<br /> <br /> SSF SCP<br /> 1. --------------------- IDP(serviceKey,termAttemptAuth) --------------------------------><br /> 2. <-------------------- RRBE (tAbandon,leg1) --------------------------------------------<br /> 3. <-------------------- DL (leg2) -------------------------------------------------------<br /> 4. --------------------- DL Result ------------------------------------------------------><br /> 5. <-------------------- ICA (CS2,leg3) --------------------------------------------------<br /> 6. --------------------- ICA Result -----------------------------------------------------><br /> 7. <-------------------- RRBE (oTermSeized,oBusy,oAnswer,oNoAnswer,routeFailure,leg3) ----<br /> 8. <-------------------- CWA (leg3)-------------------------------------------------------<br /> 9. --------------------- ERBE (oTermSeized,leg3) ----------------------------------------><br /> 10. <-------------------- CWA (leg3) ------------------------------------------------------<br /> 11. <-------------------- ETC (CS1) -------------------------------------------------------<br /> 12. --------------------- ERBE (oAnswer,leg3) --------------------------------------------><br /> 13. <-------------------- DFCWA (CS1) -----------------------------------------------------<br /> 14. <-------------------- ML (leg3) -------------------------------------------------------<br /> 15. --------------------- ML Result ------------------------------------------------------><br /> 16. <-------------------- CWA (leg3) ------------------------------------------------------<br /> 17. <-------------------- CWA (CS1) -------------------------------------------------------<br /> <br /> In case of busy received from the called party, the call flow is:<br /> <br /> 1. --------------- ERBE (oCalledPartyBusy, leg3, cause) ----------------------><br /> 2. <-------------- RC (cause received in ERBE/Busy) --------------------------<br /> <br /> ====Abnormal procedures====<br /> <br /> The following schematics will describe the behaviour of the script in certain scenarios. <br /> 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.<br /> <br /> =====Initial DP ServiceKey mismatch / DP mismatch=====<br /> <br /> <br /> SSF SCP<br /> --------------------- IDP(serviceKey,oTermAttemptAuth) -------------------------------><br /> <-------------------- ReturnError(unexpectedDataValue) --------------------------------<br /> <br /> =====Initial DP missing parameters=====<br /> <br /> <br /> SSF SCP<br /> --------------------- IDP(serviceKey,oTermAttemptAuth) -------------------------------><br /> <-------------------- ReturnError(missingParameter) -----------------------------------<br /> <br /> =====Application context mismatch=====<br /> <br /> <br /> SSF SCP<br /> --------------------- IDP(serviceKey,oTermAttemptAuth) -------------------------------><br /> <-------------------- U_Abort (user-application-context-name-not-supported) -----------<br /> <br /> =====Receiving an unsupported CAMEL phase=====<br /> <br /> 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:<br /> <br /> SSF SCP<br /> 1. --------------------- IDP(serviceKey,oTermAttemptAuth) -------------------------------><br /> <-------------------- Continue --------------------------------------------------------<br /> <br /> SSF SCP<br /> 6. --------------------- ICA Result -----------------------------------------------------><br /> <-------------------- ReleaseCall -----------------------------------------------------<br /> <br /> <br /> =====Errors received from SSF / Timeout detected for class 1 and 3 operations=====<br /> <br /> 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.<br /> <br /> SSF SCP<br /> SCP can be in either of the states : 1 / 2 / 3 <br /> <-------------------- Continue --------------------------------------------------------<br /> <br /> <br /> SSF SCP<br /> SCP can be in either of the states : 4 / 5 / 13/ 14 <br /> <-------------------- ReleaseCall --------------------------------------------------------<br /> <br /> <br /> SSF SCP<br /> SCP can be in either of the states : 6 - 11 <br /> 14. <-------------------- MoveLeg --------------------------------------------------------<br /> <br /> ===Behaviour CAMEL phase 2/3===<br /> <br /> ====Normal procedure for dialogue====<br /> <br /> <br /> The following diagrams will detail the operation of the CRBT script in case of normal, error free phase 2/3 handling.<br /> <br /> <br /> SSF SCP<br /> 1. -------------------------- IDP (serviceKey, termAttemptAuth) ---------------------------><br /> 2. <------ RRBE (leg1,tAbandon) & (leg2,tBusy,tAnswer,tNoAnswer)----------------------------<br /> 3. <------------------------- ETC ----------------------------------------------------------<br /> 4. <------------------------- CONT ---------------------------------------------------------<br /> 5. -------------------------- ERBE (leg2,tAnswer) ------------------------------------------<br /> 6. <------------------------- DFC ----------------------------------------------------------<br /> 7. <------------------------- CONT ---------------------------------------------------------<br /> <br /> ====Abnormal procedures====<br /> <br /> <br /> Situations described in sections 2.1.2.1 - 2.1.2.4 shall also apply here:<br /> * [[#Initial DP ServiceKey mismatch / DP mismatch|Initial DP ServiceKey mismatch / DP mismatch]]<br /> * [[#Initial DP missing parameters| Initial DP missing parameters]]<br /> * [[#Application context mismatch| Application context mismatch]]<br /> * [[#Receiving an unsupported CAMEL phase| Receiving an unsupported CAMEL phase]]<br /> <br /> ====Errors received from SSF====<br /> <br /> <br /> SSF SCP<br /> SCP can be in either of the states : 2 / 3 <br /> <-------------------- Continue --------------------------------------------------------</div>

Monica https://ss7api.null.ro/index.php/CRBT_logic CRBT logic 2013-10-28T11:15:30Z

<p>Monica: /* Abnormal procedures */</p> <hr /> <div>The crbt_scp.php is an implementation for a CAMEL gsmSCP application which provides a Colourful Ring Back Tone service by interfacing with a CAMEL gsmSSF.<br /> <br /> Upon service invocation, this script implements the required actions in order to instruct the gsmSSF to provide the required ringback tone.<br /> <br /> ==Configuration==<br /> <br /> ===Script side===<br /> <br /> The CRBT script supports two ways of communicating with Yate:<br /> # One based on the XML protocol, communication being realized through a TCP socket.<br /> # The other one based done through Yate messages, using ''extmodule''.<br /> The way which the script will use is chosen according to configuration - in particular, through the ''$ioType'' setting.<br /> <br /> <br /> Configuration of this script is done through ''config.php''. This allows setting the following parameters:<br /> <br /> * 1. '''$appName'''- value of the ''application'' parameters set in the ''camel.message''. This value is used to check that the message is indeed intented for this script.<br /> <br /> * 2. '''$ioType''' - type of I/O to use to communicate with Yate. The script recognizes these two values:<br /> ** ''TCP'' - use the configured TCP socket to communicate with Yate.<br /> ** ''MSG'' - use messages through exmodule protocol for communication.<br /> <br /> * 3. '''$host''','''$port''' - host and port where the application should connect to in order to communicate with Yate if ''$ioType'' is set to ''TCP''.<br /> <br /> * 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.<br /> <br /> * 5. '''$findMelodyID''' - boolean. It specifies whether the gsmSCF should take the necessary steps in order to find out the required ringtone for the called user. Its default value is false, meaning that the gsmSCF will assume that all requests reaching it are requests for subscribers which have the service activated<br /> <br /> * 6. '''$httpRequest''' - string. It's the HTTP request to be made in order to find out the ringtone associated with the user.<br /> <br /> * 7. '''$myServiceKey''' - integer. The ID of the service provided by this gsmSCF application and which should come in IDP in order to accept the request.<br /> <br /> * 8. '''$myDP''' - string. The DP for which this SCP should be triggered and which should come in IDP in order to accept the request.<br /> <br /> * 9. '''$sendAll''' - bool. If true, it will send all response components batched in a single TCAP message, otherwise it will send them each with its own TCAP message. It is set by default to true.<br /> <br /> * 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:<br /> ** ''prefix_called'' - build the gsmSRF address following this rule <tt>$srfNumber.$srfSeparator.$correlationID.$srfSeparator.$sfcID</tt>.<br /> ** ''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.<br /> <br /> When instructing the SSF to establish a temporary connection to a SRF through an ETC operation, the SCF must provide addressing information to the SSF in regards to the SRF. This information requires:<br /> * the address of the SRF - a routable number<br /> * a correlation ID - that can mean whatever the operators want, but that, according to specification, can be used by the SRF if/when contacting the SCF in order to associate the SSF -> SCF dialogue with the SRF ->SCF dialogue.<br /> * a scfID - an ID for the contacting SCF. This could be used by the SRF to know where to contact the SCF.<br /> <br /> The script provides this information in an ETC operation in 2 ways:<br /> * providing all the above information in the assistingSSPIPAddress. This is done by concatenating the SRF number, correlation ID and scfID -according to an agreement between the SSF and SCF operators. The script simply concatenates these parameters, putting between them the configured separator.<br /> * providing the information in 3 separated parameters:<br /> ** assistingSSPIPAddress - the SRF Number<br /> ** correlationID - the script will set this parameter to either the melody ID or the called party number, encoded in hexified BCD form.<br /> ** scfID - the script will set this parameter to the hexified BCD form of the SCP's GT number.<br /> <br /> Listed bellow are the parameters that need to be configured for the gsmSRF number:<br /> <br /> * '''$srfNumber''' - string. It specifies a number at which the gsmSRF is found.<br /> <br /> * '''$srfSeparator''' - string. Digit(s) used as separator between SRF number, correlationID and sfcID when the assistingSSPIPAddress contains all of them.<br /> <br /> * '''$srfNumber_qualifier''' - string. It specifies the GenericNumber qualifier. It can be one of the following values:<br /> ** ''dialed-digits''<br /> ** ''called-additional''<br /> ** ''caller-failed''<br /> ** ''caller-not-screened''<br /> ** ''terminating''<br /> ** ''connected-additional''<br /> ** ''caller-additional''<br /> ** ''called-original''<br /> ** ''redirecting''<br /> ** ''redirection''<br /> <br /> * '''$srfNumber_complete''' - boolean. It specifies whether the called number is complete or not. It should be complete.<br /> <br /> * '''$srfNumber_nature''' - string. Nature of number. It can have one of the following values:<br /> ** ''unknown''<br /> ** ''international''<br /> ** ''national''<br /> ** ''network-specific''<br /> ** ''subscriber''<br /> ** ''reserved''<br /> ** ''abbreviated''<br /> ** ''extension-reserved''<br /> <br /> * '''$srfNumber_plan''' - string. It's the used numbering plan. It can have one of the following values:<br /> ** ''unknown''<br /> ** ''isdn''<br /> ** ''data''<br /> ** ''telex''<br /> ** ''land-mobile''<br /> ** ''isdn-mobile''<br /> ** ''national''<br /> ** ''private''<br /> ** ''extension-reserved''<br /> <br /> * '''$srfNumber_restrict''' - string. It specifies the presentation of the number. Possible values are:<br /> ** ''allowed''<br /> ** ''restricted''<br /> ** ''unavailable''<br /> ** ''no''<br /> ** ''false''<br /> ** ''yes''<br /> ** ''true''<br /> <br /> * '''$srfNumber_screened''' - string. It specifies the screening indicator for the number. Possible values are:<br /> ** ''user-provided''<br /> ** ''user-provided-passed''<br /> ** ''user-provided-failed''<br /> ** ''network-provided''<br /> ** ''no''<br /> ** ''false''<br /> ** ''yes''<br /> ** ''true''<br /> <br /> * 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.<br /> <br /> * 12. '''$maxPhase''' - integer.Represents the maximum CAMEL phase allowed for CAMEL interaction. If not set, it will default to 4, meaning that all supported CAMEL phases are allowed.<br /> <br /> * 13. '''$msStateNotAllowed''' - array. List of states received for the subscriber in IDP for which the SCP will abandon CRBT handling and will continue with the call. Recognized values are:<br /> ** ''assumedIdle''<br /> ** ''camelBusy''<br /> ** ''netDetNotReachable''<br /> ** ''notProvidedFromVLR''<br /> It has no default, meaning that it will do CRBT handling ignoring the subscriber state.<br /> <br /> * 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.<br /> <br /> * 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.<br /> <br /> '''Note''' - The following parameters need not be set usually:<br /> * ''$host'', ''$port'' - set only if you intend to use TCP communication.<br /> * ''$transTimeout''<br /> * ''$sendAll''<br /> * ''$shortTimer'', ''$mediumTimer'', ''$longTimer''<br /> * ''$maxPhase''<br /> * ''$msStateNotAllowed''<br /> * ''$prearrangedEndOn'' - if there is no prearranged end agreement between operator, this doesn't need to be configured.<br /> <br /> * 16. '''$mynum''' - string. GTT number assigned to this SCP.<br /> <br /> ===Yate side===<br /> <br /> On the Yate side, the ''camel_map'' module must be configured through ''camel_map.conf''. <br /> <br /> For functionality provided through a TCP socket, a <tt>[tcap name]</tt> section should be configured. A section looks like this:<br /> <br /> [tcap camel] -- what comes after ''tcap'' will be the name of the translator<br /> ;enable=no -- enable this translator<br /> tcap=tcap-test-itu -- TCAP to be used by the translator for SS7 network communication, a section with that name should be configured in ''ysigchan.conf''<br /> host=0.0.0.0 -- address on which to listen for incoming applications<br /> port=16101 -- port on which to listen for incoming applications<br /> type=CAMEL -- type of translator (MAP/CAMEL). For the intended case, CAMEL should be set<br /> print-messages=true -- whether or not to print TCAP and XML messages in the logs<br /> add-encoding=false -- whether to add encoding attribute to data translated to XML<br /> <br /> <br /> For functionality through Yate messages, an additional section, named <tt>[local appName]</tt> should be configured:<br /> <br /> [local camelLocal] - what comes after ''local'' will be the name of the application<br /> ;enable=no -- enable this application<br /> translator=camel - which translator should be used. A section named [tcap translatorValue] should be present in the config file.<br /> capabilities=Camel - capabilities supported by this application. CAMEL translator have only one capability and that is ''Camel''.<br /> export_xml_as=both - how to export the XML part: string, object or both?<br /> <br /> '''Note:'''<br /> * setting port to 0 will disable the support for TCP applications<br /> * the name of the local application should match the name set in ''$appName'' for the script<br /> <br /> <br /> ==Script behaviour==<br /> <br /> This is a global script that awaits dialog beginnings from SSFs and it is able to handle CAMEL phases 2, 3 and 4.<br /> The phase used for handling the call will be determined using the information provided in the InitialDP operation using the following rules:<br /> * first, an application context check will be done. As seeing that every phase has a different context assigned, phase will be first determined at this stage.<br /> * if the application context determined a phase 4 handling, in the handling of the InitialDP operation these additional checks will be made:<br /> ** the value for ''supportedCamelPhases'' will be checked. In this parameter, the MSC advertises the CAMEL phases that it can handle. From that list, the SCP will choose the highest phase advertised.<br /> ** the value for ''offeredCamel4Functionalities'' will be checked. SCP will verify that all the CAMEL 4 functionalities required for doing CRBT handling in phase 4 are supported. If that is not so, the SCP will downgrade the phase to phase 2 as seeing that the presence of this parameter implied phase 4 functionality and phase 4 functionality implies, by convention, prior phases support also.<br /> <br /> In case of phase 1 detection, the SCP will end the dialogue either with an Abort with application-context-not-supported, either with a Continue operation for CAMEL.<br /> <br /> An configuration parameter was added (''$maxPhase'') - mainly for testing purposes - in order to limit what phase the SCP will accept.<br /> <br /> <br /> Bellow there is detailed description of how the script will act in different scenarios.<br /> <br /> ===Behaviour CAMEL phase 4===<br /> <br /> <br /> ====Normal procedure for dialogue====<br /> <br /> In case of a normal, error free dialogue, things will proceed according to the describing flow below:<br /> <br /> SSF SCP<br /> 1. --------------------- IDP(serviceKey,termAttemptAuth) --------------------------------><br /> 2. <-------------------- RRBE (tAbandon,leg1) --------------------------------------------<br /> 3. <-------------------- DL (leg2) -------------------------------------------------------<br /> 4. --------------------- DL Result ------------------------------------------------------><br /> 5. <-------------------- ICA (CS2,leg3) --------------------------------------------------<br /> 6. --------------------- ICA Result -----------------------------------------------------><br /> 7. <-------------------- RRBE (oTermSeized,oBusy,oAnswer,oNoAnswer,routeFailure,leg3) ----<br /> 8. <-------------------- CWA (leg3)-------------------------------------------------------<br /> 9. --------------------- ERBE (oTermSeized,leg3) ----------------------------------------><br /> 10. <-------------------- CWA (leg3) ------------------------------------------------------<br /> 11. <-------------------- ETC (CS1) -------------------------------------------------------<br /> 12. --------------------- ERBE (oAnswer,leg3) --------------------------------------------><br /> 13. <-------------------- DFCWA (CS1) -----------------------------------------------------<br /> 14. <-------------------- ML (leg3) -------------------------------------------------------<br /> 15. --------------------- ML Result ------------------------------------------------------><br /> 16. <-------------------- CWA (leg3) ------------------------------------------------------<br /> 17. <-------------------- CWA (CS1) -------------------------------------------------------<br /> <br /> In case of busy received from the called party, the call flow is:<br /> <br /> 1. --------------- ERBE (oCalledPartyBusy, leg3, cause) ----------------------><br /> 2. <-------------- RC (cause received in ERBE/Busy) --------------------------<br /> <br /> ====Abnormal procedures====<br /> <br /> The following schematics will describe the behaviour of the script in certain scenarios. <br /> 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.<br /> <br /> =====Initial DP ServiceKey mismatch / DP mismatch=====<br /> <br /> <br /> SSF SCP<br /> --------------------- IDP(serviceKey,oTermAttemptAuth) -------------------------------><br /> <-------------------- ReturnError(unexpectedDataValue) --------------------------------<br /> <br /> =====Initial DP missing parameters=====<br /> <br /> <br /> SSF SCP<br /> --------------------- IDP(serviceKey,oTermAttemptAuth) -------------------------------><br /> <-------------------- ReturnError(missingParameter) -----------------------------------<br /> <br /> =====Application context mismatch=====<br /> <br /> <br /> SSF SCP<br /> --------------------- IDP(serviceKey,oTermAttemptAuth) -------------------------------><br /> <-------------------- U_Abort (user-application-context-name-not-supported) -----------<br /> <br /> =====Receiving an unsupported CAMEL phase=====<br /> <br /> 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:<br /> <br /> SSF SCP<br /> 1. --------------------- IDP(serviceKey,oTermAttemptAuth) -------------------------------><br /> <-------------------- Continue --------------------------------------------------------<br /> <br /> SSF SCP<br /> 6. --------------------- ICA Result -----------------------------------------------------><br /> <-------------------- ReleaseCall -----------------------------------------------------<br /> <br /> <br /> =====Errors received from SSF / Timeout detected for class 1 and 3 operations=====<br /> <br /> 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.<br /> <br /> SSF SCP<br /> SCP can be in either of the states : 1 / 2 / 3 <br /> <-------------------- Continue --------------------------------------------------------<br /> <br /> <br /> SSF SCP<br /> SCP can be in either of the states : 4 / 5 / 13/ 14 <br /> <-------------------- ReleaseCall --------------------------------------------------------<br /> <br /> <br /> SSF SCP<br /> SCP can be in either of the states : 6 - 11 <br /> 14. <-------------------- MoveLeg --------------------------------------------------------<br /> <br /> ===Behaviour CAMEL phase 2/3===<br /> <br /> ====Normal procedure for dialogue====<br /> <br /> <br /> The following diagrams will detail the operation of the CRBT script in case of normal, error free phase 2/3 handling.<br /> <br /> <br /> SSF SCP<br /> 1. -------------------------- IDP (serviceKey, termAttemptAuth) ---------------------------><br /> 2. <------ RRBE (leg1,tAbandon) & (leg2,tBusy,tAnswer,tNoAnswer)----------------------------<br /> 3. <------------------------- ETC ----------------------------------------------------------<br /> 4. <------------------------- CONT ---------------------------------------------------------<br /> 5. -------------------------- ERBE (leg2,tAnswer) ------------------------------------------<br /> 6. <------------------------- DFC ----------------------------------------------------------<br /> 7. <------------------------- CONT ---------------------------------------------------------<br /> <br /> ====Abnormal procedures====<br /> <br /> <br /> Situations described in sections 2.1.2.1 - 2.1.2.4 shall also apply here.<br /> * [[#Initial DP ServiceKey mismatch / DP mismatch ]]<br /> * [[#Initial DP missing parameters ]]<br /> * [[#Application context mismatch ]]<br /> * [[#Receiving an unsupported CAMEL phase ]]<br /> <br /> ====Errors received from SSF====<br /> <br /> <br /> SSF SCP<br /> SCP can be in either of the states : 2 / 3 <br /> <-------------------- Continue --------------------------------------------------------</div>

Monica https://ss7api.null.ro/index.php/CRBT_logic CRBT logic 2013-10-28T11:13:34Z

<p>Monica: /* 1.2.5 Errors received from SSF / Timeout detected for class 1 and 3 operations */</p> <hr /> <div>The crbt_scp.php is an implementation for a CAMEL gsmSCP application which provides a Colourful Ring Back Tone service by interfacing with a CAMEL gsmSSF.<br /> <br /> Upon service invocation, this script implements the required actions in order to instruct the gsmSSF to provide the required ringback tone.<br /> <br /> ==Configuration==<br /> <br /> ===Script side===<br /> <br /> The CRBT script supports two ways of communicating with Yate:<br /> # One based on the XML protocol, communication being realized through a TCP socket.<br /> # The other one based done through Yate messages, using ''extmodule''.<br /> The way which the script will use is chosen according to configuration - in particular, through the ''$ioType'' setting.<br /> <br /> <br /> Configuration of this script is done through ''config.php''. This allows setting the following parameters:<br /> <br /> * 1. '''$appName'''- value of the ''application'' parameters set in the ''camel.message''. This value is used to check that the message is indeed intented for this script.<br /> <br /> * 2. '''$ioType''' - type of I/O to use to communicate with Yate. The script recognizes these two values:<br /> ** ''TCP'' - use the configured TCP socket to communicate with Yate.<br /> ** ''MSG'' - use messages through exmodule protocol for communication.<br /> <br /> * 3. '''$host''','''$port''' - host and port where the application should connect to in order to communicate with Yate if ''$ioType'' is set to ''TCP''.<br /> <br /> * 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.<br /> <br /> * 5. '''$findMelodyID''' - boolean. It specifies whether the gsmSCF should take the necessary steps in order to find out the required ringtone for the called user. Its default value is false, meaning that the gsmSCF will assume that all requests reaching it are requests for subscribers which have the service activated<br /> <br /> * 6. '''$httpRequest''' - string. It's the HTTP request to be made in order to find out the ringtone associated with the user.<br /> <br /> * 7. '''$myServiceKey''' - integer. The ID of the service provided by this gsmSCF application and which should come in IDP in order to accept the request.<br /> <br /> * 8. '''$myDP''' - string. The DP for which this SCP should be triggered and which should come in IDP in order to accept the request.<br /> <br /> * 9. '''$sendAll''' - bool. If true, it will send all response components batched in a single TCAP message, otherwise it will send them each with its own TCAP message. It is set by default to true.<br /> <br /> * 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:<br /> ** ''prefix_called'' - build the gsmSRF address following this rule <tt>$srfNumber.$srfSeparator.$correlationID.$srfSeparator.$sfcID</tt>.<br /> ** ''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.<br /> <br /> When instructing the SSF to establish a temporary connection to a SRF through an ETC operation, the SCF must provide addressing information to the SSF in regards to the SRF. This information requires:<br /> * the address of the SRF - a routable number<br /> * a correlation ID - that can mean whatever the operators want, but that, according to specification, can be used by the SRF if/when contacting the SCF in order to associate the SSF -> SCF dialogue with the SRF ->SCF dialogue.<br /> * a scfID - an ID for the contacting SCF. This could be used by the SRF to know where to contact the SCF.<br /> <br /> The script provides this information in an ETC operation in 2 ways:<br /> * providing all the above information in the assistingSSPIPAddress. This is done by concatenating the SRF number, correlation ID and scfID -according to an agreement between the SSF and SCF operators. The script simply concatenates these parameters, putting between them the configured separator.<br /> * providing the information in 3 separated parameters:<br /> ** assistingSSPIPAddress - the SRF Number<br /> ** correlationID - the script will set this parameter to either the melody ID or the called party number, encoded in hexified BCD form.<br /> ** scfID - the script will set this parameter to the hexified BCD form of the SCP's GT number.<br /> <br /> Listed bellow are the parameters that need to be configured for the gsmSRF number:<br /> <br /> * '''$srfNumber''' - string. It specifies a number at which the gsmSRF is found.<br /> <br /> * '''$srfSeparator''' - string. Digit(s) used as separator between SRF number, correlationID and sfcID when the assistingSSPIPAddress contains all of them.<br /> <br /> * '''$srfNumber_qualifier''' - string. It specifies the GenericNumber qualifier. It can be one of the following values:<br /> ** ''dialed-digits''<br /> ** ''called-additional''<br /> ** ''caller-failed''<br /> ** ''caller-not-screened''<br /> ** ''terminating''<br /> ** ''connected-additional''<br /> ** ''caller-additional''<br /> ** ''called-original''<br /> ** ''redirecting''<br /> ** ''redirection''<br /> <br /> * '''$srfNumber_complete''' - boolean. It specifies whether the called number is complete or not. It should be complete.<br /> <br /> * '''$srfNumber_nature''' - string. Nature of number. It can have one of the following values:<br /> ** ''unknown''<br /> ** ''international''<br /> ** ''national''<br /> ** ''network-specific''<br /> ** ''subscriber''<br /> ** ''reserved''<br /> ** ''abbreviated''<br /> ** ''extension-reserved''<br /> <br /> * '''$srfNumber_plan''' - string. It's the used numbering plan. It can have one of the following values:<br /> ** ''unknown''<br /> ** ''isdn''<br /> ** ''data''<br /> ** ''telex''<br /> ** ''land-mobile''<br /> ** ''isdn-mobile''<br /> ** ''national''<br /> ** ''private''<br /> ** ''extension-reserved''<br /> <br /> * '''$srfNumber_restrict''' - string. It specifies the presentation of the number. Possible values are:<br /> ** ''allowed''<br /> ** ''restricted''<br /> ** ''unavailable''<br /> ** ''no''<br /> ** ''false''<br /> ** ''yes''<br /> ** ''true''<br /> <br /> * '''$srfNumber_screened''' - string. It specifies the screening indicator for the number. Possible values are:<br /> ** ''user-provided''<br /> ** ''user-provided-passed''<br /> ** ''user-provided-failed''<br /> ** ''network-provided''<br /> ** ''no''<br /> ** ''false''<br /> ** ''yes''<br /> ** ''true''<br /> <br /> * 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.<br /> <br /> * 12. '''$maxPhase''' - integer.Represents the maximum CAMEL phase allowed for CAMEL interaction. If not set, it will default to 4, meaning that all supported CAMEL phases are allowed.<br /> <br /> * 13. '''$msStateNotAllowed''' - array. List of states received for the subscriber in IDP for which the SCP will abandon CRBT handling and will continue with the call. Recognized values are:<br /> ** ''assumedIdle''<br /> ** ''camelBusy''<br /> ** ''netDetNotReachable''<br /> ** ''notProvidedFromVLR''<br /> It has no default, meaning that it will do CRBT handling ignoring the subscriber state.<br /> <br /> * 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.<br /> <br /> * 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.<br /> <br /> '''Note''' - The following parameters need not be set usually:<br /> * ''$host'', ''$port'' - set only if you intend to use TCP communication.<br /> * ''$transTimeout''<br /> * ''$sendAll''<br /> * ''$shortTimer'', ''$mediumTimer'', ''$longTimer''<br /> * ''$maxPhase''<br /> * ''$msStateNotAllowed''<br /> * ''$prearrangedEndOn'' - if there is no prearranged end agreement between operator, this doesn't need to be configured.<br /> <br /> * 16. '''$mynum''' - string. GTT number assigned to this SCP.<br /> <br /> ===Yate side===<br /> <br /> On the Yate side, the ''camel_map'' module must be configured through ''camel_map.conf''. <br /> <br /> For functionality provided through a TCP socket, a <tt>[tcap name]</tt> section should be configured. A section looks like this:<br /> <br /> [tcap camel] -- what comes after ''tcap'' will be the name of the translator<br /> ;enable=no -- enable this translator<br /> tcap=tcap-test-itu -- TCAP to be used by the translator for SS7 network communication, a section with that name should be configured in ''ysigchan.conf''<br /> host=0.0.0.0 -- address on which to listen for incoming applications<br /> port=16101 -- port on which to listen for incoming applications<br /> type=CAMEL -- type of translator (MAP/CAMEL). For the intended case, CAMEL should be set<br /> print-messages=true -- whether or not to print TCAP and XML messages in the logs<br /> add-encoding=false -- whether to add encoding attribute to data translated to XML<br /> <br /> <br /> For functionality through Yate messages, an additional section, named <tt>[local appName]</tt> should be configured:<br /> <br /> [local camelLocal] - what comes after ''local'' will be the name of the application<br /> ;enable=no -- enable this application<br /> translator=camel - which translator should be used. A section named [tcap translatorValue] should be present in the config file.<br /> capabilities=Camel - capabilities supported by this application. CAMEL translator have only one capability and that is ''Camel''.<br /> export_xml_as=both - how to export the XML part: string, object or both?<br /> <br /> '''Note:'''<br /> * setting port to 0 will disable the support for TCP applications<br /> * the name of the local application should match the name set in ''$appName'' for the script<br /> <br /> <br /> ==Script behaviour==<br /> <br /> This is a global script that awaits dialog beginnings from SSFs and it is able to handle CAMEL phases 2, 3 and 4.<br /> The phase used for handling the call will be determined using the information provided in the InitialDP operation using the following rules:<br /> * first, an application context check will be done. As seeing that every phase has a different context assigned, phase will be first determined at this stage.<br /> * if the application context determined a phase 4 handling, in the handling of the InitialDP operation these additional checks will be made:<br /> ** the value for ''supportedCamelPhases'' will be checked. In this parameter, the MSC advertises the CAMEL phases that it can handle. From that list, the SCP will choose the highest phase advertised.<br /> ** the value for ''offeredCamel4Functionalities'' will be checked. SCP will verify that all the CAMEL 4 functionalities required for doing CRBT handling in phase 4 are supported. If that is not so, the SCP will downgrade the phase to phase 2 as seeing that the presence of this parameter implied phase 4 functionality and phase 4 functionality implies, by convention, prior phases support also.<br /> <br /> In case of phase 1 detection, the SCP will end the dialogue either with an Abort with application-context-not-supported, either with a Continue operation for CAMEL.<br /> <br /> An configuration parameter was added (''$maxPhase'') - mainly for testing purposes - in order to limit what phase the SCP will accept.<br /> <br /> <br /> Bellow there is detailed description of how the script will act in different scenarios.<br /> <br /> ===Behaviour CAMEL phase 4===<br /> <br /> <br /> ====Normal procedure for dialogue====<br /> <br /> In case of a normal, error free dialogue, things will proceed according to the describing flow below:<br /> <br /> SSF SCP<br /> 1. --------------------- IDP(serviceKey,termAttemptAuth) --------------------------------><br /> 2. <-------------------- RRBE (tAbandon,leg1) --------------------------------------------<br /> 3. <-------------------- DL (leg2) -------------------------------------------------------<br /> 4. --------------------- DL Result ------------------------------------------------------><br /> 5. <-------------------- ICA (CS2,leg3) --------------------------------------------------<br /> 6. --------------------- ICA Result -----------------------------------------------------><br /> 7. <-------------------- RRBE (oTermSeized,oBusy,oAnswer,oNoAnswer,routeFailure,leg3) ----<br /> 8. <-------------------- CWA (leg3)-------------------------------------------------------<br /> 9. --------------------- ERBE (oTermSeized,leg3) ----------------------------------------><br /> 10. <-------------------- CWA (leg3) ------------------------------------------------------<br /> 11. <-------------------- ETC (CS1) -------------------------------------------------------<br /> 12. --------------------- ERBE (oAnswer,leg3) --------------------------------------------><br /> 13. <-------------------- DFCWA (CS1) -----------------------------------------------------<br /> 14. <-------------------- ML (leg3) -------------------------------------------------------<br /> 15. --------------------- ML Result ------------------------------------------------------><br /> 16. <-------------------- CWA (leg3) ------------------------------------------------------<br /> 17. <-------------------- CWA (CS1) -------------------------------------------------------<br /> <br /> In case of busy received from the called party, the call flow is:<br /> <br /> 1. --------------- ERBE (oCalledPartyBusy, leg3, cause) ----------------------><br /> 2. <-------------- RC (cause received in ERBE/Busy) --------------------------<br /> <br /> ====Abnormal procedures====<br /> <br /> The following schematics will describe the behaviour of the script in certain scenarios. <br /> 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.<br /> <br /> =====Initial DP ServiceKey mismatch / DP mismatch=====<br /> <br /> <br /> SSF SCP<br /> --------------------- IDP(serviceKey,oTermAttemptAuth) -------------------------------><br /> <-------------------- ReturnError(unexpectedDataValue) --------------------------------<br /> <br /> =====Initial DP missing parameters=====<br /> <br /> <br /> SSF SCP<br /> --------------------- IDP(serviceKey,oTermAttemptAuth) -------------------------------><br /> <-------------------- ReturnError(missingParameter) -----------------------------------<br /> <br /> =====Application context mismatch=====<br /> <br /> <br /> SSF SCP<br /> --------------------- IDP(serviceKey,oTermAttemptAuth) -------------------------------><br /> <-------------------- U_Abort (user-application-context-name-not-supported) -----------<br /> <br /> =====Receiving an unsupported CAMEL phase=====<br /> <br /> 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:<br /> <br /> SSF SCP<br /> 1. --------------------- IDP(serviceKey,oTermAttemptAuth) -------------------------------><br /> <-------------------- Continue --------------------------------------------------------<br /> <br /> SSF SCP<br /> 6. --------------------- ICA Result -----------------------------------------------------><br /> <-------------------- ReleaseCall -----------------------------------------------------<br /> <br /> <br /> =====Errors received from SSF / Timeout detected for class 1 and 3 operations=====<br /> <br /> 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.<br /> <br /> SSF SCP<br /> SCP can be in either of the states : 1 / 2 / 3 <br /> <-------------------- Continue --------------------------------------------------------<br /> <br /> <br /> SSF SCP<br /> SCP can be in either of the states : 4 / 5 / 13/ 14 <br /> <-------------------- ReleaseCall --------------------------------------------------------<br /> <br /> <br /> SSF SCP<br /> SCP can be in either of the states : 6 - 11 <br /> 14. <-------------------- MoveLeg --------------------------------------------------------<br /> <br /> ===Behaviour CAMEL phase 2/3===<br /> <br /> ====Normal procedure for dialogue====<br /> <br /> <br /> The following diagrams will detail the operation of the CRBT script in case of normal, error free phase 2/3 handling.<br /> <br /> <br /> SSF SCP<br /> 1. -------------------------- IDP (serviceKey, termAttemptAuth) ---------------------------><br /> 2. <------ RRBE (leg1,tAbandon) & (leg2,tBusy,tAnswer,tNoAnswer)----------------------------<br /> 3. <------------------------- ETC ----------------------------------------------------------<br /> 4. <------------------------- CONT ---------------------------------------------------------<br /> 5. -------------------------- ERBE (leg2,tAnswer) ------------------------------------------<br /> 6. <------------------------- DFC ----------------------------------------------------------<br /> 7. <------------------------- CONT ---------------------------------------------------------<br /> <br /> ====Abnormal procedures====<br /> <br /> <br /> Situations described in sections 1.2.1 - 1.2.4 shall also apply here.<br /> <br /> ====Errors received from SSF====<br /> <br /> <br /> SSF SCP<br /> SCP can be in either of the states : 2 / 3 <br /> <-------------------- Continue --------------------------------------------------------</div>

Monica https://ss7api.null.ro/index.php/CRBT_logic CRBT logic 2013-10-28T11:13:20Z

<p>Monica: /* 1.2.3 Application context mismatch */</p> <hr /> <div>The crbt_scp.php is an implementation for a CAMEL gsmSCP application which provides a Colourful Ring Back Tone service by interfacing with a CAMEL gsmSSF.<br /> <br /> Upon service invocation, this script implements the required actions in order to instruct the gsmSSF to provide the required ringback tone.<br /> <br /> ==Configuration==<br /> <br /> ===Script side===<br /> <br /> The CRBT script supports two ways of communicating with Yate:<br /> # One based on the XML protocol, communication being realized through a TCP socket.<br /> # The other one based done through Yate messages, using ''extmodule''.<br /> The way which the script will use is chosen according to configuration - in particular, through the ''$ioType'' setting.<br /> <br /> <br /> Configuration of this script is done through ''config.php''. This allows setting the following parameters:<br /> <br /> * 1. '''$appName'''- value of the ''application'' parameters set in the ''camel.message''. This value is used to check that the message is indeed intented for this script.<br /> <br /> * 2. '''$ioType''' - type of I/O to use to communicate with Yate. The script recognizes these two values:<br /> ** ''TCP'' - use the configured TCP socket to communicate with Yate.<br /> ** ''MSG'' - use messages through exmodule protocol for communication.<br /> <br /> * 3. '''$host''','''$port''' - host and port where the application should connect to in order to communicate with Yate if ''$ioType'' is set to ''TCP''.<br /> <br /> * 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.<br /> <br /> * 5. '''$findMelodyID''' - boolean. It specifies whether the gsmSCF should take the necessary steps in order to find out the required ringtone for the called user. Its default value is false, meaning that the gsmSCF will assume that all requests reaching it are requests for subscribers which have the service activated<br /> <br /> * 6. '''$httpRequest''' - string. It's the HTTP request to be made in order to find out the ringtone associated with the user.<br /> <br /> * 7. '''$myServiceKey''' - integer. The ID of the service provided by this gsmSCF application and which should come in IDP in order to accept the request.<br /> <br /> * 8. '''$myDP''' - string. The DP for which this SCP should be triggered and which should come in IDP in order to accept the request.<br /> <br /> * 9. '''$sendAll''' - bool. If true, it will send all response components batched in a single TCAP message, otherwise it will send them each with its own TCAP message. It is set by default to true.<br /> <br /> * 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:<br /> ** ''prefix_called'' - build the gsmSRF address following this rule <tt>$srfNumber.$srfSeparator.$correlationID.$srfSeparator.$sfcID</tt>.<br /> ** ''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.<br /> <br /> When instructing the SSF to establish a temporary connection to a SRF through an ETC operation, the SCF must provide addressing information to the SSF in regards to the SRF. This information requires:<br /> * the address of the SRF - a routable number<br /> * a correlation ID - that can mean whatever the operators want, but that, according to specification, can be used by the SRF if/when contacting the SCF in order to associate the SSF -> SCF dialogue with the SRF ->SCF dialogue.<br /> * a scfID - an ID for the contacting SCF. This could be used by the SRF to know where to contact the SCF.<br /> <br /> The script provides this information in an ETC operation in 2 ways:<br /> * providing all the above information in the assistingSSPIPAddress. This is done by concatenating the SRF number, correlation ID and scfID -according to an agreement between the SSF and SCF operators. The script simply concatenates these parameters, putting between them the configured separator.<br /> * providing the information in 3 separated parameters:<br /> ** assistingSSPIPAddress - the SRF Number<br /> ** correlationID - the script will set this parameter to either the melody ID or the called party number, encoded in hexified BCD form.<br /> ** scfID - the script will set this parameter to the hexified BCD form of the SCP's GT number.<br /> <br /> Listed bellow are the parameters that need to be configured for the gsmSRF number:<br /> <br /> * '''$srfNumber''' - string. It specifies a number at which the gsmSRF is found.<br /> <br /> * '''$srfSeparator''' - string. Digit(s) used as separator between SRF number, correlationID and sfcID when the assistingSSPIPAddress contains all of them.<br /> <br /> * '''$srfNumber_qualifier''' - string. It specifies the GenericNumber qualifier. It can be one of the following values:<br /> ** ''dialed-digits''<br /> ** ''called-additional''<br /> ** ''caller-failed''<br /> ** ''caller-not-screened''<br /> ** ''terminating''<br /> ** ''connected-additional''<br /> ** ''caller-additional''<br /> ** ''called-original''<br /> ** ''redirecting''<br /> ** ''redirection''<br /> <br /> * '''$srfNumber_complete''' - boolean. It specifies whether the called number is complete or not. It should be complete.<br /> <br /> * '''$srfNumber_nature''' - string. Nature of number. It can have one of the following values:<br /> ** ''unknown''<br /> ** ''international''<br /> ** ''national''<br /> ** ''network-specific''<br /> ** ''subscriber''<br /> ** ''reserved''<br /> ** ''abbreviated''<br /> ** ''extension-reserved''<br /> <br /> * '''$srfNumber_plan''' - string. It's the used numbering plan. It can have one of the following values:<br /> ** ''unknown''<br /> ** ''isdn''<br /> ** ''data''<br /> ** ''telex''<br /> ** ''land-mobile''<br /> ** ''isdn-mobile''<br /> ** ''national''<br /> ** ''private''<br /> ** ''extension-reserved''<br /> <br /> * '''$srfNumber_restrict''' - string. It specifies the presentation of the number. Possible values are:<br /> ** ''allowed''<br /> ** ''restricted''<br /> ** ''unavailable''<br /> ** ''no''<br /> ** ''false''<br /> ** ''yes''<br /> ** ''true''<br /> <br /> * '''$srfNumber_screened''' - string. It specifies the screening indicator for the number. Possible values are:<br /> ** ''user-provided''<br /> ** ''user-provided-passed''<br /> ** ''user-provided-failed''<br /> ** ''network-provided''<br /> ** ''no''<br /> ** ''false''<br /> ** ''yes''<br /> ** ''true''<br /> <br /> * 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.<br /> <br /> * 12. '''$maxPhase''' - integer.Represents the maximum CAMEL phase allowed for CAMEL interaction. If not set, it will default to 4, meaning that all supported CAMEL phases are allowed.<br /> <br /> * 13. '''$msStateNotAllowed''' - array. List of states received for the subscriber in IDP for which the SCP will abandon CRBT handling and will continue with the call. Recognized values are:<br /> ** ''assumedIdle''<br /> ** ''camelBusy''<br /> ** ''netDetNotReachable''<br /> ** ''notProvidedFromVLR''<br /> It has no default, meaning that it will do CRBT handling ignoring the subscriber state.<br /> <br /> * 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.<br /> <br /> * 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.<br /> <br /> '''Note''' - The following parameters need not be set usually:<br /> * ''$host'', ''$port'' - set only if you intend to use TCP communication.<br /> * ''$transTimeout''<br /> * ''$sendAll''<br /> * ''$shortTimer'', ''$mediumTimer'', ''$longTimer''<br /> * ''$maxPhase''<br /> * ''$msStateNotAllowed''<br /> * ''$prearrangedEndOn'' - if there is no prearranged end agreement between operator, this doesn't need to be configured.<br /> <br /> * 16. '''$mynum''' - string. GTT number assigned to this SCP.<br /> <br /> ===Yate side===<br /> <br /> On the Yate side, the ''camel_map'' module must be configured through ''camel_map.conf''. <br /> <br /> For functionality provided through a TCP socket, a <tt>[tcap name]</tt> section should be configured. A section looks like this:<br /> <br /> [tcap camel] -- what comes after ''tcap'' will be the name of the translator<br /> ;enable=no -- enable this translator<br /> tcap=tcap-test-itu -- TCAP to be used by the translator for SS7 network communication, a section with that name should be configured in ''ysigchan.conf''<br /> host=0.0.0.0 -- address on which to listen for incoming applications<br /> port=16101 -- port on which to listen for incoming applications<br /> type=CAMEL -- type of translator (MAP/CAMEL). For the intended case, CAMEL should be set<br /> print-messages=true -- whether or not to print TCAP and XML messages in the logs<br /> add-encoding=false -- whether to add encoding attribute to data translated to XML<br /> <br /> <br /> For functionality through Yate messages, an additional section, named <tt>[local appName]</tt> should be configured:<br /> <br /> [local camelLocal] - what comes after ''local'' will be the name of the application<br /> ;enable=no -- enable this application<br /> translator=camel - which translator should be used. A section named [tcap translatorValue] should be present in the config file.<br /> capabilities=Camel - capabilities supported by this application. CAMEL translator have only one capability and that is ''Camel''.<br /> export_xml_as=both - how to export the XML part: string, object or both?<br /> <br /> '''Note:'''<br /> * setting port to 0 will disable the support for TCP applications<br /> * the name of the local application should match the name set in ''$appName'' for the script<br /> <br /> <br /> ==Script behaviour==<br /> <br /> This is a global script that awaits dialog beginnings from SSFs and it is able to handle CAMEL phases 2, 3 and 4.<br /> The phase used for handling the call will be determined using the information provided in the InitialDP operation using the following rules:<br /> * first, an application context check will be done. As seeing that every phase has a different context assigned, phase will be first determined at this stage.<br /> * if the application context determined a phase 4 handling, in the handling of the InitialDP operation these additional checks will be made:<br /> ** the value for ''supportedCamelPhases'' will be checked. In this parameter, the MSC advertises the CAMEL phases that it can handle. From that list, the SCP will choose the highest phase advertised.<br /> ** the value for ''offeredCamel4Functionalities'' will be checked. SCP will verify that all the CAMEL 4 functionalities required for doing CRBT handling in phase 4 are supported. If that is not so, the SCP will downgrade the phase to phase 2 as seeing that the presence of this parameter implied phase 4 functionality and phase 4 functionality implies, by convention, prior phases support also.<br /> <br /> In case of phase 1 detection, the SCP will end the dialogue either with an Abort with application-context-not-supported, either with a Continue operation for CAMEL.<br /> <br /> An configuration parameter was added (''$maxPhase'') - mainly for testing purposes - in order to limit what phase the SCP will accept.<br /> <br /> <br /> Bellow there is detailed description of how the script will act in different scenarios.<br /> <br /> ===Behaviour CAMEL phase 4===<br /> <br /> <br /> ====Normal procedure for dialogue====<br /> <br /> In case of a normal, error free dialogue, things will proceed according to the describing flow below:<br /> <br /> SSF SCP<br /> 1. --------------------- IDP(serviceKey,termAttemptAuth) --------------------------------><br /> 2. <-------------------- RRBE (tAbandon,leg1) --------------------------------------------<br /> 3. <-------------------- DL (leg2) -------------------------------------------------------<br /> 4. --------------------- DL Result ------------------------------------------------------><br /> 5. <-------------------- ICA (CS2,leg3) --------------------------------------------------<br /> 6. --------------------- ICA Result -----------------------------------------------------><br /> 7. <-------------------- RRBE (oTermSeized,oBusy,oAnswer,oNoAnswer,routeFailure,leg3) ----<br /> 8. <-------------------- CWA (leg3)-------------------------------------------------------<br /> 9. --------------------- ERBE (oTermSeized,leg3) ----------------------------------------><br /> 10. <-------------------- CWA (leg3) ------------------------------------------------------<br /> 11. <-------------------- ETC (CS1) -------------------------------------------------------<br /> 12. --------------------- ERBE (oAnswer,leg3) --------------------------------------------><br /> 13. <-------------------- DFCWA (CS1) -----------------------------------------------------<br /> 14. <-------------------- ML (leg3) -------------------------------------------------------<br /> 15. --------------------- ML Result ------------------------------------------------------><br /> 16. <-------------------- CWA (leg3) ------------------------------------------------------<br /> 17. <-------------------- CWA (CS1) -------------------------------------------------------<br /> <br /> In case of busy received from the called party, the call flow is:<br /> <br /> 1. --------------- ERBE (oCalledPartyBusy, leg3, cause) ----------------------><br /> 2. <-------------- RC (cause received in ERBE/Busy) --------------------------<br /> <br /> ====Abnormal procedures====<br /> <br /> The following schematics will describe the behaviour of the script in certain scenarios. <br /> 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.<br /> <br /> =====Initial DP ServiceKey mismatch / DP mismatch=====<br /> <br /> <br /> SSF SCP<br /> --------------------- IDP(serviceKey,oTermAttemptAuth) -------------------------------><br /> <-------------------- ReturnError(unexpectedDataValue) --------------------------------<br /> <br /> =====Initial DP missing parameters=====<br /> <br /> <br /> SSF SCP<br /> --------------------- IDP(serviceKey,oTermAttemptAuth) -------------------------------><br /> <-------------------- ReturnError(missingParameter) -----------------------------------<br /> <br /> =====Application context mismatch=====<br /> <br /> <br /> SSF SCP<br /> --------------------- IDP(serviceKey,oTermAttemptAuth) -------------------------------><br /> <-------------------- U_Abort (user-application-context-name-not-supported) -----------<br /> <br /> =====Receiving an unsupported CAMEL phase=====<br /> <br /> 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:<br /> <br /> SSF SCP<br /> 1. --------------------- IDP(serviceKey,oTermAttemptAuth) -------------------------------><br /> <-------------------- Continue --------------------------------------------------------<br /> <br /> SSF SCP<br /> 6. --------------------- ICA Result -----------------------------------------------------><br /> <-------------------- ReleaseCall -----------------------------------------------------<br /> <br /> <br /> =====1.2.5 Errors received from SSF / Timeout detected for class 1 and 3 operations=====<br /> <br /> 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.<br /> <br /> SSF SCP<br /> SCP can be in either of the states : 1 / 2 / 3 <br /> <-------------------- Continue --------------------------------------------------------<br /> <br /> <br /> SSF SCP<br /> SCP can be in either of the states : 4 / 5 / 13/ 14 <br /> <-------------------- ReleaseCall --------------------------------------------------------<br /> <br /> <br /> SSF SCP<br /> SCP can be in either of the states : 6 - 11 <br /> 14. <-------------------- MoveLeg --------------------------------------------------------<br /> <br /> <br /> ===Behaviour CAMEL phase 2/3===<br /> <br /> ====Normal procedure for dialogue====<br /> <br /> <br /> The following diagrams will detail the operation of the CRBT script in case of normal, error free phase 2/3 handling.<br /> <br /> <br /> SSF SCP<br /> 1. -------------------------- IDP (serviceKey, termAttemptAuth) ---------------------------><br /> 2. <------ RRBE (leg1,tAbandon) & (leg2,tBusy,tAnswer,tNoAnswer)----------------------------<br /> 3. <------------------------- ETC ----------------------------------------------------------<br /> 4. <------------------------- CONT ---------------------------------------------------------<br /> 5. -------------------------- ERBE (leg2,tAnswer) ------------------------------------------<br /> 6. <------------------------- DFC ----------------------------------------------------------<br /> 7. <------------------------- CONT ---------------------------------------------------------<br /> <br /> ====Abnormal procedures====<br /> <br /> <br /> Situations described in sections 1.2.1 - 1.2.4 shall also apply here.<br /> <br /> ====Errors received from SSF====<br /> <br /> <br /> SSF SCP<br /> SCP can be in either of the states : 2 / 3 <br /> <-------------------- Continue --------------------------------------------------------</div>

Monica https://ss7api.null.ro/index.php/CRBT_logic CRBT logic 2013-10-28T11:12:11Z

<p>Monica: </p> <hr /> <div>The crbt_scp.php is an implementation for a CAMEL gsmSCP application which provides a Colourful Ring Back Tone service by interfacing with a CAMEL gsmSSF.<br /> <br /> Upon service invocation, this script implements the required actions in order to instruct the gsmSSF to provide the required ringback tone.<br /> <br /> ==Configuration==<br /> <br /> ===Script side===<br /> <br /> The CRBT script supports two ways of communicating with Yate:<br /> # One based on the XML protocol, communication being realized through a TCP socket.<br /> # The other one based done through Yate messages, using ''extmodule''.<br /> The way which the script will use is chosen according to configuration - in particular, through the ''$ioType'' setting.<br /> <br /> <br /> Configuration of this script is done through ''config.php''. This allows setting the following parameters:<br /> <br /> * 1. '''$appName'''- value of the ''application'' parameters set in the ''camel.message''. This value is used to check that the message is indeed intented for this script.<br /> <br /> * 2. '''$ioType''' - type of I/O to use to communicate with Yate. The script recognizes these two values:<br /> ** ''TCP'' - use the configured TCP socket to communicate with Yate.<br /> ** ''MSG'' - use messages through exmodule protocol for communication.<br /> <br /> * 3. '''$host''','''$port''' - host and port where the application should connect to in order to communicate with Yate if ''$ioType'' is set to ''TCP''.<br /> <br /> * 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.<br /> <br /> * 5. '''$findMelodyID''' - boolean. It specifies whether the gsmSCF should take the necessary steps in order to find out the required ringtone for the called user. Its default value is false, meaning that the gsmSCF will assume that all requests reaching it are requests for subscribers which have the service activated<br /> <br /> * 6. '''$httpRequest''' - string. It's the HTTP request to be made in order to find out the ringtone associated with the user.<br /> <br /> * 7. '''$myServiceKey''' - integer. The ID of the service provided by this gsmSCF application and which should come in IDP in order to accept the request.<br /> <br /> * 8. '''$myDP''' - string. The DP for which this SCP should be triggered and which should come in IDP in order to accept the request.<br /> <br /> * 9. '''$sendAll''' - bool. If true, it will send all response components batched in a single TCAP message, otherwise it will send them each with its own TCAP message. It is set by default to true.<br /> <br /> * 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:<br /> ** ''prefix_called'' - build the gsmSRF address following this rule <tt>$srfNumber.$srfSeparator.$correlationID.$srfSeparator.$sfcID</tt>.<br /> ** ''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.<br /> <br /> When instructing the SSF to establish a temporary connection to a SRF through an ETC operation, the SCF must provide addressing information to the SSF in regards to the SRF. This information requires:<br /> * the address of the SRF - a routable number<br /> * a correlation ID - that can mean whatever the operators want, but that, according to specification, can be used by the SRF if/when contacting the SCF in order to associate the SSF -> SCF dialogue with the SRF ->SCF dialogue.<br /> * a scfID - an ID for the contacting SCF. This could be used by the SRF to know where to contact the SCF.<br /> <br /> The script provides this information in an ETC operation in 2 ways:<br /> * providing all the above information in the assistingSSPIPAddress. This is done by concatenating the SRF number, correlation ID and scfID -according to an agreement between the SSF and SCF operators. The script simply concatenates these parameters, putting between them the configured separator.<br /> * providing the information in 3 separated parameters:<br /> ** assistingSSPIPAddress - the SRF Number<br /> ** correlationID - the script will set this parameter to either the melody ID or the called party number, encoded in hexified BCD form.<br /> ** scfID - the script will set this parameter to the hexified BCD form of the SCP's GT number.<br /> <br /> Listed bellow are the parameters that need to be configured for the gsmSRF number:<br /> <br /> * '''$srfNumber''' - string. It specifies a number at which the gsmSRF is found.<br /> <br /> * '''$srfSeparator''' - string. Digit(s) used as separator between SRF number, correlationID and sfcID when the assistingSSPIPAddress contains all of them.<br /> <br /> * '''$srfNumber_qualifier''' - string. It specifies the GenericNumber qualifier. It can be one of the following values:<br /> ** ''dialed-digits''<br /> ** ''called-additional''<br /> ** ''caller-failed''<br /> ** ''caller-not-screened''<br /> ** ''terminating''<br /> ** ''connected-additional''<br /> ** ''caller-additional''<br /> ** ''called-original''<br /> ** ''redirecting''<br /> ** ''redirection''<br /> <br /> * '''$srfNumber_complete''' - boolean. It specifies whether the called number is complete or not. It should be complete.<br /> <br /> * '''$srfNumber_nature''' - string. Nature of number. It can have one of the following values:<br /> ** ''unknown''<br /> ** ''international''<br /> ** ''national''<br /> ** ''network-specific''<br /> ** ''subscriber''<br /> ** ''reserved''<br /> ** ''abbreviated''<br /> ** ''extension-reserved''<br /> <br /> * '''$srfNumber_plan''' - string. It's the used numbering plan. It can have one of the following values:<br /> ** ''unknown''<br /> ** ''isdn''<br /> ** ''data''<br /> ** ''telex''<br /> ** ''land-mobile''<br /> ** ''isdn-mobile''<br /> ** ''national''<br /> ** ''private''<br /> ** ''extension-reserved''<br /> <br /> * '''$srfNumber_restrict''' - string. It specifies the presentation of the number. Possible values are:<br /> ** ''allowed''<br /> ** ''restricted''<br /> ** ''unavailable''<br /> ** ''no''<br /> ** ''false''<br /> ** ''yes''<br /> ** ''true''<br /> <br /> * '''$srfNumber_screened''' - string. It specifies the screening indicator for the number. Possible values are:<br /> ** ''user-provided''<br /> ** ''user-provided-passed''<br /> ** ''user-provided-failed''<br /> ** ''network-provided''<br /> ** ''no''<br /> ** ''false''<br /> ** ''yes''<br /> ** ''true''<br /> <br /> * 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.<br /> <br /> * 12. '''$maxPhase''' - integer.Represents the maximum CAMEL phase allowed for CAMEL interaction. If not set, it will default to 4, meaning that all supported CAMEL phases are allowed.<br /> <br /> * 13. '''$msStateNotAllowed''' - array. List of states received for the subscriber in IDP for which the SCP will abandon CRBT handling and will continue with the call. Recognized values are:<br /> ** ''assumedIdle''<br /> ** ''camelBusy''<br /> ** ''netDetNotReachable''<br /> ** ''notProvidedFromVLR''<br /> It has no default, meaning that it will do CRBT handling ignoring the subscriber state.<br /> <br /> * 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.<br /> <br /> * 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.<br /> <br /> '''Note''' - The following parameters need not be set usually:<br /> * ''$host'', ''$port'' - set only if you intend to use TCP communication.<br /> * ''$transTimeout''<br /> * ''$sendAll''<br /> * ''$shortTimer'', ''$mediumTimer'', ''$longTimer''<br /> * ''$maxPhase''<br /> * ''$msStateNotAllowed''<br /> * ''$prearrangedEndOn'' - if there is no prearranged end agreement between operator, this doesn't need to be configured.<br /> <br /> * 16. '''$mynum''' - string. GTT number assigned to this SCP.<br /> <br /> ===Yate side===<br /> <br /> On the Yate side, the ''camel_map'' module must be configured through ''camel_map.conf''. <br /> <br /> For functionality provided through a TCP socket, a <tt>[tcap name]</tt> section should be configured. A section looks like this:<br /> <br /> [tcap camel] -- what comes after ''tcap'' will be the name of the translator<br /> ;enable=no -- enable this translator<br /> tcap=tcap-test-itu -- TCAP to be used by the translator for SS7 network communication, a section with that name should be configured in ''ysigchan.conf''<br /> host=0.0.0.0 -- address on which to listen for incoming applications<br /> port=16101 -- port on which to listen for incoming applications<br /> type=CAMEL -- type of translator (MAP/CAMEL). For the intended case, CAMEL should be set<br /> print-messages=true -- whether or not to print TCAP and XML messages in the logs<br /> add-encoding=false -- whether to add encoding attribute to data translated to XML<br /> <br /> <br /> For functionality through Yate messages, an additional section, named <tt>[local appName]</tt> should be configured:<br /> <br /> [local camelLocal] - what comes after ''local'' will be the name of the application<br /> ;enable=no -- enable this application<br /> translator=camel - which translator should be used. A section named [tcap translatorValue] should be present in the config file.<br /> capabilities=Camel - capabilities supported by this application. CAMEL translator have only one capability and that is ''Camel''.<br /> export_xml_as=both - how to export the XML part: string, object or both?<br /> <br /> '''Note:'''<br /> * setting port to 0 will disable the support for TCP applications<br /> * the name of the local application should match the name set in ''$appName'' for the script<br /> <br /> <br /> ==Script behaviour==<br /> <br /> This is a global script that awaits dialog beginnings from SSFs and it is able to handle CAMEL phases 2, 3 and 4.<br /> The phase used for handling the call will be determined using the information provided in the InitialDP operation using the following rules:<br /> * first, an application context check will be done. As seeing that every phase has a different context assigned, phase will be first determined at this stage.<br /> * if the application context determined a phase 4 handling, in the handling of the InitialDP operation these additional checks will be made:<br /> ** the value for ''supportedCamelPhases'' will be checked. In this parameter, the MSC advertises the CAMEL phases that it can handle. From that list, the SCP will choose the highest phase advertised.<br /> ** the value for ''offeredCamel4Functionalities'' will be checked. SCP will verify that all the CAMEL 4 functionalities required for doing CRBT handling in phase 4 are supported. If that is not so, the SCP will downgrade the phase to phase 2 as seeing that the presence of this parameter implied phase 4 functionality and phase 4 functionality implies, by convention, prior phases support also.<br /> <br /> In case of phase 1 detection, the SCP will end the dialogue either with an Abort with application-context-not-supported, either with a Continue operation for CAMEL.<br /> <br /> An configuration parameter was added (''$maxPhase'') - mainly for testing purposes - in order to limit what phase the SCP will accept.<br /> <br /> <br /> Bellow there is detailed description of how the script will act in different scenarios.<br /> <br /> ===Behaviour CAMEL phase 4===<br /> <br /> <br /> ====Normal procedure for dialogue====<br /> <br /> In case of a normal, error free dialogue, things will proceed according to the describing flow below:<br /> <br /> SSF SCP<br /> 1. --------------------- IDP(serviceKey,termAttemptAuth) --------------------------------><br /> 2. <-------------------- RRBE (tAbandon,leg1) --------------------------------------------<br /> 3. <-------------------- DL (leg2) -------------------------------------------------------<br /> 4. --------------------- DL Result ------------------------------------------------------><br /> 5. <-------------------- ICA (CS2,leg3) --------------------------------------------------<br /> 6. --------------------- ICA Result -----------------------------------------------------><br /> 7. <-------------------- RRBE (oTermSeized,oBusy,oAnswer,oNoAnswer,routeFailure,leg3) ----<br /> 8. <-------------------- CWA (leg3)-------------------------------------------------------<br /> 9. --------------------- ERBE (oTermSeized,leg3) ----------------------------------------><br /> 10. <-------------------- CWA (leg3) ------------------------------------------------------<br /> 11. <-------------------- ETC (CS1) -------------------------------------------------------<br /> 12. --------------------- ERBE (oAnswer,leg3) --------------------------------------------><br /> 13. <-------------------- DFCWA (CS1) -----------------------------------------------------<br /> 14. <-------------------- ML (leg3) -------------------------------------------------------<br /> 15. --------------------- ML Result ------------------------------------------------------><br /> 16. <-------------------- CWA (leg3) ------------------------------------------------------<br /> 17. <-------------------- CWA (CS1) -------------------------------------------------------<br /> <br /> In case of busy received from the called party, the call flow is:<br /> <br /> 1. --------------- ERBE (oCalledPartyBusy, leg3, cause) ----------------------><br /> 2. <-------------- RC (cause received in ERBE/Busy) --------------------------<br /> <br /> ====Abnormal procedures====<br /> <br /> The following schematics will describe the behaviour of the script in certain scenarios. <br /> 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.<br /> <br /> =====Initial DP ServiceKey mismatch / DP mismatch=====<br /> <br /> <br /> SSF SCP<br /> --------------------- IDP(serviceKey,oTermAttemptAuth) -------------------------------><br /> <-------------------- ReturnError(unexpectedDataValue) --------------------------------<br /> <br /> =====Initial DP missing parameters=====<br /> <br /> <br /> SSF SCP<br /> --------------------- IDP(serviceKey,oTermAttemptAuth) -------------------------------><br /> <-------------------- ReturnError(missingParameter) -----------------------------------<br /> <br /> =====1.2.3 Application context mismatch=====<br /> <br /> <br /> SSF SCP<br /> --------------------- IDP(serviceKey,oTermAttemptAuth) -------------------------------><br /> <-------------------- U_Abort (user-application-context-name-not-supported) -----------<br /> <br /> =====Receiving an unsupported CAMEL phase=====<br /> <br /> 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:<br /> <br /> SSF SCP<br /> 1. --------------------- IDP(serviceKey,oTermAttemptAuth) -------------------------------><br /> <-------------------- Continue --------------------------------------------------------<br /> <br /> SSF SCP<br /> 6. --------------------- ICA Result -----------------------------------------------------><br /> <-------------------- ReleaseCall -----------------------------------------------------<br /> <br /> <br /> =====1.2.5 Errors received from SSF / Timeout detected for class 1 and 3 operations=====<br /> <br /> 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.<br /> <br /> SSF SCP<br /> SCP can be in either of the states : 1 / 2 / 3 <br /> <-------------------- Continue --------------------------------------------------------<br /> <br /> <br /> SSF SCP<br /> SCP can be in either of the states : 4 / 5 / 13/ 14 <br /> <-------------------- ReleaseCall --------------------------------------------------------<br /> <br /> <br /> SSF SCP<br /> SCP can be in either of the states : 6 - 11 <br /> 14. <-------------------- MoveLeg --------------------------------------------------------<br /> <br /> <br /> ===Behaviour CAMEL phase 2/3===<br /> <br /> ====Normal procedure for dialogue====<br /> <br /> <br /> The following diagrams will detail the operation of the CRBT script in case of normal, error free phase 2/3 handling.<br /> <br /> <br /> SSF SCP<br /> 1. -------------------------- IDP (serviceKey, termAttemptAuth) ---------------------------><br /> 2. <------ RRBE (leg1,tAbandon) & (leg2,tBusy,tAnswer,tNoAnswer)----------------------------<br /> 3. <------------------------- ETC ----------------------------------------------------------<br /> 4. <------------------------- CONT ---------------------------------------------------------<br /> 5. -------------------------- ERBE (leg2,tAnswer) ------------------------------------------<br /> 6. <------------------------- DFC ----------------------------------------------------------<br /> 7. <------------------------- CONT ---------------------------------------------------------<br /> <br /> ====Abnormal procedures====<br /> <br /> <br /> Situations described in sections 1.2.1 - 1.2.4 shall also apply here.<br /> <br /> ====Errors received from SSF====<br /> <br /> <br /> SSF SCP<br /> SCP can be in either of the states : 2 / 3 <br /> <-------------------- Continue --------------------------------------------------------</div>

Monica https://ss7api.null.ro/index.php/CRBT_logic CRBT logic 2013-10-28T11:11:41Z

<p>Monica: /* Behaviour */</p> <hr /> <div>The crbt_scp.php is an implementation for a CAMEL gsmSCP application which provides a Colourful Ring Back Tone service by interfacing with a CAMEL gsmSSF.<br /> <br /> Upon service invocation, this script implements the required actions in order to instruct the gsmSSF to provide the required ringback tone.<br /> <br /> ==Configuration==<br /> <br /> ===Script side===<br /> <br /> The CRBT script supports two ways of communicating with Yate:<br /> # One based on the XML protocol, communication being realized through a TCP socket.<br /> # The other one based done through Yate messages, using ''extmodule''.<br /> The way which the script will use is chosen according to configuration - in particular, through the ''$ioType'' setting.<br /> <br /> <br /> Configuration of this script is done through ''config.php''. This allows setting the following parameters:<br /> <br /> * 1. '''$appName'''- value of the ''application'' parameters set in the ''camel.message''. This value is used to check that the message is indeed intented for this script.<br /> <br /> * 2. '''$ioType''' - type of I/O to use to communicate with Yate. The script recognizes these two values:<br /> ** ''TCP'' - use the configured TCP socket to communicate with Yate.<br /> ** ''MSG'' - use messages through exmodule protocol for communication.<br /> <br /> * 3. '''$host''','''$port''' - host and port where the application should connect to in order to communicate with Yate if ''$ioType'' is set to ''TCP''.<br /> <br /> * 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.<br /> <br /> * 5. '''$findMelodyID''' - boolean. It specifies whether the gsmSCF should take the necessary steps in order to find out the required ringtone for the called user. Its default value is false, meaning that the gsmSCF will assume that all requests reaching it are requests for subscribers which have the service activated<br /> <br /> * 6. '''$httpRequest''' - string. It's the HTTP request to be made in order to find out the ringtone associated with the user.<br /> <br /> * 7. '''$myServiceKey''' - integer. The ID of the service provided by this gsmSCF application and which should come in IDP in order to accept the request.<br /> <br /> * 8. '''$myDP''' - string. The DP for which this SCP should be triggered and which should come in IDP in order to accept the request.<br /> <br /> * 9. '''$sendAll''' - bool. If true, it will send all response components batched in a single TCAP message, otherwise it will send them each with its own TCAP message. It is set by default to true.<br /> <br /> * 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:<br /> ** ''prefix_called'' - build the gsmSRF address following this rule <tt>$srfNumber.$srfSeparator.$correlationID.$srfSeparator.$sfcID</tt>.<br /> ** ''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.<br /> <br /> When instructing the SSF to establish a temporary connection to a SRF through an ETC operation, the SCF must provide addressing information to the SSF in regards to the SRF. This information requires:<br /> * the address of the SRF - a routable number<br /> * a correlation ID - that can mean whatever the operators want, but that, according to specification, can be used by the SRF if/when contacting the SCF in order to associate the SSF -> SCF dialogue with the SRF ->SCF dialogue.<br /> * a scfID - an ID for the contacting SCF. This could be used by the SRF to know where to contact the SCF.<br /> <br /> The script provides this information in an ETC operation in 2 ways:<br /> * providing all the above information in the assistingSSPIPAddress. This is done by concatenating the SRF number, correlation ID and scfID -according to an agreement between the SSF and SCF operators. The script simply concatenates these parameters, putting between them the configured separator.<br /> * providing the information in 3 separated parameters:<br /> ** assistingSSPIPAddress - the SRF Number<br /> ** correlationID - the script will set this parameter to either the melody ID or the called party number, encoded in hexified BCD form.<br /> ** scfID - the script will set this parameter to the hexified BCD form of the SCP's GT number.<br /> <br /> Listed bellow are the parameters that need to be configured for the gsmSRF number:<br /> <br /> * '''$srfNumber''' - string. It specifies a number at which the gsmSRF is found.<br /> <br /> * '''$srfSeparator''' - string. Digit(s) used as separator between SRF number, correlationID and sfcID when the assistingSSPIPAddress contains all of them.<br /> <br /> * '''$srfNumber_qualifier''' - string. It specifies the GenericNumber qualifier. It can be one of the following values:<br /> ** ''dialed-digits''<br /> ** ''called-additional''<br /> ** ''caller-failed''<br /> ** ''caller-not-screened''<br /> ** ''terminating''<br /> ** ''connected-additional''<br /> ** ''caller-additional''<br /> ** ''called-original''<br /> ** ''redirecting''<br /> ** ''redirection''<br /> <br /> * '''$srfNumber_complete''' - boolean. It specifies whether the called number is complete or not. It should be complete.<br /> <br /> * '''$srfNumber_nature''' - string. Nature of number. It can have one of the following values:<br /> ** ''unknown''<br /> ** ''international''<br /> ** ''national''<br /> ** ''network-specific''<br /> ** ''subscriber''<br /> ** ''reserved''<br /> ** ''abbreviated''<br /> ** ''extension-reserved''<br /> <br /> * '''$srfNumber_plan''' - string. It's the used numbering plan. It can have one of the following values:<br /> ** ''unknown''<br /> ** ''isdn''<br /> ** ''data''<br /> ** ''telex''<br /> ** ''land-mobile''<br /> ** ''isdn-mobile''<br /> ** ''national''<br /> ** ''private''<br /> ** ''extension-reserved''<br /> <br /> * '''$srfNumber_restrict''' - string. It specifies the presentation of the number. Possible values are:<br /> ** ''allowed''<br /> ** ''restricted''<br /> ** ''unavailable''<br /> ** ''no''<br /> ** ''false''<br /> ** ''yes''<br /> ** ''true''<br /> <br /> * '''$srfNumber_screened''' - string. It specifies the screening indicator for the number. Possible values are:<br /> ** ''user-provided''<br /> ** ''user-provided-passed''<br /> ** ''user-provided-failed''<br /> ** ''network-provided''<br /> ** ''no''<br /> ** ''false''<br /> ** ''yes''<br /> ** ''true''<br /> <br /> * 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.<br /> <br /> * 12. '''$maxPhase''' - integer.Represents the maximum CAMEL phase allowed for CAMEL interaction. If not set, it will default to 4, meaning that all supported CAMEL phases are allowed.<br /> <br /> * 13. '''$msStateNotAllowed''' - array. List of states received for the subscriber in IDP for which the SCP will abandon CRBT handling and will continue with the call. Recognized values are:<br /> ** ''assumedIdle''<br /> ** ''camelBusy''<br /> ** ''netDetNotReachable''<br /> ** ''notProvidedFromVLR''<br /> It has no default, meaning that it will do CRBT handling ignoring the subscriber state.<br /> <br /> * 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.<br /> <br /> * 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.<br /> <br /> '''Note''' - The following parameters need not be set usually:<br /> * ''$host'', ''$port'' - set only if you intend to use TCP communication.<br /> * ''$transTimeout''<br /> * ''$sendAll''<br /> * ''$shortTimer'', ''$mediumTimer'', ''$longTimer''<br /> * ''$maxPhase''<br /> * ''$msStateNotAllowed''<br /> * ''$prearrangedEndOn'' - if there is no prearranged end agreement between operator, this doesn't need to be configured.<br /> <br /> * 16. '''$mynum''' - string. GTT number assigned to this SCP.<br /> <br /> ===Yate side===<br /> <br /> On the Yate side, the ''camel_map'' module must be configured through ''camel_map.conf''. <br /> <br /> For functionality provided through a TCP socket, a <tt>[tcap name]</tt> section should be configured. A section looks like this:<br /> <br /> [tcap camel] -- what comes after ''tcap'' will be the name of the translator<br /> ;enable=no -- enable this translator<br /> tcap=tcap-test-itu -- TCAP to be used by the translator for SS7 network communication, a section with that name should be configured in ''ysigchan.conf''<br /> host=0.0.0.0 -- address on which to listen for incoming applications<br /> port=16101 -- port on which to listen for incoming applications<br /> type=CAMEL -- type of translator (MAP/CAMEL). For the intended case, CAMEL should be set<br /> print-messages=true -- whether or not to print TCAP and XML messages in the logs<br /> add-encoding=false -- whether to add encoding attribute to data translated to XML<br /> <br /> <br /> For functionality through Yate messages, an additional section, named <tt>[local appName]</tt> should be configured:<br /> <br /> [local camelLocal] - what comes after ''local'' will be the name of the application<br /> ;enable=no -- enable this application<br /> translator=camel - which translator should be used. A section named [tcap translatorValue] should be present in the config file.<br /> capabilities=Camel - capabilities supported by this application. CAMEL translator have only one capability and that is ''Camel''.<br /> export_xml_as=both - how to export the XML part: string, object or both?<br /> <br /> '''Note:'''<br /> * setting port to 0 will disable the support for TCP applications<br /> * the name of the local application should match the name set in ''$appName'' for the script<br /> <br /> <br /> ==Script behaviour==<br /> <br /> This is a global script that awaits dialog beginnings from SSFs and it is able to handle CAMEL phases 2, 3 and 4.<br /> The phase used for handling the call will be determined using the information provided in the InitialDP operation using the following rules:<br /> * first, an application context check will be done. As seeing that every phase has a different context assigned, phase will be first determined at this stage.<br /> * if the application context determined a phase 4 handling, in the handling of the InitialDP operation these additional checks will be made:<br /> ** the value for ''supportedCamelPhases'' will be checked. In this parameter, the MSC advertises the CAMEL phases that it can handle. From that list, the SCP will choose the highest phase advertised.<br /> ** the value for ''offeredCamel4Functionalities'' will be checked. SCP will verify that all the CAMEL 4 functionalities required for doing CRBT handling in phase 4 are supported. If that is not so, the SCP will downgrade the phase to phase 2 as seeing that the presence of this parameter implied phase 4 functionality and phase 4 functionality implies, by convention, prior phases support also.<br /> <br /> In case of phase 1 detection, the SCP will end the dialogue either with an Abort with application-context-not-supported, either with a Continue operation for CAMEL.<br /> <br /> An configuration parameter was added (''$maxPhase'') - mainly for testing purposes - in order to limit what phase the SCP will accept.<br /> <br /> <br /> Bellow there is detailed description of how the script will act in different scenarios.<br /> <br /> ===Behaviour CAMEL phase 4===<br /> <br /> <br /> ====Normal procedure for dialogue====<br /> <br /> In case of a normal, error free dialogue, things will proceed according to the describing flow below:<br /> <br /> SSF SCP<br /> 1. --------------------- IDP(serviceKey,termAttemptAuth) --------------------------------><br /> 2. <-------------------- RRBE (tAbandon,leg1) --------------------------------------------<br /> 3. <-------------------- DL (leg2) -------------------------------------------------------<br /> 4. --------------------- DL Result ------------------------------------------------------><br /> 5. <-------------------- ICA (CS2,leg3) --------------------------------------------------<br /> 6. --------------------- ICA Result -----------------------------------------------------><br /> 7. <-------------------- RRBE (oTermSeized,oBusy,oAnswer,oNoAnswer,routeFailure,leg3) ----<br /> 8. <-------------------- CWA (leg3)-------------------------------------------------------<br /> 9. --------------------- ERBE (oTermSeized,leg3) ----------------------------------------><br /> 10. <-------------------- CWA (leg3) ------------------------------------------------------<br /> 11. <-------------------- ETC (CS1) -------------------------------------------------------<br /> 12. --------------------- ERBE (oAnswer,leg3) --------------------------------------------><br /> 13. <-------------------- DFCWA (CS1) -----------------------------------------------------<br /> 14. <-------------------- ML (leg3) -------------------------------------------------------<br /> 15. --------------------- ML Result ------------------------------------------------------><br /> 16. <-------------------- CWA (leg3) ------------------------------------------------------<br /> 17. <-------------------- CWA (CS1) -------------------------------------------------------<br /> <br /> In case of busy received from the called party, the call flow is:<br /> <br /> 1. --------------- ERBE (oCalledPartyBusy, leg3, cause) ----------------------><br /> 2. <-------------- RC (cause received in ERBE/Busy) --------------------------<br /> <br /> ====Abnormal procedures====<br /> <br /> The following schematics will describe the behaviour of the script in certain scenarios. <br /> 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.<br /> <br /> =====Initial DP ServiceKey mismatch / DP mismatch=====<br /> <br /> <br /> SSF SCP<br /> --------------------- IDP(serviceKey,oTermAttemptAuth) -------------------------------><br /> <-------------------- ReturnError(unexpectedDataValue) --------------------------------<br /> <br /> =====Initial DP missing parameters=====<br /> <br /> <br /> SSF SCP<br /> --------------------- IDP(serviceKey,oTermAttemptAuth) -------------------------------><br /> <-------------------- ReturnError(missingParameter) -----------------------------------<br /> <br /> =====1.2.3 Application context mismatch=====<br /> <br /> <br /> SSF SCP<br /> --------------------- IDP(serviceKey,oTermAttemptAuth) -------------------------------><br /> <-------------------- U_Abort (user-application-context-name-not-supported) -----------<br /> <br /> =====Receiving an unsupported CAMEL phase=====<br /> <br /> 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:<br /> <br /> SSF SCP<br /> 1. --------------------- IDP(serviceKey,oTermAttemptAuth) -------------------------------><br /> <-------------------- Continue --------------------------------------------------------<br /> <br /> SSF SCP<br /> 6. --------------------- ICA Result -----------------------------------------------------><br /> <-------------------- ReleaseCall -----------------------------------------------------<br /> <br /> <br /> =====1.2.5 Errors received from SSF / Timeout detected for class 1 and 3 operations=====<br /> <br /> 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.<br /> <br /> SSF SCP<br /> SCP can be in either of the states : 1 / 2 / 3 <br /> <-------------------- Continue --------------------------------------------------------<br /> <br /> <br /> SSF SCP<br /> SCP can be in either of the states : 4 / 5 / 13/ 14 <br /> <-------------------- ReleaseCall --------------------------------------------------------<br /> <br /> <br /> SSF SCP<br /> SCP can be in either of the states : 6 - 11 <br /> 14. <-------------------- MoveLeg --------------------------------------------------------<br /> <br /> <br /> ==Behaviour CAMEL phase 2/3==<br /> <br /> ===Normal procedure for dialogue===<br /> <br /> <br /> The following diagrams will detail the operation of the CRBT script in case of normal, error free phase 2/3 handling.<br /> <br /> <br /> SSF SCP<br /> 1. -------------------------- IDP (serviceKey, termAttemptAuth) ---------------------------><br /> 2. <------ RRBE (leg1,tAbandon) & (leg2,tBusy,tAnswer,tNoAnswer)----------------------------<br /> 3. <------------------------- ETC ----------------------------------------------------------<br /> 4. <------------------------- CONT ---------------------------------------------------------<br /> 5. -------------------------- ERBE (leg2,tAnswer) ------------------------------------------<br /> 6. <------------------------- DFC ----------------------------------------------------------<br /> 7. <------------------------- CONT ---------------------------------------------------------<br /> <br /> ===Abnormal procedures===<br /> <br /> <br /> Situations described in sections 1.2.1 - 1.2.4 shall also apply here.<br /> <br /> ===Errors received from SSF===<br /> <br /> <br /> SSF SCP<br /> SCP can be in either of the states : 2 / 3 <br /> <-------------------- Continue --------------------------------------------------------</div>

Monica https://ss7api.null.ro/index.php/CRBT_logic CRBT logic 2013-10-28T11:09:49Z

<p>Monica: /* Yate side */</p> <hr /> <div>The crbt_scp.php is an implementation for a CAMEL gsmSCP application which provides a Colourful Ring Back Tone service by interfacing with a CAMEL gsmSSF.<br /> <br /> Upon service invocation, this script implements the required actions in order to instruct the gsmSSF to provide the required ringback tone.<br /> <br /> ==Configuration==<br /> <br /> ===Script side===<br /> <br /> The CRBT script supports two ways of communicating with Yate:<br /> # One based on the XML protocol, communication being realized through a TCP socket.<br /> # The other one based done through Yate messages, using ''extmodule''.<br /> The way which the script will use is chosen according to configuration - in particular, through the ''$ioType'' setting.<br /> <br /> <br /> Configuration of this script is done through ''config.php''. This allows setting the following parameters:<br /> <br /> * 1. '''$appName'''- value of the ''application'' parameters set in the ''camel.message''. This value is used to check that the message is indeed intented for this script.<br /> <br /> * 2. '''$ioType''' - type of I/O to use to communicate with Yate. The script recognizes these two values:<br /> ** ''TCP'' - use the configured TCP socket to communicate with Yate.<br /> ** ''MSG'' - use messages through exmodule protocol for communication.<br /> <br /> * 3. '''$host''','''$port''' - host and port where the application should connect to in order to communicate with Yate if ''$ioType'' is set to ''TCP''.<br /> <br /> * 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.<br /> <br /> * 5. '''$findMelodyID''' - boolean. It specifies whether the gsmSCF should take the necessary steps in order to find out the required ringtone for the called user. Its default value is false, meaning that the gsmSCF will assume that all requests reaching it are requests for subscribers which have the service activated<br /> <br /> * 6. '''$httpRequest''' - string. It's the HTTP request to be made in order to find out the ringtone associated with the user.<br /> <br /> * 7. '''$myServiceKey''' - integer. The ID of the service provided by this gsmSCF application and which should come in IDP in order to accept the request.<br /> <br /> * 8. '''$myDP''' - string. The DP for which this SCP should be triggered and which should come in IDP in order to accept the request.<br /> <br /> * 9. '''$sendAll''' - bool. If true, it will send all response components batched in a single TCAP message, otherwise it will send them each with its own TCAP message. It is set by default to true.<br /> <br /> * 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:<br /> ** ''prefix_called'' - build the gsmSRF address following this rule <tt>$srfNumber.$srfSeparator.$correlationID.$srfSeparator.$sfcID</tt>.<br /> ** ''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.<br /> <br /> When instructing the SSF to establish a temporary connection to a SRF through an ETC operation, the SCF must provide addressing information to the SSF in regards to the SRF. This information requires:<br /> * the address of the SRF - a routable number<br /> * a correlation ID - that can mean whatever the operators want, but that, according to specification, can be used by the SRF if/when contacting the SCF in order to associate the SSF -> SCF dialogue with the SRF ->SCF dialogue.<br /> * a scfID - an ID for the contacting SCF. This could be used by the SRF to know where to contact the SCF.<br /> <br /> The script provides this information in an ETC operation in 2 ways:<br /> * providing all the above information in the assistingSSPIPAddress. This is done by concatenating the SRF number, correlation ID and scfID -according to an agreement between the SSF and SCF operators. The script simply concatenates these parameters, putting between them the configured separator.<br /> * providing the information in 3 separated parameters:<br /> ** assistingSSPIPAddress - the SRF Number<br /> ** correlationID - the script will set this parameter to either the melody ID or the called party number, encoded in hexified BCD form.<br /> ** scfID - the script will set this parameter to the hexified BCD form of the SCP's GT number.<br /> <br /> Listed bellow are the parameters that need to be configured for the gsmSRF number:<br /> <br /> * '''$srfNumber''' - string. It specifies a number at which the gsmSRF is found.<br /> <br /> * '''$srfSeparator''' - string. Digit(s) used as separator between SRF number, correlationID and sfcID when the assistingSSPIPAddress contains all of them.<br /> <br /> * '''$srfNumber_qualifier''' - string. It specifies the GenericNumber qualifier. It can be one of the following values:<br /> ** ''dialed-digits''<br /> ** ''called-additional''<br /> ** ''caller-failed''<br /> ** ''caller-not-screened''<br /> ** ''terminating''<br /> ** ''connected-additional''<br /> ** ''caller-additional''<br /> ** ''called-original''<br /> ** ''redirecting''<br /> ** ''redirection''<br /> <br /> * '''$srfNumber_complete''' - boolean. It specifies whether the called number is complete or not. It should be complete.<br /> <br /> * '''$srfNumber_nature''' - string. Nature of number. It can have one of the following values:<br /> ** ''unknown''<br /> ** ''international''<br /> ** ''national''<br /> ** ''network-specific''<br /> ** ''subscriber''<br /> ** ''reserved''<br /> ** ''abbreviated''<br /> ** ''extension-reserved''<br /> <br /> * '''$srfNumber_plan''' - string. It's the used numbering plan. It can have one of the following values:<br /> ** ''unknown''<br /> ** ''isdn''<br /> ** ''data''<br /> ** ''telex''<br /> ** ''land-mobile''<br /> ** ''isdn-mobile''<br /> ** ''national''<br /> ** ''private''<br /> ** ''extension-reserved''<br /> <br /> * '''$srfNumber_restrict''' - string. It specifies the presentation of the number. Possible values are:<br /> ** ''allowed''<br /> ** ''restricted''<br /> ** ''unavailable''<br /> ** ''no''<br /> ** ''false''<br /> ** ''yes''<br /> ** ''true''<br /> <br /> * '''$srfNumber_screened''' - string. It specifies the screening indicator for the number. Possible values are:<br /> ** ''user-provided''<br /> ** ''user-provided-passed''<br /> ** ''user-provided-failed''<br /> ** ''network-provided''<br /> ** ''no''<br /> ** ''false''<br /> ** ''yes''<br /> ** ''true''<br /> <br /> * 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.<br /> <br /> * 12. '''$maxPhase''' - integer.Represents the maximum CAMEL phase allowed for CAMEL interaction. If not set, it will default to 4, meaning that all supported CAMEL phases are allowed.<br /> <br /> * 13. '''$msStateNotAllowed''' - array. List of states received for the subscriber in IDP for which the SCP will abandon CRBT handling and will continue with the call. Recognized values are:<br /> ** ''assumedIdle''<br /> ** ''camelBusy''<br /> ** ''netDetNotReachable''<br /> ** ''notProvidedFromVLR''<br /> It has no default, meaning that it will do CRBT handling ignoring the subscriber state.<br /> <br /> * 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.<br /> <br /> * 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.<br /> <br /> '''Note''' - The following parameters need not be set usually:<br /> * ''$host'', ''$port'' - set only if you intend to use TCP communication.<br /> * ''$transTimeout''<br /> * ''$sendAll''<br /> * ''$shortTimer'', ''$mediumTimer'', ''$longTimer''<br /> * ''$maxPhase''<br /> * ''$msStateNotAllowed''<br /> * ''$prearrangedEndOn'' - if there is no prearranged end agreement between operator, this doesn't need to be configured.<br /> <br /> * 16. '''$mynum''' - string. GTT number assigned to this SCP.<br /> <br /> ===Yate side===<br /> <br /> On the Yate side, the ''camel_map'' module must be configured through ''camel_map.conf''. <br /> <br /> For functionality provided through a TCP socket, a <tt>[tcap name]</tt> section should be configured. A section looks like this:<br /> <br /> [tcap camel] -- what comes after ''tcap'' will be the name of the translator<br /> ;enable=no -- enable this translator<br /> tcap=tcap-test-itu -- TCAP to be used by the translator for SS7 network communication, a section with that name should be configured in ''ysigchan.conf''<br /> host=0.0.0.0 -- address on which to listen for incoming applications<br /> port=16101 -- port on which to listen for incoming applications<br /> type=CAMEL -- type of translator (MAP/CAMEL). For the intended case, CAMEL should be set<br /> print-messages=true -- whether or not to print TCAP and XML messages in the logs<br /> add-encoding=false -- whether to add encoding attribute to data translated to XML<br /> <br /> <br /> For functionality through Yate messages, an additional section, named <tt>[local appName]</tt> should be configured:<br /> <br /> [local camelLocal] - what comes after ''local'' will be the name of the application<br /> ;enable=no -- enable this application<br /> translator=camel - which translator should be used. A section named [tcap translatorValue] should be present in the config file.<br /> capabilities=Camel - capabilities supported by this application. CAMEL translator have only one capability and that is ''Camel''.<br /> export_xml_as=both - how to export the XML part: string, object or both?<br /> <br /> '''Note:'''<br /> * setting port to 0 will disable the support for TCP applications<br /> * the name of the local application should match the name set in ''$appName'' for the script<br /> <br /> ==Behaviour==<br /> <br /> ===Script behaviour===<br /> <br /> This is a global script that awaits dialog beginnings from SSFs and it is able to handle CAMEL phases 2, 3 and 4.<br /> The phase used for handling the call will be determined using the information provided in the InitialDP operation using the following rules:<br /> * first, an application context check will be done. As seeing that every phase has a different context assigned, phase will be first determined at this stage.<br /> * if the application context determined a phase 4 handling, in the handling of the InitialDP operation these additional checks will be made:<br /> ** the value for ''supportedCamelPhases'' will be checked. In this parameter, the MSC advertises the CAMEL phases that it can handle. From that list, the SCP will choose the highest phase advertised.<br /> ** the value for ''offeredCamel4Functionalities'' will be checked. SCP will verify that all the CAMEL 4 functionalities required for doing CRBT handling in phase 4 are supported. If that is not so, the SCP will downgrade the phase to phase 2 as seeing that the presence of this parameter implied phase 4 functionality and phase 4 functionality implies, by convention, prior phases support also.<br /> <br /> In case of phase 1 detection, the SCP will end the dialogue either with an Abort with application-context-not-supported, either with a Continue operation for CAMEL.<br /> <br /> An configuration parameter was added (''$maxPhase'') - mainly for testing purposes - in order to limit what phase the SCP will accept.<br /> <br /> <br /> Bellow there is detailed description of how the script will act in different scenarios.<br /> <br /> ====Behaviour CAMEL phase 4====<br /> <br /> <br /> =====Normal procedure for dialogue=====<br /> <br /> In case of a normal, error free dialogue, things will proceed according to the describing flow below:<br /> <br /> SSF SCP<br /> 1. --------------------- IDP(serviceKey,termAttemptAuth) --------------------------------><br /> 2. <-------------------- RRBE (tAbandon,leg1) --------------------------------------------<br /> 3. <-------------------- DL (leg2) -------------------------------------------------------<br /> 4. --------------------- DL Result ------------------------------------------------------><br /> 5. <-------------------- ICA (CS2,leg3) --------------------------------------------------<br /> 6. --------------------- ICA Result -----------------------------------------------------><br /> 7. <-------------------- RRBE (oTermSeized,oBusy,oAnswer,oNoAnswer,routeFailure,leg3) ----<br /> 8. <-------------------- CWA (leg3)-------------------------------------------------------<br /> 9. --------------------- ERBE (oTermSeized,leg3) ----------------------------------------><br /> 10. <-------------------- CWA (leg3) ------------------------------------------------------<br /> 11. <-------------------- ETC (CS1) -------------------------------------------------------<br /> 12. --------------------- ERBE (oAnswer,leg3) --------------------------------------------><br /> 13. <-------------------- DFCWA (CS1) -----------------------------------------------------<br /> 14. <-------------------- ML (leg3) -------------------------------------------------------<br /> 15. --------------------- ML Result ------------------------------------------------------><br /> 16. <-------------------- CWA (leg3) ------------------------------------------------------<br /> 17. <-------------------- CWA (CS1) -------------------------------------------------------<br /> <br /> In case of busy received from the called party, the call flow is:<br /> <br /> 1. --------------- ERBE (oCalledPartyBusy, leg3, cause) ----------------------><br /> 2. <-------------- RC (cause received in ERBE/Busy) --------------------------<br /> <br /> =====Abnormal procedures=====<br /> <br /> The following schematics will describe the behaviour of the script in certain scenarios. <br /> 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.<br /> <br /> ======Initial DP ServiceKey mismatch / DP mismatch======<br /> <br /> <br /> SSF SCP<br /> --------------------- IDP(serviceKey,oTermAttemptAuth) -------------------------------><br /> <-------------------- ReturnError(unexpectedDataValue) --------------------------------<br /> <br /> ======Initial DP missing parameters======<br /> <br /> <br /> SSF SCP<br /> --------------------- IDP(serviceKey,oTermAttemptAuth) -------------------------------><br /> <-------------------- ReturnError(missingParameter) -----------------------------------<br /> <br /> ======1.2.3 Application context mismatch======<br /> <br /> <br /> SSF SCP<br /> --------------------- IDP(serviceKey,oTermAttemptAuth) -------------------------------><br /> <-------------------- U_Abort (user-application-context-name-not-supported) -----------<br /> <br /> ======Receiving an unsupported CAMEL phase======<br /> <br /> 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:<br /> <br /> SSF SCP<br /> 1. --------------------- IDP(serviceKey,oTermAttemptAuth) -------------------------------><br /> <-------------------- Continue --------------------------------------------------------<br /> <br /> SSF SCP<br /> 6. --------------------- ICA Result -----------------------------------------------------><br /> <-------------------- ReleaseCall -----------------------------------------------------<br /> <br /> <br /> ======1.2.5 Errors received from SSF / Timeout detected for class 1 and 3 operations======<br /> <br /> 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.<br /> <br /> SSF SCP<br /> SCP can be in either of the states : 1 / 2 / 3 <br /> <-------------------- Continue --------------------------------------------------------<br /> <br /> <br /> SSF SCP<br /> SCP can be in either of the states : 4 / 5 / 13/ 14 <br /> <-------------------- ReleaseCall --------------------------------------------------------<br /> <br /> <br /> SSF SCP<br /> SCP can be in either of the states : 6 - 11 <br /> 14. <-------------------- MoveLeg --------------------------------------------------------<br /> <br /> <br /> ===Behaviour CAMEL phase 2/3===<br /> <br /> ====Normal procedure for dialogue====<br /> <br /> <br /> The following diagrams will detail the operation of the CRBT script in case of normal, error free phase 2/3 handling.<br /> <br /> <br /> SSF SCP<br /> 1. -------------------------- IDP (serviceKey, termAttemptAuth) ---------------------------><br /> 2. <------ RRBE (leg1,tAbandon) & (leg2,tBusy,tAnswer,tNoAnswer)----------------------------<br /> 3. <------------------------- ETC ----------------------------------------------------------<br /> 4. <------------------------- CONT ---------------------------------------------------------<br /> 5. -------------------------- ERBE (leg2,tAnswer) ------------------------------------------<br /> 6. <------------------------- DFC ----------------------------------------------------------<br /> 7. <------------------------- CONT ---------------------------------------------------------<br /> <br /> ====Abnormal procedures====<br /> <br /> <br /> Situations described in sections 1.2.1 - 1.2.4 shall also apply here.<br /> <br /> ====Errors received from SSF====<br /> <br /> <br /> SSF SCP<br /> SCP can be in either of the states : 2 / 3 <br /> <-------------------- Continue --------------------------------------------------------</div>

Monica https://ss7api.null.ro/index.php/CRBT_logic CRBT logic 2013-10-28T11:06:53Z

<p>Monica: /* Script side */</p> <hr /> <div>The crbt_scp.php is an implementation for a CAMEL gsmSCP application which provides a Colourful Ring Back Tone service by interfacing with a CAMEL gsmSSF.<br /> <br /> Upon service invocation, this script implements the required actions in order to instruct the gsmSSF to provide the required ringback tone.<br /> <br /> ==Configuration==<br /> <br /> ===Script side===<br /> <br /> The CRBT script supports two ways of communicating with Yate:<br /> # One based on the XML protocol, communication being realized through a TCP socket.<br /> # The other one based done through Yate messages, using ''extmodule''.<br /> The way which the script will use is chosen according to configuration - in particular, through the ''$ioType'' setting.<br /> <br /> <br /> Configuration of this script is done through ''config.php''. This allows setting the following parameters:<br /> <br /> * 1. '''$appName'''- value of the ''application'' parameters set in the ''camel.message''. This value is used to check that the message is indeed intented for this script.<br /> <br /> * 2. '''$ioType''' - type of I/O to use to communicate with Yate. The script recognizes these two values:<br /> ** ''TCP'' - use the configured TCP socket to communicate with Yate.<br /> ** ''MSG'' - use messages through exmodule protocol for communication.<br /> <br /> * 3. '''$host''','''$port''' - host and port where the application should connect to in order to communicate with Yate if ''$ioType'' is set to ''TCP''.<br /> <br /> * 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.<br /> <br /> * 5. '''$findMelodyID''' - boolean. It specifies whether the gsmSCF should take the necessary steps in order to find out the required ringtone for the called user. Its default value is false, meaning that the gsmSCF will assume that all requests reaching it are requests for subscribers which have the service activated<br /> <br /> * 6. '''$httpRequest''' - string. It's the HTTP request to be made in order to find out the ringtone associated with the user.<br /> <br /> * 7. '''$myServiceKey''' - integer. The ID of the service provided by this gsmSCF application and which should come in IDP in order to accept the request.<br /> <br /> * 8. '''$myDP''' - string. The DP for which this SCP should be triggered and which should come in IDP in order to accept the request.<br /> <br /> * 9. '''$sendAll''' - bool. If true, it will send all response components batched in a single TCAP message, otherwise it will send them each with its own TCAP message. It is set by default to true.<br /> <br /> * 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:<br /> ** ''prefix_called'' - build the gsmSRF address following this rule <tt>$srfNumber.$srfSeparator.$correlationID.$srfSeparator.$sfcID</tt>.<br /> ** ''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.<br /> <br /> When instructing the SSF to establish a temporary connection to a SRF through an ETC operation, the SCF must provide addressing information to the SSF in regards to the SRF. This information requires:<br /> * the address of the SRF - a routable number<br /> * a correlation ID - that can mean whatever the operators want, but that, according to specification, can be used by the SRF if/when contacting the SCF in order to associate the SSF -> SCF dialogue with the SRF ->SCF dialogue.<br /> * a scfID - an ID for the contacting SCF. This could be used by the SRF to know where to contact the SCF.<br /> <br /> The script provides this information in an ETC operation in 2 ways:<br /> * providing all the above information in the assistingSSPIPAddress. This is done by concatenating the SRF number, correlation ID and scfID -according to an agreement between the SSF and SCF operators. The script simply concatenates these parameters, putting between them the configured separator.<br /> * providing the information in 3 separated parameters:<br /> ** assistingSSPIPAddress - the SRF Number<br /> ** correlationID - the script will set this parameter to either the melody ID or the called party number, encoded in hexified BCD form.<br /> ** scfID - the script will set this parameter to the hexified BCD form of the SCP's GT number.<br /> <br /> Listed bellow are the parameters that need to be configured for the gsmSRF number:<br /> <br /> * '''$srfNumber''' - string. It specifies a number at which the gsmSRF is found.<br /> <br /> * '''$srfSeparator''' - string. Digit(s) used as separator between SRF number, correlationID and sfcID when the assistingSSPIPAddress contains all of them.<br /> <br /> * '''$srfNumber_qualifier''' - string. It specifies the GenericNumber qualifier. It can be one of the following values:<br /> ** ''dialed-digits''<br /> ** ''called-additional''<br /> ** ''caller-failed''<br /> ** ''caller-not-screened''<br /> ** ''terminating''<br /> ** ''connected-additional''<br /> ** ''caller-additional''<br /> ** ''called-original''<br /> ** ''redirecting''<br /> ** ''redirection''<br /> <br /> * '''$srfNumber_complete''' - boolean. It specifies whether the called number is complete or not. It should be complete.<br /> <br /> * '''$srfNumber_nature''' - string. Nature of number. It can have one of the following values:<br /> ** ''unknown''<br /> ** ''international''<br /> ** ''national''<br /> ** ''network-specific''<br /> ** ''subscriber''<br /> ** ''reserved''<br /> ** ''abbreviated''<br /> ** ''extension-reserved''<br /> <br /> * '''$srfNumber_plan''' - string. It's the used numbering plan. It can have one of the following values:<br /> ** ''unknown''<br /> ** ''isdn''<br /> ** ''data''<br /> ** ''telex''<br /> ** ''land-mobile''<br /> ** ''isdn-mobile''<br /> ** ''national''<br /> ** ''private''<br /> ** ''extension-reserved''<br /> <br /> * '''$srfNumber_restrict''' - string. It specifies the presentation of the number. Possible values are:<br /> ** ''allowed''<br /> ** ''restricted''<br /> ** ''unavailable''<br /> ** ''no''<br /> ** ''false''<br /> ** ''yes''<br /> ** ''true''<br /> <br /> * '''$srfNumber_screened''' - string. It specifies the screening indicator for the number. Possible values are:<br /> ** ''user-provided''<br /> ** ''user-provided-passed''<br /> ** ''user-provided-failed''<br /> ** ''network-provided''<br /> ** ''no''<br /> ** ''false''<br /> ** ''yes''<br /> ** ''true''<br /> <br /> * 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.<br /> <br /> * 12. '''$maxPhase''' - integer.Represents the maximum CAMEL phase allowed for CAMEL interaction. If not set, it will default to 4, meaning that all supported CAMEL phases are allowed.<br /> <br /> * 13. '''$msStateNotAllowed''' - array. List of states received for the subscriber in IDP for which the SCP will abandon CRBT handling and will continue with the call. Recognized values are:<br /> ** ''assumedIdle''<br /> ** ''camelBusy''<br /> ** ''netDetNotReachable''<br /> ** ''notProvidedFromVLR''<br /> It has no default, meaning that it will do CRBT handling ignoring the subscriber state.<br /> <br /> * 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.<br /> <br /> * 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.<br /> <br /> '''Note''' - The following parameters need not be set usually:<br /> * ''$host'', ''$port'' - set only if you intend to use TCP communication.<br /> * ''$transTimeout''<br /> * ''$sendAll''<br /> * ''$shortTimer'', ''$mediumTimer'', ''$longTimer''<br /> * ''$maxPhase''<br /> * ''$msStateNotAllowed''<br /> * ''$prearrangedEndOn'' - if there is no prearranged end agreement between operator, this doesn't need to be configured.<br /> <br /> * 16. '''$mynum''' - string. GTT number assigned to this SCP.<br /> <br /> ===Yate side===<br /> <br /> On the Yate side, the ''camel_map'' module must be configured through ''camel_map.conf''. <br /> <br /> For functionality provided through a TCP socket, a <tt>[tcap name]</tt> section should be configured. A section looks like this:<br /> <br /> [tcap camel] -- what comes after ''tcap'' will be the name of the translator<br /> ;enable=no -- enable this translator<br /> tcap=tcap-test-itu -- TCAP to be used by the translator for SS7 network communication, a section with that name should be configured in ''ysigchan.conf''<br /> host=0.0.0.0 -- address on which to listen for incoming applications<br /> port=16101 -- port on which to listen for incoming applications<br /> type=CAMEL -- type of translator (MAP/CAMEL). For the intended case, CAMEL should be set<br /> print-messages=true -- whether or not to print TCAP and XML messages in the logs<br /> add-encoding=false -- whether to add encoding attribute to data translated to XML<br /> <br /> <br /> For functionality through Yate messages, an additional section, named <tt>[local appName]</tt> should be configured:<br /> <br /> [local camelLocal] - what comes after ''local'' will be the name of the application<br /> ;enable=no -- enable this application<br /> translator=camel - which translator should be used. A section named [tcap translatorValue] should be present in the config file.<br /> capabilities=Camel - capabilities supported by this application. CAMEL translator have only one capability and that is ''Camel''.<br /> export_xml_as=both - how to export the XML part: string, object or both?<br /> <br /> '''Note:'''<br /> * setting port to 0 will disable the support for TCP applications<br /> * the name of the local application should match the name set in ''$appName'' for the script<br /> <br /> ==Behaviour==<br /> <br /> ===Script behaviour===<br /> <br /> This is a global script that awaits dialog beginnings from SSFs and it is able to handle CAMEL phases 2, 3 and 4.<br /> The phase used for handling the call will be determined using the information provided in the InitialDP operation using the following rules:<br /> * first, an application context check will be done. As seeing that every phase has a different context assigned, phase will be first determined at this stage.<br /> * if the application context determined a phase 4 handling, in the handling of the InitialDP operation these additional checks will be made:<br /> ** the value for ''supportedCamelPhases'' will be checked. In this parameter, the MSC advertises the CAMEL phases that it can handle. From that list, the SCP will choose the highest phase advertised.<br /> ** the value for ''offeredCamel4Functionalities'' will be checked. SCP will verify that all the CAMEL 4 functionalities required for doing CRBT handling in phase 4 are supported. If that is not so, the SCP will downgrade the phase to phase 2 as seeing that the presence of this parameter implied phase 4 functionality and phase 4 functionality implies, by convention, prior phases support also.<br /> <br /> In case of phase 1 detection, the SCP will end the dialogue either with an Abort with application-context-not-supported, either with a Continue operation for CAMEL.<br /> <br /> An configuration parameter was added (''$maxPhase'') - mainly for testing purposes - in order to limit what phase the SCP will accept.<br /> <br /> <br /> Bellow there is detailed description of how the script will act in different scenarios.<br /> <br /> ====Behaviour CAMEL phase 4====<br /> <br /> <br /> =====Normal procedure for dialogue=====<br /> <br /> In case of a normal, error free dialogue, things will proceed according to the describing flow below:<br /> <br /> SSF SCP<br /> 1. --------------------- IDP(serviceKey,termAttemptAuth) --------------------------------><br /> 2. <-------------------- RRBE (tAbandon,leg1) --------------------------------------------<br /> 3. <-------------------- DL (leg2) -------------------------------------------------------<br /> 4. --------------------- DL Result ------------------------------------------------------><br /> 5. <-------------------- ICA (CS2,leg3) --------------------------------------------------<br /> 6. --------------------- ICA Result -----------------------------------------------------><br /> 7. <-------------------- RRBE (oTermSeized,oBusy,oAnswer,oNoAnswer,routeFailure,leg3) ----<br /> 8. <-------------------- CWA (leg3)-------------------------------------------------------<br /> 9. --------------------- ERBE (oTermSeized,leg3) ----------------------------------------><br /> 10. <-------------------- CWA (leg3) ------------------------------------------------------<br /> 11. <-------------------- ETC (CS1) -------------------------------------------------------<br /> 12. --------------------- ERBE (oAnswer,leg3) --------------------------------------------><br /> 13. <-------------------- DFCWA (CS1) -----------------------------------------------------<br /> 14. <-------------------- ML (leg3) -------------------------------------------------------<br /> 15. --------------------- ML Result ------------------------------------------------------><br /> 16. <-------------------- CWA (leg3) ------------------------------------------------------<br /> 17. <-------------------- CWA (CS1) -------------------------------------------------------<br /> <br /> In case of busy received from the called party, the call flow is:<br /> <br /> 1. --------------- ERBE (oCalledPartyBusy, leg3, cause) ----------------------><br /> 2. <-------------- RC (cause received in ERBE/Busy) --------------------------<br /> <br /> =====Abnormal procedures=====<br /> <br /> The following schematics will describe the behaviour of the script in certain scenarios. <br /> 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.<br /> <br /> ======Initial DP ServiceKey mismatch / DP mismatch======<br /> <br /> <br /> SSF SCP<br /> --------------------- IDP(serviceKey,oTermAttemptAuth) -------------------------------><br /> <-------------------- ReturnError(unexpectedDataValue) --------------------------------<br /> <br /> ======Initial DP missing parameters======<br /> <br /> <br /> SSF SCP<br /> --------------------- IDP(serviceKey,oTermAttemptAuth) -------------------------------><br /> <-------------------- ReturnError(missingParameter) -----------------------------------<br /> <br /> ======1.2.3 Application context mismatch======<br /> <br /> <br /> SSF SCP<br /> --------------------- IDP(serviceKey,oTermAttemptAuth) -------------------------------><br /> <-------------------- U_Abort (user-application-context-name-not-supported) -----------<br /> <br /> ======Receiving an unsupported CAMEL phase======<br /> <br /> 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:<br /> <br /> SSF SCP<br /> 1. --------------------- IDP(serviceKey,oTermAttemptAuth) -------------------------------><br /> <-------------------- Continue --------------------------------------------------------<br /> <br /> SSF SCP<br /> 6. --------------------- ICA Result -----------------------------------------------------><br /> <-------------------- ReleaseCall -----------------------------------------------------<br /> <br /> <br /> ======1.2.5 Errors received from SSF / Timeout detected for class 1 and 3 operations======<br /> <br /> 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.<br /> <br /> SSF SCP<br /> SCP can be in either of the states : 1 / 2 / 3 <br /> <-------------------- Continue --------------------------------------------------------<br /> <br /> <br /> SSF SCP<br /> SCP can be in either of the states : 4 / 5 / 13/ 14 <br /> <-------------------- ReleaseCall --------------------------------------------------------<br /> <br /> <br /> SSF SCP<br /> SCP can be in either of the states : 6 - 11 <br /> 14. <-------------------- MoveLeg --------------------------------------------------------<br /> <br /> <br /> ===Behaviour CAMEL phase 2/3===<br /> <br /> ====Normal procedure for dialogue====<br /> <br /> <br /> The following diagrams will detail the operation of the CRBT script in case of normal, error free phase 2/3 handling.<br /> <br /> <br /> SSF SCP<br /> 1. -------------------------- IDP (serviceKey, termAttemptAuth) ---------------------------><br /> 2. <------ RRBE (leg1,tAbandon) & (leg2,tBusy,tAnswer,tNoAnswer)----------------------------<br /> 3. <------------------------- ETC ----------------------------------------------------------<br /> 4. <------------------------- CONT ---------------------------------------------------------<br /> 5. -------------------------- ERBE (leg2,tAnswer) ------------------------------------------<br /> 6. <------------------------- DFC ----------------------------------------------------------<br /> 7. <------------------------- CONT ---------------------------------------------------------<br /> <br /> ====Abnormal procedures====<br /> <br /> <br /> Situations described in sections 1.2.1 - 1.2.4 shall also apply here.<br /> <br /> ====Errors received from SSF====<br /> <br /> <br /> SSF SCP<br /> SCP can be in either of the states : 2 / 3 <br /> <-------------------- Continue --------------------------------------------------------</div>

Monica https://ss7api.null.ro/index.php/CRBT_logic CRBT logic 2013-10-28T11:05:57Z

<p>Monica: </p> <hr /> <div>The crbt_scp.php is an implementation for a CAMEL gsmSCP application which provides a Colourful Ring Back Tone service by interfacing with a CAMEL gsmSSF.<br /> <br /> Upon service invocation, this script implements the required actions in order to instruct the gsmSSF to provide the required ringback tone.<br /> <br /> ==Configuration==<br /> <br /> ===Script side===<br /> <br /> The CRBT script supports two ways of communicating with Yate:<br /> # One based on the XML protocol, communication being realized through a TCP socket.<br /> # The other one based done through Yate messages, using ''extmodule''.<br /> The way which the script will use is chosen according to configuration - in particular, through the ''$ioType'' setting.<br /> <br /> <br /> Configuration of this script is done through ''config.php''. This allows setting the following parameters:<br /> <br /> * 1. '''$appName'''- value of the ''application'' parameters set in the ''camel.message''. This value is used to check that the message is indeed intented for this script.<br /> <br /> * 2. '''$ioType''' - type of I/O to use to communicate with Yate. The script recognizes these two values:<br /> ** ''TCP'' - use the configured TCP socket to communicate with Yate.<br /> ** ''MSG'' - use messages through exmodule protocol for communication.<br /> <br /> * 3. '''$host''','''$port''' - host and port where the application should connect to in order to communicate with Yate if ''$ioType'' is set to ''TCP''.<br /> <br /> * 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.<br /> <br /> * 5. '''$findMelodyID''' - boolean. It specifies whether the gsmSCF should take the necessary steps in order to find out the required ringtone for the called user. Its default value is false, meaning that the gsmSCF will assume that all requests reaching it are requests for subscribers which have the service activated<br /> <br /> * 6. '''$httpRequest''' - string. It's the HTTP request to be made in order to find out the ringtone associated with the user.<br /> <br /> * 7. '''$myServiceKey''' - integer. The ID of the service provided by this gsmSCF application and which should come in IDP in order to accept the request.<br /> <br /> * 8. '''$myDP''' - string. The DP for which this SCP should be triggered and which should come in IDP in order to accept the request.<br /> <br /> * 9. '''$sendAll''' - bool. If true, it will send all response components batched in a single TCAP message, otherwise it will send them each with its own TCAP message. It is set by default to true.<br /> <br /> * 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:<br /> ** ''prefix_called'' - build the gsmSRF address following this rule <tt>$srfNumber.$srfSeparator.$correlationID.$srfSeparator.$sfcID</tt>.<br /> ** ''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.<br /> <br /> When instructing the SSF to establish a temporary connection to a SRF through an ETC operation, the SCF must provide addressing information to the SSF in regards to the SRF. This information requires:<br /> * the address of the SRF - a routable number<br /> * a correlation ID - that can mean whatever the operators want, but that, according to specification, can be used by the SRF if/when contacting the SCF in order to associate the SSF -> SCF dialogue with the SRF ->SCF dialogue.<br /> * a scfID - an ID for the contacting SCF. This could be used by the SRF to know where to contact the SCF.<br /> <br /> The script provides this information in an ETC operation in 2 ways:<br /> * providing all the above information in the assistingSSPIPAddress. This is done by concatenating the SRF number, correlation ID and scfID -according to an agreement between the SSF and SCF operators. The script simply concatenates these parameters, putting between them the configured separator.<br /> * providing the information in 3 separated parameters:<br /> ** assistingSSPIPAddress - the SRF Number<br /> ** correlationID - the script will set this parameter to either the melody ID or the called party number, encoded in hexified BCD form.<br /> ** scfID - the script will set this parameter to the hexified BCD form of the SCP's GT number.<br /> <br /> Listed bellow are the parameters that need to be configured for the gsmSRF number:<br /> <br /> * '''$srfNumber''' - string. It specifies a number at which the gsmSRF is found.<br /> <br /> * '''$srfSeparator''' - string. Digit(s) used as separator between SRF number, correlationID and sfcID when the assistingSSPIPAddress contains all of them.<br /> <br /> * '''$srfNumber_qualifier''' - string. It specifies the GenericNumber qualifier. It can be one of the following values:<br /> ** ''dialed-digits''<br /> ** ''called-additional''<br /> ** ''caller-failed''<br /> ** ''caller-not-screened''<br /> ** ''terminating''<br /> ** ''connected-additional''<br /> ** ''caller-additional''<br /> ** ''called-original''<br /> ** ''redirecting''<br /> ** ''redirection''<br /> <br /> * '''$srfNumber_complete''' - boolean. It specifies whether the called number is complete or not. It should be complete.<br /> <br /> * '''$srfNumber_nature''' - string. Nature of number. It can have one of the following values:<br /> ** ''unknown''<br /> ** ''international''<br /> ** ''national''<br /> ** ''network-specific''<br /> ** ''subscriber''<br /> ** ''reserved''<br /> ** ''abbreviated''<br /> ** ''extension-reserved''<br /> <br /> * '''$srfNumber_plan''' - string. It's the used numbering plan. It can have one of the following values:<br /> ** ''unknown''<br /> ** ''isdn''<br /> ** ''data''<br /> ** ''telex''<br /> ** ''land-mobile''<br /> ** ''isdn-mobile''<br /> ** ''national''<br /> ** ''private''<br /> ** ''extension-reserved''<br /> <br /> * '''$srfNumber_restrict''' - string. It specifies the presentation of the number. Possible values are:<br /> ** ''allowed''<br /> ** ''restricted''<br /> ** ''unavailable''<br /> ** ''no''<br /> ** ''false''<br /> ** ''yes''<br /> ** ''true''<br /> <br /> * '''$srfNumber_screened''' - string. It specifies the screening indicator for the number. Possible values are:<br /> ** ''user-provided''<br /> ** ''user-provided-passed''<br /> ** ''user-provided-failed''<br /> ** ''network-provided''<br /> ** ''no''<br /> ** ''false''<br /> ** ''yes''<br /> ** ''true''<br /> <br /> <br /> * 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.<br /> <br /> * 12. '''$maxPhase''' - integer.Represents the maximum CAMEL phase allowed for CAMEL interaction. If not set, it will default to 4, meaning that all supported CAMEL phases are allowed.<br /> <br /> * 13. '''$msStateNotAllowed''' - array. List of states received for the subscriber in IDP for which the SCP will abandon CRBT handling and will continue with the call. Recognized values are:<br /> ** ''assumedIdle''<br /> ** ''camelBusy''<br /> ** ''netDetNotReachable''<br /> ** ''notProvidedFromVLR''<br /> It has no default, meaning that it will do CRBT handling ignoring the subscriber state.<br /> <br /> * 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.<br /> <br /> <br /> * 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.<br /> <br /> '''Note''' - The following parameters need not be set usually:<br /> * ''$host'', ''$port'' - set only if you intend to use TCP communication.<br /> * ''$transTimeout''<br /> * ''$sendAll''<br /> * ''$shortTimer'', ''$mediumTimer'', ''$longTimer''<br /> * ''$maxPhase''<br /> * ''$msStateNotAllowed''<br /> * ''$prearrangedEndOn'' - if there is no prearranged end agreement between operator, this doesn't need to be configured.<br /> <br /> * 16. '''$mynum''' - string. GTT number assigned to this SCP.<br /> <br /> ===Yate side===<br /> <br /> On the Yate side, the ''camel_map'' module must be configured through ''camel_map.conf''. <br /> <br /> For functionality provided through a TCP socket, a <tt>[tcap name]</tt> section should be configured. A section looks like this:<br /> <br /> [tcap camel] -- what comes after ''tcap'' will be the name of the translator<br /> ;enable=no -- enable this translator<br /> tcap=tcap-test-itu -- TCAP to be used by the translator for SS7 network communication, a section with that name should be configured in ''ysigchan.conf''<br /> host=0.0.0.0 -- address on which to listen for incoming applications<br /> port=16101 -- port on which to listen for incoming applications<br /> type=CAMEL -- type of translator (MAP/CAMEL). For the intended case, CAMEL should be set<br /> print-messages=true -- whether or not to print TCAP and XML messages in the logs<br /> add-encoding=false -- whether to add encoding attribute to data translated to XML<br /> <br /> <br /> For functionality through Yate messages, an additional section, named <tt>[local appName]</tt> should be configured:<br /> <br /> [local camelLocal] - what comes after ''local'' will be the name of the application<br /> ;enable=no -- enable this application<br /> translator=camel - which translator should be used. A section named [tcap translatorValue] should be present in the config file.<br /> capabilities=Camel - capabilities supported by this application. CAMEL translator have only one capability and that is ''Camel''.<br /> export_xml_as=both - how to export the XML part: string, object or both?<br /> <br /> '''Note:'''<br /> * setting port to 0 will disable the support for TCP applications<br /> * the name of the local application should match the name set in ''$appName'' for the script<br /> <br /> ==Behaviour==<br /> <br /> ===Script behaviour===<br /> <br /> This is a global script that awaits dialog beginnings from SSFs and it is able to handle CAMEL phases 2, 3 and 4.<br /> The phase used for handling the call will be determined using the information provided in the InitialDP operation using the following rules:<br /> * first, an application context check will be done. As seeing that every phase has a different context assigned, phase will be first determined at this stage.<br /> * if the application context determined a phase 4 handling, in the handling of the InitialDP operation these additional checks will be made:<br /> ** the value for ''supportedCamelPhases'' will be checked. In this parameter, the MSC advertises the CAMEL phases that it can handle. From that list, the SCP will choose the highest phase advertised.<br /> ** the value for ''offeredCamel4Functionalities'' will be checked. SCP will verify that all the CAMEL 4 functionalities required for doing CRBT handling in phase 4 are supported. If that is not so, the SCP will downgrade the phase to phase 2 as seeing that the presence of this parameter implied phase 4 functionality and phase 4 functionality implies, by convention, prior phases support also.<br /> <br /> In case of phase 1 detection, the SCP will end the dialogue either with an Abort with application-context-not-supported, either with a Continue operation for CAMEL.<br /> <br /> An configuration parameter was added (''$maxPhase'') - mainly for testing purposes - in order to limit what phase the SCP will accept.<br /> <br /> <br /> Bellow there is detailed description of how the script will act in different scenarios.<br /> <br /> ====Behaviour CAMEL phase 4====<br /> <br /> <br /> =====Normal procedure for dialogue=====<br /> <br /> In case of a normal, error free dialogue, things will proceed according to the describing flow below:<br /> <br /> SSF SCP<br /> 1. --------------------- IDP(serviceKey,termAttemptAuth) --------------------------------><br /> 2. <-------------------- RRBE (tAbandon,leg1) --------------------------------------------<br /> 3. <-------------------- DL (leg2) -------------------------------------------------------<br /> 4. --------------------- DL Result ------------------------------------------------------><br /> 5. <-------------------- ICA (CS2,leg3) --------------------------------------------------<br /> 6. --------------------- ICA Result -----------------------------------------------------><br /> 7. <-------------------- RRBE (oTermSeized,oBusy,oAnswer,oNoAnswer,routeFailure,leg3) ----<br /> 8. <-------------------- CWA (leg3)-------------------------------------------------------<br /> 9. --------------------- ERBE (oTermSeized,leg3) ----------------------------------------><br /> 10. <-------------------- CWA (leg3) ------------------------------------------------------<br /> 11. <-------------------- ETC (CS1) -------------------------------------------------------<br /> 12. --------------------- ERBE (oAnswer,leg3) --------------------------------------------><br /> 13. <-------------------- DFCWA (CS1) -----------------------------------------------------<br /> 14. <-------------------- ML (leg3) -------------------------------------------------------<br /> 15. --------------------- ML Result ------------------------------------------------------><br /> 16. <-------------------- CWA (leg3) ------------------------------------------------------<br /> 17. <-------------------- CWA (CS1) -------------------------------------------------------<br /> <br /> In case of busy received from the called party, the call flow is:<br /> <br /> 1. --------------- ERBE (oCalledPartyBusy, leg3, cause) ----------------------><br /> 2. <-------------- RC (cause received in ERBE/Busy) --------------------------<br /> <br /> =====Abnormal procedures=====<br /> <br /> The following schematics will describe the behaviour of the script in certain scenarios. <br /> 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.<br /> <br /> ======Initial DP ServiceKey mismatch / DP mismatch======<br /> <br /> <br /> SSF SCP<br /> --------------------- IDP(serviceKey,oTermAttemptAuth) -------------------------------><br /> <-------------------- ReturnError(unexpectedDataValue) --------------------------------<br /> <br /> ======Initial DP missing parameters======<br /> <br /> <br /> SSF SCP<br /> --------------------- IDP(serviceKey,oTermAttemptAuth) -------------------------------><br /> <-------------------- ReturnError(missingParameter) -----------------------------------<br /> <br /> ======1.2.3 Application context mismatch======<br /> <br /> <br /> SSF SCP<br /> --------------------- IDP(serviceKey,oTermAttemptAuth) -------------------------------><br /> <-------------------- U_Abort (user-application-context-name-not-supported) -----------<br /> <br /> ======Receiving an unsupported CAMEL phase======<br /> <br /> 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:<br /> <br /> SSF SCP<br /> 1. --------------------- IDP(serviceKey,oTermAttemptAuth) -------------------------------><br /> <-------------------- Continue --------------------------------------------------------<br /> <br /> SSF SCP<br /> 6. --------------------- ICA Result -----------------------------------------------------><br /> <-------------------- ReleaseCall -----------------------------------------------------<br /> <br /> <br /> ======1.2.5 Errors received from SSF / Timeout detected for class 1 and 3 operations======<br /> <br /> 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.<br /> <br /> SSF SCP<br /> SCP can be in either of the states : 1 / 2 / 3 <br /> <-------------------- Continue --------------------------------------------------------<br /> <br /> <br /> SSF SCP<br /> SCP can be in either of the states : 4 / 5 / 13/ 14 <br /> <-------------------- ReleaseCall --------------------------------------------------------<br /> <br /> <br /> SSF SCP<br /> SCP can be in either of the states : 6 - 11 <br /> 14. <-------------------- MoveLeg --------------------------------------------------------<br /> <br /> <br /> ===Behaviour CAMEL phase 2/3===<br /> <br /> ====Normal procedure for dialogue====<br /> <br /> <br /> The following diagrams will detail the operation of the CRBT script in case of normal, error free phase 2/3 handling.<br /> <br /> <br /> SSF SCP<br /> 1. -------------------------- IDP (serviceKey, termAttemptAuth) ---------------------------><br /> 2. <------ RRBE (leg1,tAbandon) & (leg2,tBusy,tAnswer,tNoAnswer)----------------------------<br /> 3. <------------------------- ETC ----------------------------------------------------------<br /> 4. <------------------------- CONT ---------------------------------------------------------<br /> 5. -------------------------- ERBE (leg2,tAnswer) ------------------------------------------<br /> 6. <------------------------- DFC ----------------------------------------------------------<br /> 7. <------------------------- CONT ---------------------------------------------------------<br /> <br /> ====Abnormal procedures====<br /> <br /> <br /> Situations described in sections 1.2.1 - 1.2.4 shall also apply here.<br /> <br /> ====Errors received from SSF====<br /> <br /> <br /> SSF SCP<br /> SCP can be in either of the states : 2 / 3 <br /> <-------------------- Continue --------------------------------------------------------</div>

Monica https://ss7api.null.ro/index.php/CRBT_logic CRBT logic 2013-10-28T11:05:06Z

<p>Monica: /* Script side */</p> <hr /> <div>The crbt_scp.php is an implementation for a CAMEL gsmSCP application which provides a Colourful Ring Back Tone service by interfacing with a CAMEL gsmSSF.<br /> <br /> Upon service invocation, this script implements the required actions in order to instruct the gsmSSF to provide the required ringback tone.<br /> <br /> ==Configuration==<br /> <br /> ===Script side===<br /> <br /> The CRBT script supports two ways of communicating with Yate:<br /> # One based on the XML protocol, communication being realized through a TCP socket.<br /> # The other one based done through Yate messages, using ''extmodule''.<br /> The way which the script will use is chosen according to configuration - in particular, through the ''$ioType'' setting.<br /> <br /> <br /> Configuration of this script is done through ''config.php''. This allows setting the following parameters:<br /> <br /> * 1. '''$appName'''- value of the ''application'' parameters set in the ''camel.message''. This value is used to check that the message is indeed intented for this script.<br /> <br /> * 2. '''$ioType''' - type of I/O to use to communicate with Yate. The script recognizes these two values:<br /> ** ''TCP'' - use the configured TCP socket to communicate with Yate.<br /> ** ''MSG'' - use messages through exmodule protocol for communication.<br /> <br /> * 3. '''$host''','''$port''' - host and port where the application should connect to in order to communicate with Yate if ''$ioType'' is set to ''TCP''.<br /> <br /> * 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.<br /> <br /> * 5. '''$findMelodyID''' - boolean. It specifies whether the gsmSCF should take the necessary steps in order to find out the required ringtone for the called user. Its default value is false, meaning that the gsmSCF will assume that all requests reaching it are requests for subscribers which have the service activated<br /> <br /> * 6. '''$httpRequest''' - string. It's the HTTP request to be made in order to find out the ringtone associated with the user.<br /> <br /> * 7. '''$myServiceKey''' - integer. The ID of the service provided by this gsmSCF application and which should come in IDP in order to accept the request.<br /> <br /> * 8. '''$myDP''' - string. The DP for which this SCP should be triggered and which should come in IDP in order to accept the request.<br /> <br /> * 9. '''$sendAll''' - bool. If true, it will send all response components batched in a single TCAP message, otherwise it will send them each with its own TCAP message. It is set by default to true.<br /> <br /> * 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:<br /> ** ''prefix_called'' - build the gsmSRF address following this rule <tt>$srfNumber.$srfSeparator.$correlationID.$srfSeparator.$sfcID</tt>.<br /> ** ''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.<br /> <br /> When instructing the SSF to establish a temporary connection to a SRF through an ETC operation, the SCF must provide addressing information to the SSF in regards to the SRF. This information requires:<br /> * the address of the SRF - a routable number<br /> * a correlation ID - that can mean whatever the operators want, but that, according to specification, can be used by the SRF if/when contacting the SCF in order to associate the SSF -> SCF dialogue with the SRF ->SCF dialogue.<br /> * a scfID - an ID for the contacting SCF. This could be used by the SRF to know where to contact the SCF.<br /> <br /> The script provides this information in an ETC operation in 2 ways:<br /> * providing all the above information in the assistingSSPIPAddress. This is done by concatenating the SRF number, correlation ID and scfID -according to an agreement between the SSF and SCF operators. The script simply concatenates these parameters, putting between them the configured separator.<br /> * providing the information in 3 separated parameters:<br /> ** assistingSSPIPAddress - the SRF Number<br /> ** correlationID - the script will set this parameter to either the melody ID or the called party number, encoded in hexified BCD form.<br /> ** scfID - the script will set this parameter to the hexified BCD form of the SCP's GT number.<br /> <br /> Listed bellow are the parameters that need to be configured for the gsmSRF number:<br /> <br /> * '''$srfNumber''' - string. It specifies a number at which the gsmSRF is found.<br /> <br /> * '''$srfSeparator''' - string. Digit(s) used as separator between SRF number, correlationID and sfcID when the assistingSSPIPAddress contains all of them.<br /> <br /> * '''$srfNumber_qualifier''' - string. It specifies the GenericNumber qualifier. It can be one of the following values:<br /> ** ''dialed-digits''<br /> ** ''called-additional''<br /> ** ''caller-failed''<br /> ** ''caller-not-screened''<br /> ** ''terminating''<br /> ** ''connected-additional''<br /> ** ''caller-additional''<br /> ** ''called-original''<br /> ** ''redirecting''<br /> ** ''redirection''<br /> <br /> * '''$srfNumber_complete''' - boolean. It specifies whether the called number is complete or not. It should be complete.<br /> <br /> * '''$srfNumber_nature''' - string. Nature of number. It can have one of the following values:<br /> ** ''unknown''<br /> ** ''international''<br /> ** ''national''<br /> ** ''network-specific''<br /> ** ''subscriber''<br /> ** ''reserved''<br /> ** ''abbreviated''<br /> ** ''extension-reserved''<br /> <br /> * '''$srfNumber_plan''' - string. It's the used numbering plan. It can have one of the following values:<br /> ** ''unknown''<br /> ** ''isdn''<br /> ** ''data''<br /> ** ''telex''<br /> ** ''land-mobile''<br /> ** ''isdn-mobile''<br /> ** ''national''<br /> ** ''private''<br /> ** ''extension-reserved''<br /> <br /> * '''$srfNumber_restrict''' - string. It specifies the presentation of the number. Possible values are:<br /> ** ''allowed''<br /> ** ''restricted''<br /> ** ''unavailable''<br /> ** ''no''<br /> ** ''false''<br /> ** ''yes''<br /> ** ''true''<br /> <br /> * '''$srfNumber_screened''' - string. It specifies the screening indicator for the number. Possible values are:<br /> ** ''user-provided''<br /> ** ''user-provided-passed''<br /> ** ''user-provided-failed''<br /> ** ''network-provided''<br /> ** ''no''<br /> ** ''false''<br /> ** ''yes''<br /> ** ''true''<br /> <br /> <br /> * 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.<br /> <br /> * 12. '''$maxPhase''' - integer.Represents the maximum CAMEL phase allowed for CAMEL interaction. If not set, it will default to 4, meaning that all supported CAMEL phases are allowed.<br /> <br /> * 13. '''$msStateNotAllowed''' - array. List of states received for the subscriber in IDP for which the SCP will abandon CRBT handling and will continue with the call. Recognized values are:<br /> ** ''assumedIdle''<br /> ** ''camelBusy''<br /> ** ''netDetNotReachable''<br /> ** ''notProvidedFromVLR''<br /> It has no default, meaning that it will do CRBT handling ignoring the subscriber state.<br /> <br /> * 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.<br /> <br /> <br /> * 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.<br /> <br /> '''Note''' - The following parameters need not be set usually:<br /> * ''$host'', ''$port'' - set only if you intend to use TCP communication.<br /> * ''$transTimeout''<br /> * ''$sendAll''<br /> * ''$shortTimer'', ''$mediumTimer'', ''$longTimer''<br /> * ''$maxPhase''<br /> * ''$msStateNotAllowed''<br /> * ''$prearrangedEndOn'' - if there is no prearranged end agreement between operator, this doesn't need to be configured.<br /> <br /> * 16. '''$mynum''' - string. GTT number assigned to this SCP.<br /> <br /> ===Yate side===<br /> <br /> On the Yate side, the ''camel_map'' module must be configured through ''camel_map.conf''. <br /> <br /> For functionality provided through a TCP socket, a @@[tcap name]@@ section should be configured. A section looks like this:<br /> <br /> [tcap camel] -- what comes after ''tcap'' will be the name of the translator<br /> ;enable=no -- enable this translator<br /> tcap=tcap-test-itu -- TCAP to be used by the translator for SS7 network communication, a section with that name should be configured in ''ysigchan.conf''<br /> host=0.0.0.0 -- address on which to listen for incoming applications<br /> port=16101 -- port on which to listen for incoming applications<br /> type=CAMEL -- type of translator (MAP/CAMEL). For the intended case, CAMEL should be set<br /> print-messages=true -- whether or not to print TCAP and XML messages in the logs<br /> add-encoding=false -- whether to add encoding attribute to data translated to XML<br /> <br /> <br /> For functionality through Yate messages, an additional section, named @@[local appName]@@ should be configured:<br /> <br /> [local camelLocal] - what comes after ''local'' will be the name of the application<br /> ;enable=no -- enable this application<br /> translator=camel - which translator should be used. A section named [tcap translatorValue] should be present in the config file.<br /> capabilities=Camel - capabilities supported by this application. CAMEL translator have only one capability and that is ''Camel''.<br /> export_xml_as=both - how to export the XML part: string, object or both?<br /> <br /> '''Note:'''<br /> * setting port to 0 will disable the support for TCP applications<br /> * the name of the local application should match the name set in ''$appName'' for the script<br /> <br /> ==Behaviour==<br /> <br /> ===Script behaviour===<br /> <br /> This is a global script that awaits dialog beginnings from SSFs and it is able to handle CAMEL phases 2, 3 and 4.<br /> The phase used for handling the call will be determined using the information provided in the InitialDP operation using the following rules:<br /> * first, an application context check will be done. As seeing that every phase has a different context assigned, phase will be first determined at this stage.<br /> * if the application context determined a phase 4 handling, in the handling of the InitialDP operation these additional checks will be made:<br /> ** the value for ''supportedCamelPhases'' will be checked. In this parameter, the MSC advertises the CAMEL phases that it can handle. From that list, the SCP will choose the highest phase advertised.<br /> ** the value for ''offeredCamel4Functionalities'' will be checked. SCP will verify that all the CAMEL 4 functionalities required for doing CRBT handling in phase 4 are supported. If that is not so, the SCP will downgrade the phase to phase 2 as seeing that the presence of this parameter implied phase 4 functionality and phase 4 functionality implies, by convention, prior phases support also.<br /> <br /> In case of phase 1 detection, the SCP will end the dialogue either with an Abort with application-context-not-supported, either with a Continue operation for CAMEL.<br /> <br /> An configuration parameter was added (''$maxPhase'') - mainly for testing purposes - in order to limit what phase the SCP will accept.<br /> <br /> <br /> Bellow there is detailed description of how the script will act in different scenarios.<br /> <br /> ====Behaviour CAMEL phase 4====<br /> <br /> <br /> =====Normal procedure for dialogue=====<br /> <br /> In case of a normal, error free dialogue, things will proceed according to the describing flow below:<br /> <br /> SSF SCP<br /> 1. --------------------- IDP(serviceKey,termAttemptAuth) --------------------------------><br /> 2. <-------------------- RRBE (tAbandon,leg1) --------------------------------------------<br /> 3. <-------------------- DL (leg2) -------------------------------------------------------<br /> 4. --------------------- DL Result ------------------------------------------------------><br /> 5. <-------------------- ICA (CS2,leg3) --------------------------------------------------<br /> 6. --------------------- ICA Result -----------------------------------------------------><br /> 7. <-------------------- RRBE (oTermSeized,oBusy,oAnswer,oNoAnswer,routeFailure,leg3) ----<br /> 8. <-------------------- CWA (leg3)-------------------------------------------------------<br /> 9. --------------------- ERBE (oTermSeized,leg3) ----------------------------------------><br /> 10. <-------------------- CWA (leg3) ------------------------------------------------------<br /> 11. <-------------------- ETC (CS1) -------------------------------------------------------<br /> 12. --------------------- ERBE (oAnswer,leg3) --------------------------------------------><br /> 13. <-------------------- DFCWA (CS1) -----------------------------------------------------<br /> 14. <-------------------- ML (leg3) -------------------------------------------------------<br /> 15. --------------------- ML Result ------------------------------------------------------><br /> 16. <-------------------- CWA (leg3) ------------------------------------------------------<br /> 17. <-------------------- CWA (CS1) -------------------------------------------------------<br /> <br /> In case of busy received from the called party, the call flow is:<br /> <br /> 1. --------------- ERBE (oCalledPartyBusy, leg3, cause) ----------------------><br /> 2. <-------------- RC (cause received in ERBE/Busy) --------------------------<br /> <br /> =====Abnormal procedures=====<br /> <br /> The following schematics will describe the behaviour of the script in certain scenarios. <br /> 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.<br /> <br /> ======Initial DP ServiceKey mismatch / DP mismatch======<br /> <br /> <br /> SSF SCP<br /> --------------------- IDP(serviceKey,oTermAttemptAuth) -------------------------------><br /> <-------------------- ReturnError(unexpectedDataValue) --------------------------------<br /> <br /> ======Initial DP missing parameters======<br /> <br /> <br /> SSF SCP<br /> --------------------- IDP(serviceKey,oTermAttemptAuth) -------------------------------><br /> <-------------------- ReturnError(missingParameter) -----------------------------------<br /> <br /> ======1.2.3 Application context mismatch======<br /> <br /> <br /> SSF SCP<br /> --------------------- IDP(serviceKey,oTermAttemptAuth) -------------------------------><br /> <-------------------- U_Abort (user-application-context-name-not-supported) -----------<br /> <br /> ======Receiving an unsupported CAMEL phase======<br /> <br /> 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:<br /> <br /> SSF SCP<br /> 1. --------------------- IDP(serviceKey,oTermAttemptAuth) -------------------------------><br /> <-------------------- Continue --------------------------------------------------------<br /> <br /> SSF SCP<br /> 6. --------------------- ICA Result -----------------------------------------------------><br /> <-------------------- ReleaseCall -----------------------------------------------------<br /> <br /> <br /> ======1.2.5 Errors received from SSF / Timeout detected for class 1 and 3 operations======<br /> <br /> 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.<br /> <br /> SSF SCP<br /> SCP can be in either of the states : 1 / 2 / 3 <br /> <-------------------- Continue --------------------------------------------------------<br /> <br /> <br /> SSF SCP<br /> SCP can be in either of the states : 4 / 5 / 13/ 14 <br /> <-------------------- ReleaseCall --------------------------------------------------------<br /> <br /> <br /> SSF SCP<br /> SCP can be in either of the states : 6 - 11 <br /> 14. <-------------------- MoveLeg --------------------------------------------------------<br /> <br /> <br /> ===Behaviour CAMEL phase 2/3===<br /> <br /> ====Normal procedure for dialogue====<br /> <br /> <br /> The following diagrams will detail the operation of the CRBT script in case of normal, error free phase 2/3 handling.<br /> <br /> <br /> SSF SCP<br /> 1. -------------------------- IDP (serviceKey, termAttemptAuth) ---------------------------><br /> 2. <------ RRBE (leg1,tAbandon) & (leg2,tBusy,tAnswer,tNoAnswer)----------------------------<br /> 3. <------------------------- ETC ----------------------------------------------------------<br /> 4. <------------------------- CONT ---------------------------------------------------------<br /> 5. -------------------------- ERBE (leg2,tAnswer) ------------------------------------------<br /> 6. <------------------------- DFC ----------------------------------------------------------<br /> 7. <------------------------- CONT ---------------------------------------------------------<br /> <br /> ====Abnormal procedures====<br /> <br /> <br /> Situations described in sections 1.2.1 - 1.2.4 shall also apply here.<br /> <br /> ====Errors received from SSF====<br /> <br /> <br /> SSF SCP<br /> SCP can be in either of the states : 2 / 3 <br /> <-------------------- Continue --------------------------------------------------------</div>

Monica https://ss7api.null.ro/index.php/CRBT_logic CRBT logic 2013-10-28T10:32:22Z

<p>Monica: /* Script side */</p> <hr /> <div>The crbt_scp.php is an implementation for a CAMEL gsmSCP application which provides a Colourful Ring Back Tone service by interfacing with a CAMEL gsmSSF.<br /> <br /> Upon service invocation, this script implements the required actions in order to instruct the gsmSSF to provide the required ringback tone.<br /> <br /> ==Configuration==<br /> <br /> ===Script side===<br /> <br /> The CRBT script supports two ways of communicating with Yate:<br /> # One based on the XML protocol, communication being realized through a TCP socket.<br /> # The other one based done through Yate messages, using ''extmodule''.<br /> The way which the script will use is chosen according to configuration - in particular, through the ''$ioType'' setting.<br /> <br /> <br /> Configuration of this script is done through ''config.php''. This allows setting the following parameters:<br /> <br /> * 1. '''$appName'''- value of the ''application'' parameters set in the ''camel.message''. This value is used to check that the message is indeed intented for this script.<br /> <br /> * 2. '''$ioType''' - type of I/O to use to communicate with Yate. The script recognizes these two values:<br /> ** ''TCP'' - use the configured TCP socket to communicate with Yate.<br /> ** ''MSG'' - use messages through exmodule protocol for communication.<br /> <br /> * 3. '''$host''','''$port''' - host and port where the application should connect to in order to communicate with Yate if ''$ioType'' is set to ''TCP''.<br /> <br /> * 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.<br /> <br /> * 5. '''$findMelodyID''' - boolean. It specifies whether the gsmSCF should take the necessary steps in order to find out the required ringtone for the called user. Its default value is false, meaning that the gsmSCF will assume that all requests reaching it are requests for subscribers which have the service activated<br /> <br /> * 6. '''$httpRequest''' - string. It's the HTTP request to be made in order to find out the ringtone associated with the user.<br /> <br /> * 7. '''$myServiceKey''' - integer. The ID of the service provided by this gsmSCF application and which should come in IDP in order to accept the request.<br /> <br /> * 8. '''$myDP''' - string. The DP for which this SCP should be triggered and which should come in IDP in order to accept the request.<br /> <br /> * 9. '''$sendAll''' - bool. If true, it will send all response components batched in a single TCAP message, otherwise it will send them each with its own TCAP message. It is set by default to true.<br /> <br /> * 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:<br /> ** ''prefix_called'' - build the gsmSRF address following this rule @@$srfNumber.$srfSeparator.$correlationID.$srfSeparator.$sfcID@@.<br /> ** ''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.<br /> <br /> When instructing the SSF to establish a temporary connection to a SRF through an ETC operation, the SCF must provide addressing information to the SSF in regards to the SRF. This information requires:<br /> * the address of the SRF - a routable number<br /> * a correlation ID - that can mean whatever the operators want, but that, according to specification, can be used by the SRF if/when contacting the SCF in order to associate the SSF -> SCF dialogue with the SRF ->SCF dialogue.<br /> * a scfID - an ID for the contacting SCF. This could be used by the SRF to know where to contact the SCF.<br /> <br /> The script provides this information in an ETC operation in 2 ways:<br /> * providing all the above information in the assistingSSPIPAddress. This is done by concatenating the SRF number, correlation ID and scfID -according to an agreement between the SSF and SCF operators. The script simply concatenates these parameters, putting between them the configured separator.<br /> * providing the information in 3 separated parameters:<br /> ** assistingSSPIPAddress - the SRF Number<br /> ** correlationID - the script will set this parameter to either the melody ID or the called party number, encoded in hexified BCD form.<br /> ** scfID - the script will set this parameter to the hexified BCD form of the SCP's GT number.<br /> <br /> Listed bellow are the parameters that need to be configured for the gsmSRF number:<br /> <br /> * '''$srfNumber''' - string. It specifies a number at which the gsmSRF is found.<br /> <br /> * '''$srfSeparator''' - string. Digit(s) used as separator between SRF number, correlationID and sfcID when the assistingSSPIPAddress contains all of them.<br /> <br /> * '''$srfNumber_qualifier''' - string. It specifies the GenericNumber qualifier. It can be one of the following values:<br /> ** ''dialed-digits''<br /> ** ''called-additional''<br /> ** ''caller-failed''<br /> ** ''caller-not-screened''<br /> ** ''terminating''<br /> ** ''connected-additional''<br /> ** ''caller-additional''<br /> ** ''called-original''<br /> ** ''redirecting''<br /> ** ''redirection''<br /> <br /> * '''$srfNumber_complete''' - boolean. It specifies whether the called number is complete or not. It should be complete.<br /> <br /> * '''$srfNumber_nature''' - string. Nature of number. It can have one of the following values:<br /> ** ''unknown''<br /> ** ''international''<br /> ** ''national''<br /> ** ''network-specific''<br /> ** ''subscriber''<br /> ** ''reserved''<br /> ** ''abbreviated''<br /> ** ''extension-reserved''<br /> <br /> * '''$srfNumber_plan''' - string. It's the used numbering plan. It can have one of the following values:<br /> ** ''unknown''<br /> ** ''isdn''<br /> ** ''data''<br /> ** ''telex''<br /> ** ''land-mobile''<br /> ** ''isdn-mobile''<br /> ** ''national''<br /> ** ''private''<br /> ** ''extension-reserved''<br /> <br /> * '''$srfNumber_restrict''' - string. It specifies the presentation of the number. Possible values are:<br /> ** ''allowed''<br /> ** ''restricted''<br /> ** ''unavailable''<br /> ** ''no''<br /> ** ''false''<br /> ** ''yes''<br /> ** ''true''<br /> <br /> * '''$srfNumber_screened''' - string. It specifies the screening indicator for the number. Possible values are:<br /> ** ''user-provided''<br /> ** ''user-provided-passed''<br /> ** ''user-provided-failed''<br /> ** ''network-provided''<br /> ** ''no''<br /> ** ''false''<br /> ** ''yes''<br /> ** ''true''<br /> <br /> <br /> * 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.<br /> <br /> * 12. '''$maxPhase''' - integer.Represents the maximum CAMEL phase allowed for CAMEL interaction. If not set, it will default to 4, meaning that all supported CAMEL phases are allowed.<br /> <br /> * 13. '''$msStateNotAllowed''' - array. List of states received for the subscriber in IDP for which the SCP will abandon CRBT handling and will continue with the call. Recognized values are:<br /> ** ''assumedIdle''<br /> ** ''camelBusy''<br /> ** ''netDetNotReachable''<br /> ** ''notProvidedFromVLR''<br /> It has no default, meaning that it will do CRBT handling ignoring the subscriber state.<br /> <br /> * 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.<br /> <br /> <br /> * 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.<br /> <br /> '''Note''' - The following parameters need not be set usually:<br /> * ''$host'', ''$port'' - set only if you intend to use TCP communication.<br /> * ''$transTimeout''<br /> * ''$sendAll''<br /> * ''$shortTimer'', ''$mediumTimer'', ''$longTimer''<br /> * ''$maxPhase''<br /> * ''$msStateNotAllowed''<br /> * ''$prearrangedEndOn'' - if there is no prearranged end agreement between operator, this doesn't need to be configured.<br /> <br /> * 16. '''$mynum''' - string. GTT number assigned to this SCP.<br /> <br /> ===Yate side===<br /> <br /> On the Yate side, the ''camel_map'' module must be configured through ''camel_map.conf''. <br /> <br /> For functionality provided through a TCP socket, a @@[tcap name]@@ section should be configured. A section looks like this:<br /> <br /> [tcap camel] -- what comes after ''tcap'' will be the name of the translator<br /> ;enable=no -- enable this translator<br /> tcap=tcap-test-itu -- TCAP to be used by the translator for SS7 network communication, a section with that name should be configured in ''ysigchan.conf''<br /> host=0.0.0.0 -- address on which to listen for incoming applications<br /> port=16101 -- port on which to listen for incoming applications<br /> type=CAMEL -- type of translator (MAP/CAMEL). For the intended case, CAMEL should be set<br /> print-messages=true -- whether or not to print TCAP and XML messages in the logs<br /> add-encoding=false -- whether to add encoding attribute to data translated to XML<br /> <br /> <br /> For functionality through Yate messages, an additional section, named @@[local appName]@@ should be configured:<br /> <br /> [local camelLocal] - what comes after ''local'' will be the name of the application<br /> ;enable=no -- enable this application<br /> translator=camel - which translator should be used. A section named [tcap translatorValue] should be present in the config file.<br /> capabilities=Camel - capabilities supported by this application. CAMEL translator have only one capability and that is ''Camel''.<br /> export_xml_as=both - how to export the XML part: string, object or both?<br /> <br /> '''Note:'''<br /> * setting port to 0 will disable the support for TCP applications<br /> * the name of the local application should match the name set in ''$appName'' for the script<br /> <br /> ==Behaviour==<br /> <br /> ===Script behaviour===<br /> <br /> This is a global script that awaits dialog beginnings from SSFs and it is able to handle CAMEL phases 2, 3 and 4.<br /> The phase used for handling the call will be determined using the information provided in the InitialDP operation using the following rules:<br /> * first, an application context check will be done. As seeing that every phase has a different context assigned, phase will be first determined at this stage.<br /> * if the application context determined a phase 4 handling, in the handling of the InitialDP operation these additional checks will be made:<br /> ** the value for ''supportedCamelPhases'' will be checked. In this parameter, the MSC advertises the CAMEL phases that it can handle. From that list, the SCP will choose the highest phase advertised.<br /> ** the value for ''offeredCamel4Functionalities'' will be checked. SCP will verify that all the CAMEL 4 functionalities required for doing CRBT handling in phase 4 are supported. If that is not so, the SCP will downgrade the phase to phase 2 as seeing that the presence of this parameter implied phase 4 functionality and phase 4 functionality implies, by convention, prior phases support also.<br /> <br /> In case of phase 1 detection, the SCP will end the dialogue either with an Abort with application-context-not-supported, either with a Continue operation for CAMEL.<br /> <br /> An configuration parameter was added (''$maxPhase'') - mainly for testing purposes - in order to limit what phase the SCP will accept.<br /> <br /> <br /> Bellow there is detailed description of how the script will act in different scenarios.<br /> <br /> ====Behaviour CAMEL phase 4====<br /> <br /> <br /> =====Normal procedure for dialogue=====<br /> <br /> In case of a normal, error free dialogue, things will proceed according to the describing flow below:<br /> <br /> SSF SCP<br /> 1. --------------------- IDP(serviceKey,termAttemptAuth) --------------------------------><br /> 2. <-------------------- RRBE (tAbandon,leg1) --------------------------------------------<br /> 3. <-------------------- DL (leg2) -------------------------------------------------------<br /> 4. --------------------- DL Result ------------------------------------------------------><br /> 5. <-------------------- ICA (CS2,leg3) --------------------------------------------------<br /> 6. --------------------- ICA Result -----------------------------------------------------><br /> 7. <-------------------- RRBE (oTermSeized,oBusy,oAnswer,oNoAnswer,routeFailure,leg3) ----<br /> 8. <-------------------- CWA (leg3)-------------------------------------------------------<br /> 9. --------------------- ERBE (oTermSeized,leg3) ----------------------------------------><br /> 10. <-------------------- CWA (leg3) ------------------------------------------------------<br /> 11. <-------------------- ETC (CS1) -------------------------------------------------------<br /> 12. --------------------- ERBE (oAnswer,leg3) --------------------------------------------><br /> 13. <-------------------- DFCWA (CS1) -----------------------------------------------------<br /> 14. <-------------------- ML (leg3) -------------------------------------------------------<br /> 15. --------------------- ML Result ------------------------------------------------------><br /> 16. <-------------------- CWA (leg3) ------------------------------------------------------<br /> 17. <-------------------- CWA (CS1) -------------------------------------------------------<br /> <br /> In case of busy received from the called party, the call flow is:<br /> <br /> 1. --------------- ERBE (oCalledPartyBusy, leg3, cause) ----------------------><br /> 2. <-------------- RC (cause received in ERBE/Busy) --------------------------<br /> <br /> =====Abnormal procedures=====<br /> <br /> The following schematics will describe the behaviour of the script in certain scenarios. <br /> 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.<br /> <br /> ======Initial DP ServiceKey mismatch / DP mismatch======<br /> <br /> <br /> SSF SCP<br /> --------------------- IDP(serviceKey,oTermAttemptAuth) -------------------------------><br /> <-------------------- ReturnError(unexpectedDataValue) --------------------------------<br /> <br /> ======Initial DP missing parameters======<br /> <br /> <br /> SSF SCP<br /> --------------------- IDP(serviceKey,oTermAttemptAuth) -------------------------------><br /> <-------------------- ReturnError(missingParameter) -----------------------------------<br /> <br /> ======1.2.3 Application context mismatch======<br /> <br /> <br /> SSF SCP<br /> --------------------- IDP(serviceKey,oTermAttemptAuth) -------------------------------><br /> <-------------------- U_Abort (user-application-context-name-not-supported) -----------<br /> <br /> ======Receiving an unsupported CAMEL phase======<br /> <br /> 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:<br /> <br /> SSF SCP<br /> 1. --------------------- IDP(serviceKey,oTermAttemptAuth) -------------------------------><br /> <-------------------- Continue --------------------------------------------------------<br /> <br /> SSF SCP<br /> 6. --------------------- ICA Result -----------------------------------------------------><br /> <-------------------- ReleaseCall -----------------------------------------------------<br /> <br /> <br /> ======1.2.5 Errors received from SSF / Timeout detected for class 1 and 3 operations======<br /> <br /> 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.<br /> <br /> SSF SCP<br /> SCP can be in either of the states : 1 / 2 / 3 <br /> <-------------------- Continue --------------------------------------------------------<br /> <br /> <br /> SSF SCP<br /> SCP can be in either of the states : 4 / 5 / 13/ 14 <br /> <-------------------- ReleaseCall --------------------------------------------------------<br /> <br /> <br /> SSF SCP<br /> SCP can be in either of the states : 6 - 11 <br /> 14. <-------------------- MoveLeg --------------------------------------------------------<br /> <br /> <br /> ===Behaviour CAMEL phase 2/3===<br /> <br /> ====Normal procedure for dialogue====<br /> <br /> <br /> The following diagrams will detail the operation of the CRBT script in case of normal, error free phase 2/3 handling.<br /> <br /> <br /> SSF SCP<br /> 1. -------------------------- IDP (serviceKey, termAttemptAuth) ---------------------------><br /> 2. <------ RRBE (leg1,tAbandon) & (leg2,tBusy,tAnswer,tNoAnswer)----------------------------<br /> 3. <------------------------- ETC ----------------------------------------------------------<br /> 4. <------------------------- CONT ---------------------------------------------------------<br /> 5. -------------------------- ERBE (leg2,tAnswer) ------------------------------------------<br /> 6. <------------------------- DFC ----------------------------------------------------------<br /> 7. <------------------------- CONT ---------------------------------------------------------<br /> <br /> ====Abnormal procedures====<br /> <br /> <br /> Situations described in sections 1.2.1 - 1.2.4 shall also apply here.<br /> <br /> ====Errors received from SSF====<br /> <br /> <br /> SSF SCP<br /> SCP can be in either of the states : 2 / 3 <br /> <-------------------- Continue --------------------------------------------------------</div>

Monica https://ss7api.null.ro/index.php/CRBT_logic CRBT logic 2013-10-28T10:31:00Z

<p>Monica: </p> <hr /> <div>The crbt_scp.php is an implementation for a CAMEL gsmSCP application which provides a Colourful Ring Back Tone service by interfacing with a CAMEL gsmSSF.<br /> <br /> Upon service invocation, this script implements the required actions in order to instruct the gsmSSF to provide the required ringback tone.<br /> <br /> ==Configuration==<br /> <br /> ===Script side===<br /> <br /> The CRBT script supports two ways of communicating with Yate:<br /> # One based on the XML protocol, communication being realized through a TCP socket.<br /> # The other one based done through Yate messages, using ''extmodule''.<br /> The way which the script will use is chosen according to configuration - in particular, through the ''$ioType'' setting.<br /> <br /> <br /> Configuration of this script is done through ''config.php''. This allows setting the following parameters:<br /> <br /> * 1. '''$appName'''- value of the ''application'' parameters set in the ''camel.message''. This value is used to check that the message is indeed intented for this script.<br /> <br /> * 2. '''$ioType''' - type of I/O to use to communicate with Yate. The script recognizes these two values:<br /> ** ''TCP'' - use the configured TCP socket to communicate with Yate.<br /> ** ''MSG'' - use messages through exmodule protocol for communication.<br /> <br /> * 3. '''$host''','''$port''' - host and port where the application should connect to in order to communicate with Yate if ''$ioType'' is set to ''TCP''.<br /> '<br /> * 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.<br /> <br /> * 5. '''$findMelodyID''' - boolean. It specifies whether the gsmSCF should take the necessary steps in order to find out the required ringtone for the called user. Its default value is false, meaning that the gsmSCF will assume that all requests reaching it are requests for subscribers which have the service activated<br /> <br /> * 6. '''$httpRequest''' - string. It's the HTTP request to be made in order to find out the ringtone associated with the user.<br /> <br /> * 7. '''$myServiceKey''' - integer. The ID of the service provided by this gsmSCF application and which should come in IDP in order to accept the request.<br /> <br /> * 8. '''$myDP''' - string. The DP for which this SCP should be triggered and which should come in IDP in order to accept the request.<br /> <br /> * 9. '''$sendAll''' - bool. If true, it will send all response components batched in a single TCAP message, otherwise it will send them each with its own TCAP message. It is set by default to true.<br /> <br /> * 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:<br /> ** ''prefix_called'' - build the gsmSRF address following this rule @@$srfNumber.$srfSeparator.$correlationID.$srfSeparator.$sfcID@@.<br /> ** ''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.<br /> <br /> When instructing the SSF to establish a temporary connection to a SRF through an ETC operation, the SCF must provide addressing information to the SSF in regards to the SRF. This information requires:<br /> * the address of the SRF - a routable number<br /> * a correlation ID - that can mean whatever the operators want, but that, according to specification, can be used by the SRF if/when contacting the SCF in order to associate the SSF -> SCF dialogue with the SRF ->SCF dialogue.<br /> * a scfID - an ID for the contacting SCF. This could be used by the SRF to know where to contact the SCF.<br /> <br /> The script provides this information in an ETC operation in 2 ways:<br /> * providing all the above information in the assistingSSPIPAddress. This is done by concatenating the SRF number, correlation ID and scfID -according to an agreement between the SSF and SCF operators. The script simply concatenates these parameters, putting between them the configured separator.<br /> * providing the information in 3 separated parameters:<br /> ** assistingSSPIPAddress - the SRF Number<br /> ** correlationID - the script will set this parameter to either the melody ID or the called party number, encoded in hexified BCD form.<br /> ** scfID - the script will set this parameter to the hexified BCD form of the SCP's GT number.<br /> <br /> Listed bellow are the parameters that need to be configured for the gsmSRF number:<br /> <br /> * '''$srfNumber''' - string. It specifies a number at which the gsmSRF is found.<br /> <br /> * '''$srfSeparator''' - string. Digit(s) used as separator between SRF number, correlationID and sfcID when the assistingSSPIPAddress contains all of them.<br /> <br /> * '''$srfNumber_qualifier''' - string. It specifies the GenericNumber qualifier. It can be one of the following values:<br /> ** ''dialed-digits''<br /> ** ''called-additional''<br /> ** ''caller-failed''<br /> ** ''caller-not-screened''<br /> ** ''terminating''<br /> ** ''connected-additional''<br /> ** ''caller-additional''<br /> ** ''called-original''<br /> ** ''redirecting''<br /> ** ''redirection''<br /> <br /> * '''$srfNumber_complete''' - boolean. It specifies whether the called number is complete or not. It should be complete.<br /> <br /> * '''$srfNumber_nature''' - string. Nature of number. It can have one of the following values:<br /> ** ''unknown''<br /> ** ''international''<br /> ** ''national''<br /> ** ''network-specific''<br /> ** ''subscriber''<br /> ** ''reserved''<br /> ** ''abbreviated''<br /> ** ''extension-reserved''<br /> <br /> * '''$srfNumber_plan''' - string. It's the used numbering plan. It can have one of the following values:<br /> ** ''unknown''<br /> ** ''isdn''<br /> ** ''data''<br /> ** ''telex''<br /> ** ''land-mobile''<br /> ** ''isdn-mobile''<br /> ** ''national''<br /> ** ''private''<br /> ** ''extension-reserved''<br /> <br /> * '''$srfNumber_restrict''' - string. It specifies the presentation of the number. Possible values are:<br /> ** ''allowed''<br /> ** ''restricted''<br /> ** ''unavailable''<br /> ** ''no''<br /> ** ''false''<br /> ** ''yes''<br /> ** ''true''<br /> <br /> * '''$srfNumber_screened''' - string. It specifies the screening indicator for the number. Possible values are:<br /> ** ''user-provided''<br /> ** ''user-provided-passed''<br /> ** ''user-provided-failed''<br /> ** ''network-provided''<br /> ** ''no''<br /> ** ''false''<br /> ** ''yes''<br /> ** ''true''<br /> <br /> <br /> * 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.<br /> <br /> * 12. '''$maxPhase''' - integer.Represents the maximum CAMEL phase allowed for CAMEL interaction. If not set, it will default to 4, meaning that all supported CAMEL phases are allowed.<br /> <br /> * 13. '''$msStateNotAllowed''' - array. List of states received for the subscriber in IDP for which the SCP will abandon CRBT handling and will continue with the call. Recognized values are:<br /> ** ''assumedIdle''<br /> ** ''camelBusy''<br /> ** ''netDetNotReachable''<br /> ** ''notProvidedFromVLR''<br /> It has no default, meaning that it will do CRBT handling ignoring the subscriber state.<br /> <br /> * 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.<br /> <br /> <br /> * 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.<br /> <br /> '''Note''' - The following parameters need not be set usually:<br /> * ''$host'', ''$port'' - set only if you intend to use TCP communication.<br /> * ''$transTimeout''<br /> * ''$sendAll''<br /> * ''$shortTimer'', ''$mediumTimer'', ''$longTimer''<br /> * ''$maxPhase''<br /> * ''$msStateNotAllowed''<br /> * ''$prearrangedEndOn'' - if there is no prearranged end agreement between operator, this doesn't need to be configured.<br /> <br /> * 16. '''$mynum''' - string. GTT number assigned to this SCP.<br /> <br /> <br /> ===Yate side===<br /> <br /> On the Yate side, the ''camel_map'' module must be configured through ''camel_map.conf''. <br /> <br /> For functionality provided through a TCP socket, a @@[tcap name]@@ section should be configured. A section looks like this:<br /> <br /> [tcap camel] -- what comes after ''tcap'' will be the name of the translator<br /> ;enable=no -- enable this translator<br /> tcap=tcap-test-itu -- TCAP to be used by the translator for SS7 network communication, a section with that name should be configured in ''ysigchan.conf''<br /> host=0.0.0.0 -- address on which to listen for incoming applications<br /> port=16101 -- port on which to listen for incoming applications<br /> type=CAMEL -- type of translator (MAP/CAMEL). For the intended case, CAMEL should be set<br /> print-messages=true -- whether or not to print TCAP and XML messages in the logs<br /> add-encoding=false -- whether to add encoding attribute to data translated to XML<br /> <br /> <br /> For functionality through Yate messages, an additional section, named @@[local appName]@@ should be configured:<br /> <br /> [local camelLocal] - what comes after ''local'' will be the name of the application<br /> ;enable=no -- enable this application<br /> translator=camel - which translator should be used. A section named [tcap translatorValue] should be present in the config file.<br /> capabilities=Camel - capabilities supported by this application. CAMEL translator have only one capability and that is ''Camel''.<br /> export_xml_as=both - how to export the XML part: string, object or both?<br /> <br /> '''Note:'''<br /> * setting port to 0 will disable the support for TCP applications<br /> * the name of the local application should match the name set in ''$appName'' for the script<br /> <br /> ==Behaviour==<br /> <br /> ===Script behaviour===<br /> <br /> This is a global script that awaits dialog beginnings from SSFs and it is able to handle CAMEL phases 2, 3 and 4.<br /> The phase used for handling the call will be determined using the information provided in the InitialDP operation using the following rules:<br /> * first, an application context check will be done. As seeing that every phase has a different context assigned, phase will be first determined at this stage.<br /> * if the application context determined a phase 4 handling, in the handling of the InitialDP operation these additional checks will be made:<br /> ** the value for ''supportedCamelPhases'' will be checked. In this parameter, the MSC advertises the CAMEL phases that it can handle. From that list, the SCP will choose the highest phase advertised.<br /> ** the value for ''offeredCamel4Functionalities'' will be checked. SCP will verify that all the CAMEL 4 functionalities required for doing CRBT handling in phase 4 are supported. If that is not so, the SCP will downgrade the phase to phase 2 as seeing that the presence of this parameter implied phase 4 functionality and phase 4 functionality implies, by convention, prior phases support also.<br /> <br /> In case of phase 1 detection, the SCP will end the dialogue either with an Abort with application-context-not-supported, either with a Continue operation for CAMEL.<br /> <br /> An configuration parameter was added (''$maxPhase'') - mainly for testing purposes - in order to limit what phase the SCP will accept.<br /> <br /> <br /> Bellow there is detailed description of how the script will act in different scenarios.<br /> <br /> ====Behaviour CAMEL phase 4====<br /> <br /> <br /> =====Normal procedure for dialogue=====<br /> <br /> In case of a normal, error free dialogue, things will proceed according to the describing flow below:<br /> <br /> SSF SCP<br /> 1. --------------------- IDP(serviceKey,termAttemptAuth) --------------------------------><br /> 2. <-------------------- RRBE (tAbandon,leg1) --------------------------------------------<br /> 3. <-------------------- DL (leg2) -------------------------------------------------------<br /> 4. --------------------- DL Result ------------------------------------------------------><br /> 5. <-------------------- ICA (CS2,leg3) --------------------------------------------------<br /> 6. --------------------- ICA Result -----------------------------------------------------><br /> 7. <-------------------- RRBE (oTermSeized,oBusy,oAnswer,oNoAnswer,routeFailure,leg3) ----<br /> 8. <-------------------- CWA (leg3)-------------------------------------------------------<br /> 9. --------------------- ERBE (oTermSeized,leg3) ----------------------------------------><br /> 10. <-------------------- CWA (leg3) ------------------------------------------------------<br /> 11. <-------------------- ETC (CS1) -------------------------------------------------------<br /> 12. --------------------- ERBE (oAnswer,leg3) --------------------------------------------><br /> 13. <-------------------- DFCWA (CS1) -----------------------------------------------------<br /> 14. <-------------------- ML (leg3) -------------------------------------------------------<br /> 15. --------------------- ML Result ------------------------------------------------------><br /> 16. <-------------------- CWA (leg3) ------------------------------------------------------<br /> 17. <-------------------- CWA (CS1) -------------------------------------------------------<br /> <br /> In case of busy received from the called party, the call flow is:<br /> <br /> 1. --------------- ERBE (oCalledPartyBusy, leg3, cause) ----------------------><br /> 2. <-------------- RC (cause received in ERBE/Busy) --------------------------<br /> <br /> =====Abnormal procedures=====<br /> <br /> The following schematics will describe the behaviour of the script in certain scenarios. <br /> 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.<br /> <br /> ======Initial DP ServiceKey mismatch / DP mismatch======<br /> <br /> <br /> SSF SCP<br /> --------------------- IDP(serviceKey,oTermAttemptAuth) -------------------------------><br /> <-------------------- ReturnError(unexpectedDataValue) --------------------------------<br /> <br /> ======Initial DP missing parameters======<br /> <br /> <br /> SSF SCP<br /> --------------------- IDP(serviceKey,oTermAttemptAuth) -------------------------------><br /> <-------------------- ReturnError(missingParameter) -----------------------------------<br /> <br /> ======1.2.3 Application context mismatch======<br /> <br /> <br /> SSF SCP<br /> --------------------- IDP(serviceKey,oTermAttemptAuth) -------------------------------><br /> <-------------------- U_Abort (user-application-context-name-not-supported) -----------<br /> <br /> ======Receiving an unsupported CAMEL phase======<br /> <br /> 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:<br /> <br /> SSF SCP<br /> 1. --------------------- IDP(serviceKey,oTermAttemptAuth) -------------------------------><br /> <-------------------- Continue --------------------------------------------------------<br /> <br /> SSF SCP<br /> 6. --------------------- ICA Result -----------------------------------------------------><br /> <-------------------- ReleaseCall -----------------------------------------------------<br /> <br /> <br /> ======1.2.5 Errors received from SSF / Timeout detected for class 1 and 3 operations======<br /> <br /> 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.<br /> <br /> SSF SCP<br /> SCP can be in either of the states : 1 / 2 / 3 <br /> <-------------------- Continue --------------------------------------------------------<br /> <br /> <br /> SSF SCP<br /> SCP can be in either of the states : 4 / 5 / 13/ 14 <br /> <-------------------- ReleaseCall --------------------------------------------------------<br /> <br /> <br /> SSF SCP<br /> SCP can be in either of the states : 6 - 11 <br /> 14. <-------------------- MoveLeg --------------------------------------------------------<br /> <br /> <br /> ===Behaviour CAMEL phase 2/3===<br /> <br /> ====Normal procedure for dialogue====<br /> <br /> <br /> The following diagrams will detail the operation of the CRBT script in case of normal, error free phase 2/3 handling.<br /> <br /> <br /> SSF SCP<br /> 1. -------------------------- IDP (serviceKey, termAttemptAuth) ---------------------------><br /> 2. <------ RRBE (leg1,tAbandon) & (leg2,tBusy,tAnswer,tNoAnswer)----------------------------<br /> 3. <------------------------- ETC ----------------------------------------------------------<br /> 4. <------------------------- CONT ---------------------------------------------------------<br /> 5. -------------------------- ERBE (leg2,tAnswer) ------------------------------------------<br /> 6. <------------------------- DFC ----------------------------------------------------------<br /> 7. <------------------------- CONT ---------------------------------------------------------<br /> <br /> ====Abnormal procedures====<br /> <br /> <br /> Situations described in sections 1.2.1 - 1.2.4 shall also apply here.<br /> <br /> ====Errors received from SSF====<br /> <br /> <br /> SSF SCP<br /> SCP can be in either of the states : 2 / 3 <br /> <-------------------- Continue --------------------------------------------------------</div>

Monica https://ss7api.null.ro/index.php/CRBT_logic CRBT logic 2013-10-28T10:26:20Z

<p>Monica: Created page with "The crbt_scp.php is an implementation for a CAMEL gsmSCP application which provides a Colourful Ring Back Tone service by interfacing with a CAMEL gsmSSF. Upon service invoca..."</p> <hr /> <div>The crbt_scp.php is an implementation for a CAMEL gsmSCP application which provides a Colourful Ring Back Tone service by interfacing with a CAMEL gsmSSF.<br /> <br /> Upon service invocation, this script implements the required actions in order to instruct the gsmSSF to provide the required ringback tone.<br /> <br /> ==Configuration==<br /> <br /> ===Script side===<br /> <br /> The CRBT script supports two ways of communicating with Yate:<br /> # One based on the XML protocol, communication being realized through a TCP socket.<br /> # The other one based done through Yate messages, using ''extmodule''.<br /> The way which the script will use is chosen according to configuration - in particular, through the ''$ioType'' setting.<br /> <br /> <br /> Configuration of this script is done through ''config.php''. This allows setting the following parameters:<br /> <br /> * 1. '''$appName'''- value of the ''application'' parameters set in the ''camel.message''. This value is used to check that the message is indeed intented for this script.<br /> <br /> * 2. '''$ioType''' - type of I/O to use to communicate with Yate. The script recognizes these two values:<br /> ** ''TCP'' - use the configured TCP socket to communicate with Yate.<br /> ** ''MSG'' - use messages through exmodule protocol for communication.<br /> <br /> * 3. '''$host''','''$port''' - host and port where the application should connect to in order to communicate with Yate if ''$ioType'' is set to ''TCP''.<br /> '<br /> * 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.<br /> <br /> * 5. '''$findMelodyID''' - boolean. It specifies whether the gsmSCF should take the necessary steps in order to find out the required ringtone for the called user. Its default value is false, meaning that the gsmSCF will assume that all requests reaching it are requests for subscribers which have the service activated<br /> <br /> * 6. '''$httpRequest''' - string. It's the HTTP request to be made in order to find out the ringtone associated with the user.<br /> <br /> * 7. '''$myServiceKey''' - integer. The ID of the service provided by this gsmSCF application and which should come in IDP in order to accept the request.<br /> <br /> * 8. '''$myDP''' - string. The DP for which this SCP should be triggered and which should come in IDP in order to accept the request.<br /> <br /> * 9. '''$sendAll''' - bool. If true, it will send all response components batched in a single TCAP message, otherwise it will send them each with its own TCAP message. It is set by default to true.<br /> <br /> * 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:<br /> ** ''prefix_called'' - build the gsmSRF address following this rule @@$srfNumber.$srfSeparator.$correlationID.$srfSeparator.$sfcID@@.<br /> ** ''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.<br /> <br /> When instructing the SSF to establish a temporary connection to a SRF through an ETC operation, the SCF must provide addressing information to the SSF in regards to the SRF. This information requires:<br /> * the address of the SRF - a routable number<br /> * a correlation ID - that can mean whatever the operators want, but that, according to specification, can be used by the SRF if/when contacting the SCF in order to associate the SSF -> SCF dialogue with the SRF ->SCF dialogue.<br /> * a scfID - an ID for the contacting SCF. This could be used by the SRF to know where to contact the SCF.<br /> <br /> The script provides this information in an ETC operation in 2 ways:<br /> * providing all the above information in the assistingSSPIPAddress. This is done by concatenating the SRF number, correlation ID and scfID -according to an agreement between the SSF and SCF operators. The script simply concatenates these parameters, putting between them the configured separator.<br /> * providing the information in 3 separated parameters:<br /> ** assistingSSPIPAddress - the SRF Number<br /> ** correlationID - the script will set this parameter to either the melody ID or the called party number, encoded in hexified BCD form.<br /> ** scfID - the script will set this parameter to the hexified BCD form of the SCP's GT number.<br /> <br /> Listed bellow are the parameters that need to be configured for the gsmSRF number:<br /> <br /> * '''$srfNumber''' - string. It specifies a number at which the gsmSRF is found.<br /> <br /> * '''$srfSeparator''' - string. Digit(s) used as separator between SRF number, correlationID and sfcID when the assistingSSPIPAddress contains all of them.<br /> <br /> * '''$srfNumber_qualifier''' - string. It specifies the GenericNumber qualifier. It can be one of the following values:<br /> ** ''dialed-digits''<br /> ** ''called-additional''<br /> ** ''caller-failed''<br /> ** ''caller-not-screened''<br /> ** ''terminating''<br /> ** ''connected-additional''<br /> ** ''caller-additional''<br /> ** ''called-original''<br /> ** ''redirecting''<br /> ** ''redirection''<br /> <br /> * '''$srfNumber_complete''' - boolean. It specifies whether the called number is complete or not. It should be complete.<br /> <br /> * '''$srfNumber_nature''' - string. Nature of number. It can have one of the following values:<br /> ** ''unknown''<br /> ** ''international''<br /> ** ''national''<br /> ** ''network-specific''<br /> ** ''subscriber''<br /> ** ''reserved''<br /> ** ''abbreviated''<br /> ** ''extension-reserved''<br /> <br /> * '''$srfNumber_plan''' - string. It's the used numbering plan. It can have one of the following values:<br /> ** ''unknown''<br /> ** ''isdn''<br /> ** ''data''<br /> ** ''telex''<br /> ** ''land-mobile''<br /> ** ''isdn-mobile''<br /> ** ''national''<br /> ** ''private''<br /> ** ''extension-reserved''<br /> <br /> * '''$srfNumber_restrict''' - string. It specifies the presentation of the number. Possible values are:<br /> ** ''allowed''<br /> ** ''restricted''<br /> ** ''unavailable''<br /> ** ''no''<br /> ** ''false''<br /> ** ''yes''<br /> ** ''true''<br /> <br /> * '''$srfNumber_screened''' - string. It specifies the screening indicator for the number. Possible values are:<br /> ** ''user-provided''<br /> ** ''user-provided-passed''<br /> ** ''user-provided-failed''<br /> ** ''network-provided''<br /> ** ''no''<br /> ** ''false''<br /> ** ''yes''<br /> ** ''true''<br /> <br /> <br /> * 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.<br /> <br /> * 12. '''$maxPhase''' - integer.Represents the maximum CAMEL phase allowed for CAMEL interaction. If not set, it will default to 4, meaning that all supported CAMEL phases are allowed.<br /> <br /> * 13. '''$msStateNotAllowed''' - array. List of states received for the subscriber in IDP for which the SCP will abandon CRBT handling and will continue with the call. Recognized values are:<br /> ** ''assumedIdle''<br /> ** ''camelBusy''<br /> ** ''netDetNotReachable''<br /> ** ''notProvidedFromVLR''<br /> It has no default, meaning that it will do CRBT handling ignoring the subscriber state.<br /> <br /> * 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.<br /> <br /> <br /> * 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.<br /> <br /> '''Note''' - The following parameters need not be set usually:<br /> * ''$host'', ''$port'' - set only if you intend to use TCP communication.<br /> * ''$transTimeout''<br /> * ''$sendAll''<br /> * ''$shortTimer'', ''$mediumTimer'', ''$longTimer''<br /> * ''$maxPhase''<br /> * ''$msStateNotAllowed''<br /> * ''$prearrangedEndOn'' - if there is no prearranged end agreement between operator, this doesn't need to be configured.<br /> <br /> * 16. '''$mynum''' - string. GTT number assigned to this SCP.<br /> <br /> <br /> ===Yate side===<br /> <br /> On the Yate side, the ''camel_map'' module must be configured through ''camel_map.conf''. <br /> <br /> For functionality provided through a TCP socket, a @@[tcap name]@@ section should be configured. A section looks like this:<br /> <br /> [tcap camel] -- what comes after ''tcap'' will be the name of the translator<br /> ;enable=no -- enable this translator<br /> tcap=tcap-test-itu -- TCAP to be used by the translator for SS7 network communication, a section with that name should be configured in ''ysigchan.conf''<br /> host=0.0.0.0 -- address on which to listen for incoming applications<br /> port=16101 -- port on which to listen for incoming applications<br /> type=CAMEL -- type of translator (MAP/CAMEL). For the intended case, CAMEL should be set<br /> print-messages=true -- whether or not to print TCAP and XML messages in the logs<br /> add-encoding=false -- whether to add encoding attribute to data translated to XML<br /> <br /> <br /> For functionality through Yate messages, an additional section, named @@[local appName]@@ should be configured:<br /> <br /> [local camelLocal] - what comes after ''local'' will be the name of the application<br /> ;enable=no -- enable this application<br /> translator=camel - which translator should be used. A section named [tcap translatorValue] should be present in the config file.<br /> capabilities=Camel - capabilities supported by this application. CAMEL translator have only one capability and that is ''Camel''.<br /> export_xml_as=both - how to export the XML part: string, object or both?<br /> <br /> '''Note:'''<br /> * setting port to 0 will disable the support for TCP applications<br /> * the name of the local application should match the name set in ''$appName'' for the script</div>

Monica https://ss7api.null.ro/index.php/Main_Page Main Page 2013-09-02T12:40:34Z

<p>Monica: </p> <hr /> <div><br /> ==YATE's TCAP XML Interface==<br /> <br /> Note! I believe this page should hold a guide on what this website offers, not technical info as it currently does.<br /> <br /> The purpose of this document is to describe the XML based protocol used to implement communication between TCAP and the application servers for mobile services.<br /> <br /> <br /> MAP (Mobile Application Part) and CAMEL (Customized Application of Mobile Enhanced Logic) are SS7 protocols used for authentication, registration, messaging, call control and billing in mobile networks. Both protocols are based on TCAP (Transaction Capabilities Application Part) which is a transaction oriented protocol.<br /> <br /> <br /> This protocol aims to map the structure of MAP and CAMEL messages and messageless TCAP primitives on XML messages as transparently as possible. However, some concepts of the TCAP layer will reflect in the message flow and in some of the parameters.<br /> <br /> <br /> Each communication between two network elements happens inside a dialog created by the first message. Multiple components can exist inside the dialog, each with its own direction and timing. The dialog is ended normally when the last component finished exchanging data. The correlation of simultaneously happening dialogs and components is done using unique identifiers. Dialogs hold a local ID and a remote ID. Each such ID must be unique per communication endpoint.<br /> <br /> <br /> Components also hold an ID inside the dialog. Each such ID must be unique per component and direction. It is important to note that same numeric ID may be used for components invoked from the opposing sides of the connection.<br /> <br /> <br /> The following picture shows a transaction with two components: <br /> <br /> [[File:tcap_transaction.png]]</div>

Monica https://ss7api.null.ro/index.php/Introduction Introduction 2013-09-02T12:39:06Z

<p>Monica: </p> <hr /> <div>{{DISPLAYTITLE:Introduction}}<br /> <br /> The purpose of this document is to describe the XML based protocol used to implement communication between TCAP and the application servers for mobile services.<br /> <br /> <br /> MAP (Mobile Application Part) and CAMEL (Customized Application of Mobile Enhanced Logic) are SS7 protocols used for authentication, registration, messaging, call control and billing in mobile networks. Both protocols are based on TCAP (Transaction Capabilities Application Part) which is a transaction oriented protocol.<br /> <br /> <br /> This protocol aims to map the structure of MAP and CAMEL messages and messageless TCAP primitives on XML messages as transparently as possible. However, some concepts of the TCAP layer will reflect in the message flow and in some of the parameters.<br /> <br /> <br /> Each communication between two network elements happens inside a dialog created by the first message. Multiple components can exist inside the dialog, each with its own direction and timing. The dialog is ended normally when the last component finished exchanging data. The correlation of simultaneously happening dialogs and components is done using unique identifiers. Dialogs hold a local ID and a remote ID. Each such ID must be unique per communication endpoint.<br /> <br /> <br /> Components also hold an ID inside the dialog. Each such ID must be unique per component and direction. It is important to note that same numeric ID may be used for components invoked from the opposing sides of the connection.<br /> <br /> <br /> The following picture shows a transaction with two components: <br /> <br /> [[File:tcap_transaction.png]]</div>

Monica https://ss7api.null.ro/index.php/Introduction Introduction 2013-09-02T12:38:25Z

<p>Monica: </p> <hr /> <div>{{DISPLAYTITLE:Introduction - YATE's TCAP XML Interface}}<br /> <br /> The purpose of this document is to describe the XML based protocol used to implement communication between TCAP and the application servers for mobile services.<br /> <br /> <br /> MAP (Mobile Application Part) and CAMEL (Customized Application of Mobile Enhanced Logic) are SS7 protocols used for authentication, registration, messaging, call control and billing in mobile networks. Both protocols are based on TCAP (Transaction Capabilities Application Part) which is a transaction oriented protocol.<br /> <br /> <br /> This protocol aims to map the structure of MAP and CAMEL messages and messageless TCAP primitives on XML messages as transparently as possible. However, some concepts of the TCAP layer will reflect in the message flow and in some of the parameters.<br /> <br /> <br /> Each communication between two network elements happens inside a dialog created by the first message. Multiple components can exist inside the dialog, each with its own direction and timing. The dialog is ended normally when the last component finished exchanging data. The correlation of simultaneously happening dialogs and components is done using unique identifiers. Dialogs hold a local ID and a remote ID. Each such ID must be unique per communication endpoint.<br /> <br /> <br /> Components also hold an ID inside the dialog. Each such ID must be unique per component and direction. It is important to note that same numeric ID may be used for components invoked from the opposing sides of the connection.<br /> <br /> <br /> The following picture shows a transaction with two components: <br /> <br /> [[File:tcap_transaction.png]]</div>

Monica https://ss7api.null.ro/index.php/Error_codes Error codes 2013-09-02T12:36:30Z

<p>Monica: /* Error Codes - CAMEL */</p> <hr /> <div>Contents:<br /> #[[#Error codes - GSM MAP|Error codes - GSM MAP]]<br /> #[[#Error codes - CAMEL|Error codes - CAMEL]]<br /> <br /> ==Error codes - GSM MAP==<br /> <br /> Unless a dash appears in the optional parameters an extensionContainer can be added to an error.<br /> <br /> {| class="wikitable" style="text-align: left; color: green;"<br /> |Name<br /> |Code<br /> |Optional parameters<br /> |-<br /> |unknownSubscriber<br /> |1<br /> |unknownSubscriberDiagnostic<br /> |-<br /> |unknownMSC<br /> |3<br /> |– <br /> |-<br /> |absentsubscriberSM<br /> |6<br /> |absentSubscriberDiagnosticSM, additionalAbsentSubscriberDiagnosticSM<br /> |-<br /> |unknownEquipment<br /> |7<br /> |–<br /> |-<br /> |roamingNotAllowed<br /> |8<br /> |additionalRoamingNotAllowedCause<br /> |-<br /> |illegalSubscriber<br /> |9<br /> |<br /> |-<br /> |bearerServiceNotProvisioned<br /> |10<br /> | <br /> |-<br /> |teleserviceNotProvisioned<br /> |11<br /> |<br /> |- <br /> |illegalEquipment<br /> |12<br /> | <br /> |-<br /> |callBarred<br /> |13<br /> |'''Mandatory: callBarringCause''', unauthorisedMessageOriginator<br /> |-<br /> |cug-Reject<br /> |15<br /> |cug-RejectCause<br /> |-<br /> |illegalSS-Operation<br /> |16<br /> | <br /> |-<br /> |ss-ErrorStatus<br /> |17<br /> |–<br /> |-<br /> |ss-NotAvailable<br /> |18<br /> | <br /> |-<br /> |ss-SubscriptionViolation<br /> |19<br /> |<br /> |- <br /> |ss-Incompatibility<br /> |20<br /> |ss-Code, basicService, ss-Status<br /> |-<br /> |facilityNotSupported<br /> |21<br /> |shapeOfLocationEstimateNotSupported, neededLcsCapabilityNotSupportedInServingNode<br /> |-<br /> |absentSubscriber<br /> |27<br /> |absentSubscriberReason<br /> |-<br /> |subscriberBusyForMT-SMS<br /> |31<br /> |gprsConnectionSuspended<br /> |-<br /> |sm-DeliveryFailure<br /> |32<br /> |'''Mandatory: sm-EnumeratedDeliveryFailureCause''', diagnosticInfo<br /> |-<br /> |messageWaitingListFull<br /> |33<br /> | <br /> |-<br /> |pw-RegistrationFailure <br /> |37<br /> |'''Mandatory: reason value'''<br /> |-<br /> |negativePW-Check<br /> |38<br /> |–<br /> |-<br /> |noRoamingNumberAvailable<br /> |39<br /> | <br /> |-<br /> |tracingBufferFull<br /> |40<br /> | <br /> |-<br /> |busySubscriber <br /> |45<br /> |ccbs-Possible, ccbs-Busy<br /> |-<br /> |noSubscriberReply<br /> |46<br /> | <br /> |-<br /> |unauthorizedRequestingNetwork<br /> |52<br /> |<br /> |}<br /> <br /> ==Error codes - CAMEL==<br /> Unless a dash appears in the optional parameters an extensionContainer can be added to an error.<br /> <br /> {| class="wikitable" style="text-align: left; color: green;"<br /> |Name<br /> |Code<br /> |Optional parameters<br /> |-<br /> |cancelled<br /> |0<br /> |–<br /> |-<br /> |cancelFailed<br /> |1<br /> | <br /> |-<br /> |eTCFailed<br /> |3<br /> |–<br /> |-<br /> |improperCallerResponse<br /> |4<br /> |–<br /> |-<br /> |missingCustomerRecord<br /> |6<br /> |–<br /> |-<br /> |missingParameter<br /> |7<br /> |–<br /> |-<br /> |parameterOutOfRange<br /> |8<br /> |–<br /> |-<br /> |requestedInfoError<br /> |10<br /> | <br /> |-<br /> |systemFailure<br /> |11<br /> | <br /> |-<br /> |taskRefused<br /> |12<br /> | <br /> |-<br /> |unavailableResource<br /> |13<br /> |–<br /> |-<br /> |unexpectedComponentSequence<br /> |14<br /> |–<br /> |-<br /> |unexpectedData<br /> |15<br /> |–<br /> |-<br /> |unexpectedParameter<br /> |16<br /> |–<br /> |-<br /> |unknownLegID<br /> |17<br /> |–<br /> |}</div>

Monica https://ss7api.null.ro/index.php/Error_codes Error codes 2013-09-02T12:36:17Z

<p>Monica: </p> <hr /> <div>Contents:<br /> #[[#Error codes - GSM MAP|Error codes - GSM MAP]]<br /> #[[#Error codes - CAMEL|Error codes - CAMEL]]<br /> <br /> ==Error codes - GSM MAP==<br /> <br /> Unless a dash appears in the optional parameters an extensionContainer can be added to an error.<br /> <br /> {| class="wikitable" style="text-align: left; color: green;"<br /> |Name<br /> |Code<br /> |Optional parameters<br /> |-<br /> |unknownSubscriber<br /> |1<br /> |unknownSubscriberDiagnostic<br /> |-<br /> |unknownMSC<br /> |3<br /> |– <br /> |-<br /> |absentsubscriberSM<br /> |6<br /> |absentSubscriberDiagnosticSM, additionalAbsentSubscriberDiagnosticSM<br /> |-<br /> |unknownEquipment<br /> |7<br /> |–<br /> |-<br /> |roamingNotAllowed<br /> |8<br /> |additionalRoamingNotAllowedCause<br /> |-<br /> |illegalSubscriber<br /> |9<br /> |<br /> |-<br /> |bearerServiceNotProvisioned<br /> |10<br /> | <br /> |-<br /> |teleserviceNotProvisioned<br /> |11<br /> |<br /> |- <br /> |illegalEquipment<br /> |12<br /> | <br /> |-<br /> |callBarred<br /> |13<br /> |'''Mandatory: callBarringCause''', unauthorisedMessageOriginator<br /> |-<br /> |cug-Reject<br /> |15<br /> |cug-RejectCause<br /> |-<br /> |illegalSS-Operation<br /> |16<br /> | <br /> |-<br /> |ss-ErrorStatus<br /> |17<br /> |–<br /> |-<br /> |ss-NotAvailable<br /> |18<br /> | <br /> |-<br /> |ss-SubscriptionViolation<br /> |19<br /> |<br /> |- <br /> |ss-Incompatibility<br /> |20<br /> |ss-Code, basicService, ss-Status<br /> |-<br /> |facilityNotSupported<br /> |21<br /> |shapeOfLocationEstimateNotSupported, neededLcsCapabilityNotSupportedInServingNode<br /> |-<br /> |absentSubscriber<br /> |27<br /> |absentSubscriberReason<br /> |-<br /> |subscriberBusyForMT-SMS<br /> |31<br /> |gprsConnectionSuspended<br /> |-<br /> |sm-DeliveryFailure<br /> |32<br /> |'''Mandatory: sm-EnumeratedDeliveryFailureCause''', diagnosticInfo<br /> |-<br /> |messageWaitingListFull<br /> |33<br /> | <br /> |-<br /> |pw-RegistrationFailure <br /> |37<br /> |'''Mandatory: reason value'''<br /> |-<br /> |negativePW-Check<br /> |38<br /> |–<br /> |-<br /> |noRoamingNumberAvailable<br /> |39<br /> | <br /> |-<br /> |tracingBufferFull<br /> |40<br /> | <br /> |-<br /> |busySubscriber <br /> |45<br /> |ccbs-Possible, ccbs-Busy<br /> |-<br /> |noSubscriberReply<br /> |46<br /> | <br /> |-<br /> |unauthorizedRequestingNetwork<br /> |52<br /> |<br /> |}<br /> <br /> ==Error Codes - CAMEL==<br /> Unless a dash appears in the optional parameters an extensionContainer can be added to an error.<br /> <br /> {| class="wikitable" style="text-align: left; color: green;"<br /> |Name<br /> |Code<br /> |Optional parameters<br /> |-<br /> |cancelled<br /> |0<br /> |–<br /> |-<br /> |cancelFailed<br /> |1<br /> | <br /> |-<br /> |eTCFailed<br /> |3<br /> |–<br /> |-<br /> |improperCallerResponse<br /> |4<br /> |–<br /> |-<br /> |missingCustomerRecord<br /> |6<br /> |–<br /> |-<br /> |missingParameter<br /> |7<br /> |–<br /> |-<br /> |parameterOutOfRange<br /> |8<br /> |–<br /> |-<br /> |requestedInfoError<br /> |10<br /> | <br /> |-<br /> |systemFailure<br /> |11<br /> | <br /> |-<br /> |taskRefused<br /> |12<br /> | <br /> |-<br /> |unavailableResource<br /> |13<br /> |–<br /> |-<br /> |unexpectedComponentSequence<br /> |14<br /> |–<br /> |-<br /> |unexpectedData<br /> |15<br /> |–<br /> |-<br /> |unexpectedParameter<br /> |16<br /> |–<br /> |-<br /> |unknownLegID<br /> |17<br /> |–<br /> |}</div>

Monica https://ss7api.null.ro/index.php/Error_codes Error codes 2013-09-02T12:32:40Z

<p>Monica: </p> <hr /> <div>Contents:<br /> #[[#Error codes - GSM MAP|Error codes - GSM MAP]]<br /> #[[#Error codes - CAMEL|Error codes - CAMEL]]<br /> <br /> ==Error Codes - GSM MAP==<br /> <br /> Unless a dash appears in the optional parameters an extensionContainer can be added to an error.<br /> <br /> {| class="wikitable" style="text-align: left; color: green;"<br /> |Name<br /> |Code<br /> |Optional parameters<br /> |-<br /> |unknownSubscriber<br /> |1<br /> |unknownSubscriberDiagnostic<br /> |-<br /> |unknownMSC<br /> |3<br /> |– <br /> |-<br /> |absentsubscriberSM<br /> |6<br /> |absentSubscriberDiagnosticSM, additionalAbsentSubscriberDiagnosticSM<br /> |-<br /> |unknownEquipment<br /> |7<br /> |–<br /> |-<br /> |roamingNotAllowed<br /> |8<br /> |additionalRoamingNotAllowedCause<br /> |-<br /> |illegalSubscriber<br /> |9<br /> |<br /> |-<br /> |bearerServiceNotProvisioned<br /> |10<br /> | <br /> |-<br /> |teleserviceNotProvisioned<br /> |11<br /> |<br /> |- <br /> |illegalEquipment<br /> |12<br /> | <br /> |-<br /> |callBarred<br /> |13<br /> |'''Mandatory: callBarringCause''', unauthorisedMessageOriginator<br /> |-<br /> |cug-Reject<br /> |15<br /> |cug-RejectCause<br /> |-<br /> |illegalSS-Operation<br /> |16<br /> | <br /> |-<br /> |ss-ErrorStatus<br /> |17<br /> |–<br /> |-<br /> |ss-NotAvailable<br /> |18<br /> | <br /> |-<br /> |ss-SubscriptionViolation<br /> |19<br /> |<br /> |- <br /> |ss-Incompatibility<br /> |20<br /> |ss-Code, basicService, ss-Status<br /> |-<br /> |facilityNotSupported<br /> |21<br /> |shapeOfLocationEstimateNotSupported, neededLcsCapabilityNotSupportedInServingNode<br /> |-<br /> |absentSubscriber<br /> |27<br /> |absentSubscriberReason<br /> |-<br /> |subscriberBusyForMT-SMS<br /> |31<br /> |gprsConnectionSuspended<br /> |-<br /> |sm-DeliveryFailure<br /> |32<br /> |'''Mandatory: sm-EnumeratedDeliveryFailureCause''', diagnosticInfo<br /> |-<br /> |messageWaitingListFull<br /> |33<br /> | <br /> |-<br /> |pw-RegistrationFailure <br /> |37<br /> |'''Mandatory: reason value'''<br /> |-<br /> |negativePW-Check<br /> |38<br /> |–<br /> |-<br /> |noRoamingNumberAvailable<br /> |39<br /> | <br /> |-<br /> |tracingBufferFull<br /> |40<br /> | <br /> |-<br /> |busySubscriber <br /> |45<br /> |ccbs-Possible, ccbs-Busy<br /> |-<br /> |noSubscriberReply<br /> |46<br /> | <br /> |-<br /> |unauthorizedRequestingNetwork<br /> |52<br /> |<br /> |}<br /> <br /> ==Error Codes - CAMEL==<br /> Unless a dash appears in the optional parameters an extensionContainer can be added to an error.<br /> <br /> {| class="wikitable" style="text-align: left; color: green;"<br /> |Name<br /> |Code<br /> |Optional parameters<br /> |-<br /> |cancelled<br /> |0<br /> |–<br /> |-<br /> |cancelFailed<br /> |1<br /> | <br /> |-<br /> |eTCFailed<br /> |3<br /> |–<br /> |-<br /> |improperCallerResponse<br /> |4<br /> |–<br /> |-<br /> |missingCustomerRecord<br /> |6<br /> |–<br /> |-<br /> |missingParameter<br /> |7<br /> |–<br /> |-<br /> |parameterOutOfRange<br /> |8<br /> |–<br /> |-<br /> |requestedInfoError<br /> |10<br /> | <br /> |-<br /> |systemFailure<br /> |11<br /> | <br /> |-<br /> |taskRefused<br /> |12<br /> | <br /> |-<br /> |unavailableResource<br /> |13<br /> |–<br /> |-<br /> |unexpectedComponentSequence<br /> |14<br /> |–<br /> |-<br /> |unexpectedData<br /> |15<br /> |–<br /> |-<br /> |unexpectedParameter<br /> |16<br /> |–<br /> |-<br /> |unknownLegID<br /> |17<br /> |–<br /> |}</div>

Monica https://ss7api.null.ro/index.php/Operation_codes Operation codes 2013-09-02T12:31:45Z

<p>Monica: </p> <hr /> <div>Contents:<br /> #[[#Operation codes - GSM MAP|Operation codes - GSM MAP]]<br /> #[[#Operation codes - CAMEL|Operation codes - CAMEL]]<br /> <br /> ==Operation codes - GSM MAP==<br /> {| class="wikitable" style="text-align: left; color: green;"<br /> |Name<br /> |Code<br /> |Impl.<br /> |Notes<br /> |-<br /> |updateLocation<br /> |2<br /> |<br /> |<br /> |-<br /> |cancelLocation<br /> |3<br /> |<br /> |<br /> |- <br /> |provideRoamingNumber<br /> |4<br /> |<br /> |<br /> |-<br /> |insertSubscriberData<br /> |7<br /> |<br /> |<br /> |-<br /> |deleteSubscriberData<br /> |8<br /> |<br /> |<br /> |-<br /> |registerSS<br /> |10<br /> |<br /> |<br /> |-<br /> |eraseSS<br /> |11<br /> |<br /> |<br /> |-<br /> |activateSS<br /> |12<br /> |<br /> |<br /> |-<br /> |deactivateSS<br /> |13<br /> |<br /> |<br /> |-<br /> |interrogateSS<br /> |14<br /> |<br /> |<br /> |-<br /> |authenticationFailureReport<br /> |15<br /> |<br /> |<br /> |-<br /> |registerPassword<br /> |17<br /> |<br /> |<br /> |-<br /> |getPassword<br /> |18<br /> |<br /> |<br /> |- <br /> |updateGprsLocation<br /> |23<br /> |<br /> |<br /> |-<br /> |sendRoutingInfoForGprs<br /> |24<br /> |<br /> |<br /> |-<br /> |failureReport<br /> |25<br /> |<br /> |<br /> |-<br /> |reset<br /> |37<br /> |<br /> |<br /> |-<br /> |forwardCheckSS-Indication<br /> |38<br /> |<br /> |<br /> |-<br /> |mt-forwardSM<br /> |44<br /> |<br /> |<br /> |-<br /> |sendRoutingInfoForSM<br /> |45<br /> |<br /> |<br /> |- <br /> |mo-forwardSM<br /> |46<br /> |<br /> |<br /> |-<br /> |reportSM-DeliveryStatus<br /> |47<br /> |<br /> |<br /> |-<br /> |activateTracemMode<br /> |50<br /> |<br /> |<br /> |-<br /> |deactivateTraceMode<br /> |51<br /> |<br /> |<br /> |- <br /> |sendAuthenticationInfo<br /> |56<br /> |<br /> |<br /> |-<br /> |restoreData<br /> |57<br /> |<br /> |<br /> |-<br /> |sendIMSI<br /> |58<br /> |<br /> |<br /> |-<br /> |processUnstructuredSS-Request<br /> |59<br /> |<br /> |<br /> |-<br /> |unstructuredSS-Request<br /> |60<br /> |<br /> |<br /> |-<br /> |unstructuredSS-Notify<br /> |61<br /> |<br /> |<br /> |-<br /> |informServiceCentre<br /> |63<br /> |<br /> |<br /> |- <br /> |alertServiceCentre<br /> |64<br /> |<br /> |<br /> |-<br /> |readyForSM<br /> |66<br /> |<br /> |<br /> |- <br /> |purgeMS<br /> |67<br /> |<br /> |<br /> |- <br /> |provideSubscriberInfo<br /> |70<br /> |<br /> |<br /> |-<br /> |anyTimeInterrogation<br /> |71<br /> |<br /> |<br /> |- <br /> |setReportingState<br /> |73<br /> |<br /> |<br /> |- <br /> |statusReport<br /> |74<br /> |<br /> |<br /> |- <br /> |sendRoutingInfoForLCS<br /> |85<br /> |<br /> |<br /> |- <br /> |}<br /> <br /> ==Operation codes - CAMEL==<br /> <br /> {| class="wikitable" style="text-align: left; color: green;"<br /> |Name<br /> |Code<br /> |Impl.<br /> |Notes<br /> |-<br /> |initialDP<br /> |0<br /> |<br /> |<br /> |-<br /> |assistRequestInstructions<br /> |16<br /> |<br /> |<br /> |-<br /> |establishTemporaryConnection<br /> |17<br /> |<br /> |<br /> |-<br /> |disconnectForwardConnection<br /> |18<br /> |<br /> |<br /> |- <br /> |connectToResource<br /> |19<br /> |<br /> |<br /> |- <br /> |connect<br /> |20<br /> |<br /> |<br /> |- <br /> |releaseCall<br /> |22<br /> |<br /> |<br /> |- <br /> |requestReportBCSMEvent<br /> |23<br /> |<br /> |<br /> |- <br /> |eventReportBCSM<br /> |24<br /> |<br /> |<br /> |-<br /> |continue<br /> |31<br /> |<br /> |<br /> |- <br /> |resetTimer<br /> |33<br /> |<br /> |<br /> |- <br /> |furnishChargingInformation<br /> |34<br /> |<br /> |<br /> |- <br /> |applyCharging<br /> |35<br /> |<br /> |<br /> |- <br /> |applyChargingReport<br /> |36<br /> |<br /> |<br /> |- <br /> |callInformationReport<br /> |44<br /> |<br /> |<br /> |- <br /> |callInformationRequest<br /> |45<br /> |<br /> |<br /> |- <br /> |sendChargingInformation<br /> |46<br /> |<br /> |<br /> |- <br /> |sendChargingInformation<br /> |47<br /> |<br /> |<br /> |- <br /> |promptAndCollectUserInformation<br /> |48<br /> |<br /> |<br /> |- <br /> |specializedResourceReport<br /> |49<br /> |<br /> |<br /> |- <br /> |cancel<br /> |53<br /> |<br /> |<br /> |- <br /> |activityTest<br /> |55<br /> |<br /> |<br /> |}</div>

Monica https://ss7api.null.ro/index.php/Operation_codes Operation codes 2013-09-02T12:31:20Z

<p>Monica: </p> <hr /> <div>On this page<br /> *[[#Operation codes - GSM MAP|Operation codes - GSM MAP]]<br /> *[[#Operation codes - CAMEL|Operation codes - CAMEL]]<br /> <br /> ==Operation codes - GSM MAP==<br /> {| class="wikitable" style="text-align: left; color: green;"<br /> |Name<br /> |Code<br /> |Impl.<br /> |Notes<br /> |-<br /> |updateLocation<br /> |2<br /> |<br /> |<br /> |-<br /> |cancelLocation<br /> |3<br /> |<br /> |<br /> |- <br /> |provideRoamingNumber<br /> |4<br /> |<br /> |<br /> |-<br /> |insertSubscriberData<br /> |7<br /> |<br /> |<br /> |-<br /> |deleteSubscriberData<br /> |8<br /> |<br /> |<br /> |-<br /> |registerSS<br /> |10<br /> |<br /> |<br /> |-<br /> |eraseSS<br /> |11<br /> |<br /> |<br /> |-<br /> |activateSS<br /> |12<br /> |<br /> |<br /> |-<br /> |deactivateSS<br /> |13<br /> |<br /> |<br /> |-<br /> |interrogateSS<br /> |14<br /> |<br /> |<br /> |-<br /> |authenticationFailureReport<br /> |15<br /> |<br /> |<br /> |-<br /> |registerPassword<br /> |17<br /> |<br /> |<br /> |-<br /> |getPassword<br /> |18<br /> |<br /> |<br /> |- <br /> |updateGprsLocation<br /> |23<br /> |<br /> |<br /> |-<br /> |sendRoutingInfoForGprs<br /> |24<br /> |<br /> |<br /> |-<br /> |failureReport<br /> |25<br /> |<br /> |<br /> |-<br /> |reset<br /> |37<br /> |<br /> |<br /> |-<br /> |forwardCheckSS-Indication<br /> |38<br /> |<br /> |<br /> |-<br /> |mt-forwardSM<br /> |44<br /> |<br /> |<br /> |-<br /> |sendRoutingInfoForSM<br /> |45<br /> |<br /> |<br /> |- <br /> |mo-forwardSM<br /> |46<br /> |<br /> |<br /> |-<br /> |reportSM-DeliveryStatus<br /> |47<br /> |<br /> |<br /> |-<br /> |activateTracemMode<br /> |50<br /> |<br /> |<br /> |-<br /> |deactivateTraceMode<br /> |51<br /> |<br /> |<br /> |- <br /> |sendAuthenticationInfo<br /> |56<br /> |<br /> |<br /> |-<br /> |restoreData<br /> |57<br /> |<br /> |<br /> |-<br /> |sendIMSI<br /> |58<br /> |<br /> |<br /> |-<br /> |processUnstructuredSS-Request<br /> |59<br /> |<br /> |<br /> |-<br /> |unstructuredSS-Request<br /> |60<br /> |<br /> |<br /> |-<br /> |unstructuredSS-Notify<br /> |61<br /> |<br /> |<br /> |-<br /> |informServiceCentre<br /> |63<br /> |<br /> |<br /> |- <br /> |alertServiceCentre<br /> |64<br /> |<br /> |<br /> |-<br /> |readyForSM<br /> |66<br /> |<br /> |<br /> |- <br /> |purgeMS<br /> |67<br /> |<br /> |<br /> |- <br /> |provideSubscriberInfo<br /> |70<br /> |<br /> |<br /> |-<br /> |anyTimeInterrogation<br /> |71<br /> |<br /> |<br /> |- <br /> |setReportingState<br /> |73<br /> |<br /> |<br /> |- <br /> |statusReport<br /> |74<br /> |<br /> |<br /> |- <br /> |sendRoutingInfoForLCS<br /> |85<br /> |<br /> |<br /> |- <br /> |}<br /> <br /> ==Operation codes - CAMEL==<br /> <br /> {| class="wikitable" style="text-align: left; color: green;"<br /> |Name<br /> |Code<br /> |Impl.<br /> |Notes<br /> |-<br /> |initialDP<br /> |0<br /> |<br /> |<br /> |-<br /> |assistRequestInstructions<br /> |16<br /> |<br /> |<br /> |-<br /> |establishTemporaryConnection<br /> |17<br /> |<br /> |<br /> |-<br /> |disconnectForwardConnection<br /> |18<br /> |<br /> |<br /> |- <br /> |connectToResource<br /> |19<br /> |<br /> |<br /> |- <br /> |connect<br /> |20<br /> |<br /> |<br /> |- <br /> |releaseCall<br /> |22<br /> |<br /> |<br /> |- <br /> |requestReportBCSMEvent<br /> |23<br /> |<br /> |<br /> |- <br /> |eventReportBCSM<br /> |24<br /> |<br /> |<br /> |-<br /> |continue<br /> |31<br /> |<br /> |<br /> |- <br /> |resetTimer<br /> |33<br /> |<br /> |<br /> |- <br /> |furnishChargingInformation<br /> |34<br /> |<br /> |<br /> |- <br /> |applyCharging<br /> |35<br /> |<br /> |<br /> |- <br /> |applyChargingReport<br /> |36<br /> |<br /> |<br /> |- <br /> |callInformationReport<br /> |44<br /> |<br /> |<br /> |- <br /> |callInformationRequest<br /> |45<br /> |<br /> |<br /> |- <br /> |sendChargingInformation<br /> |46<br /> |<br /> |<br /> |- <br /> |sendChargingInformation<br /> |47<br /> |<br /> |<br /> |- <br /> |promptAndCollectUserInformation<br /> |48<br /> |<br /> |<br /> |- <br /> |specializedResourceReport<br /> |49<br /> |<br /> |<br /> |- <br /> |cancel<br /> |53<br /> |<br /> |<br /> |- <br /> |activityTest<br /> |55<br /> |<br /> |<br /> |}</div>

Monica https://ss7api.null.ro/index.php/Operation_codes Operation codes 2013-09-02T12:30:51Z

<p>Monica: </p> <hr /> <div>On this page<br /> *[[#Operation codes - GSM MAP|Operation codes - GSM MAP]]<br /> <br /> <br /> ==Operation codes - GSM MAP==<br /> {| class="wikitable" style="text-align: left; color: green;"<br /> |Name<br /> |Code<br /> |Impl.<br /> |Notes<br /> |-<br /> |updateLocation<br /> |2<br /> |<br /> |<br /> |-<br /> |cancelLocation<br /> |3<br /> |<br /> |<br /> |- <br /> |provideRoamingNumber<br /> |4<br /> |<br /> |<br /> |-<br /> |insertSubscriberData<br /> |7<br /> |<br /> |<br /> |-<br /> |deleteSubscriberData<br /> |8<br /> |<br /> |<br /> |-<br /> |registerSS<br /> |10<br /> |<br /> |<br /> |-<br /> |eraseSS<br /> |11<br /> |<br /> |<br /> |-<br /> |activateSS<br /> |12<br /> |<br /> |<br /> |-<br /> |deactivateSS<br /> |13<br /> |<br /> |<br /> |-<br /> |interrogateSS<br /> |14<br /> |<br /> |<br /> |-<br /> |authenticationFailureReport<br /> |15<br /> |<br /> |<br /> |-<br /> |registerPassword<br /> |17<br /> |<br /> |<br /> |-<br /> |getPassword<br /> |18<br /> |<br /> |<br /> |- <br /> |updateGprsLocation<br /> |23<br /> |<br /> |<br /> |-<br /> |sendRoutingInfoForGprs<br /> |24<br /> |<br /> |<br /> |-<br /> |failureReport<br /> |25<br /> |<br /> |<br /> |-<br /> |reset<br /> |37<br /> |<br /> |<br /> |-<br /> |forwardCheckSS-Indication<br /> |38<br /> |<br /> |<br /> |-<br /> |mt-forwardSM<br /> |44<br /> |<br /> |<br /> |-<br /> |sendRoutingInfoForSM<br /> |45<br /> |<br /> |<br /> |- <br /> |mo-forwardSM<br /> |46<br /> |<br /> |<br /> |-<br /> |reportSM-DeliveryStatus<br /> |47<br /> |<br /> |<br /> |-<br /> |activateTracemMode<br /> |50<br /> |<br /> |<br /> |-<br /> |deactivateTraceMode<br /> |51<br /> |<br /> |<br /> |- <br /> |sendAuthenticationInfo<br /> |56<br /> |<br /> |<br /> |-<br /> |restoreData<br /> |57<br /> |<br /> |<br /> |-<br /> |sendIMSI<br /> |58<br /> |<br /> |<br /> |-<br /> |processUnstructuredSS-Request<br /> |59<br /> |<br /> |<br /> |-<br /> |unstructuredSS-Request<br /> |60<br /> |<br /> |<br /> |-<br /> |unstructuredSS-Notify<br /> |61<br /> |<br /> |<br /> |-<br /> |informServiceCentre<br /> |63<br /> |<br /> |<br /> |- <br /> |alertServiceCentre<br /> |64<br /> |<br /> |<br /> |-<br /> |readyForSM<br /> |66<br /> |<br /> |<br /> |- <br /> |purgeMS<br /> |67<br /> |<br /> |<br /> |- <br /> |provideSubscriberInfo<br /> |70<br /> |<br /> |<br /> |-<br /> |anyTimeInterrogation<br /> |71<br /> |<br /> |<br /> |- <br /> |setReportingState<br /> |73<br /> |<br /> |<br /> |- <br /> |statusReport<br /> |74<br /> |<br /> |<br /> |- <br /> |sendRoutingInfoForLCS<br /> |85<br /> |<br /> |<br /> |- <br /> |}<br /> <br /> ==Operation codes - CAMEL==<br /> <br /> {| class="wikitable" style="text-align: left; color: green;"<br /> |Name<br /> |Code<br /> |Impl.<br /> |Notes<br /> |-<br /> |initialDP<br /> |0<br /> |<br /> |<br /> |-<br /> |assistRequestInstructions<br /> |16<br /> |<br /> |<br /> |-<br /> |establishTemporaryConnection<br /> |17<br /> |<br /> |<br /> |-<br /> |disconnectForwardConnection<br /> |18<br /> |<br /> |<br /> |- <br /> |connectToResource<br /> |19<br /> |<br /> |<br /> |- <br /> |connect<br /> |20<br /> |<br /> |<br /> |- <br /> |releaseCall<br /> |22<br /> |<br /> |<br /> |- <br /> |requestReportBCSMEvent<br /> |23<br /> |<br /> |<br /> |- <br /> |eventReportBCSM<br /> |24<br /> |<br /> |<br /> |-<br /> |continue<br /> |31<br /> |<br /> |<br /> |- <br /> |resetTimer<br /> |33<br /> |<br /> |<br /> |- <br /> |furnishChargingInformation<br /> |34<br /> |<br /> |<br /> |- <br /> |applyCharging<br /> |35<br /> |<br /> |<br /> |- <br /> |applyChargingReport<br /> |36<br /> |<br /> |<br /> |- <br /> |callInformationReport<br /> |44<br /> |<br /> |<br /> |- <br /> |callInformationRequest<br /> |45<br /> |<br /> |<br /> |- <br /> |sendChargingInformation<br /> |46<br /> |<br /> |<br /> |- <br /> |sendChargingInformation<br /> |47<br /> |<br /> |<br /> |- <br /> |promptAndCollectUserInformation<br /> |48<br /> |<br /> |<br /> |- <br /> |specializedResourceReport<br /> |49<br /> |<br /> |<br /> |- <br /> |cancel<br /> |53<br /> |<br /> |<br /> |- <br /> |activityTest<br /> |55<br /> |<br /> |<br /> |}</div>

Monica https://ss7api.null.ro/index.php/ActivityTest ActivityTest 2013-08-28T12:25:39Z

<p>Monica: </p> <hr /> <div>{{DISPLAYTITLE:activityTest}}<br /> ==Capability: Camel==<br /> <br /> ==Usage==<br /> <br /> This operation is used to check for the continued existence of a relationship between the gsmSCF and gsmSSF, gsmSCF and gsmSRF or gsmSCF and assistSSF. If the relationship is still in existence, then the gsmSSF, gsmSRF or assistSSF will respond.<br /> <br /> ==Expected actions==<br /> <br /> * When receiving this operation, the receiving end will respond the this invocation in order to acknowledge that the connection is still in existence.<br /> <br /> ==Invoke parameters==<br /> <br /> This operation hasn't any invoke parameters.<br /> <br /> ==Result parameters==<br /> <br /> This operation expects a result.<br /> <br /> ==Example==<br /> <br /> <component remoteCID="1" type="Invoke" operationCode="activityTest"/></div>

Monica https://ss7api.null.ro/index.php/Cancel Cancel 2013-08-28T12:25:15Z

<p>Monica: </p> <hr /> <div>{{DISPLAYTITLE:cancel}}<br /> ==Capability: Camel== <br /> <br /> ==Usage==<br /> <br /> This operation is used by the gsmSCF to request the gsmSRF to cancel a correlated previous operation. The operation to be deleted can be either a PlayAnnouncement or a PromptAndCollectUserInformation operation. It can also be used to cancell all outstanding requests.<br /> <br /> ==Expected actions==<br /> <br /> <br /> ==Invoke parameters==<br /> <br /> * The operation contains one of the following parameters:<br /> ** '''invokeID''' – specifies the operation to be cancelled<br /> ** '''allRequests''' – indicates that all active requests for EventReportBCSM, ApplyChargingReport and CallInformationReport shall be cancelled.<br /> <br /> <br /> ==Result parameters==<br /> <br /> This operation does not expect a result.<br /> <br /> ==Example==<br /> <br /> <component localCID="1" type="Invoke" operationCode="cancel"><br /> <cancelArg><br /> <allRequests/><br /> </cancelArg><br /> </component></div>

Monica https://ss7api.null.ro/index.php/SpecializedResourceReport SpecializedResourceReport 2013-08-28T12:24:55Z

<p>Monica: </p> <hr /> <div>{{DISPLAYTITLE:specializedResourceReport}}<br /> ==Capability: Camel== <br /> <br /> ==Usage==<br /> <br /> This operation is used by the gsmSRF to indicate as a response to the gsmSCF that a “PlayAnnouncement” operation that the announcement was completed when a report indication was set.<br /> <br /> ==Expected actions==<br /> <br /> ==Invoke parameters==<br /> <br /> This operation has not any Invoke parameters.<br /> <br /> ==Result parameters==<br /> <br /> This operation does not expect a result.<br /> <br /> ==Example==<br /> <br /> <component localCID="1" type="Invoke" operationCode="specializedResourceReport"/></div>

Monica