Begin Voice Call

Voice Call - Initialise

This node allows a voice call to be initialised through the InitialDP INAP message. This connects the A-Party to the network and begins call control handling by the SRF.


Test Fields

Additional Calling Party Number

optional

This field provides space in the InitialDP to delivery a secondary number to identify the calling party.

Usually this field is used for VPN services, where the calling party number will have a VPN specific address as well as a PSTN number.

Examples

  • 2122

Bearer Capability

optional

The bearer capability identifies what sort of capabilities the MSC can support on the connection. In generally this indicates whether the circuits involved can support data, voice or some other form of connection capability. Usually when supporting voice, the voice quality and compression is defined as well.

By default the application sets this to 8090a3, which is hex to indicate that the capabilities are:

  • Speech
  • 64 kbit/s
  • Encoded as G.711 A-law

Examples

  • 0x8090a3

Called Party Number

optional

The B-party - the party that the calling party dialled to connect to - is given in this calling party number field.

This field is generally used at the AnalyzedInfo (DP 3) trigger point and contains the address digits as inferred by the SSF. The IN Tester will give a warning if this field is used outside of where the standard specifies.

Examples

  • 06 358 1140

Called Party (BCD) Number

optional

The Called Party (BCD) Number field is very similar to the Called (B) Party field. It generally holds the digits dialled by the A-party without any modification by the SSF.

This field is generally used at the CollectedInfo (DP 2) trigger point and contains the address digits as received by the SSF.

Examples

  • 06 358 1140

Call Forward Flag (callForwardingSS-Pending)

optional

The Call Forward Flag, technically titled the callForwardingSS-Pending or gsm-ForwardingPending flag depending on the version of INAP CAMEL used, indicates that a forwarding number exists for the subscriber (configured at a lower level in the network to the SCP) and that the call will be forwarded, unless the SCP indicates it should otherwise not be.


Calling Party Number

required

The A-party - the party that dialled the called party - is given in this calling party number field.

Usually this is the caller’s phone number in national format.

Examples

  • 022 063 5462

Calling Party’s Category

required

The calling party’s category in the InitialDP message identifies the type of call being made. In most cases this will be set to 10 which indicates that the call is a normal voice call.

Examples

  • 10 Ordinary Calling Subscriber
  • 32 Payphone

Call Reference Number

optional

The call reference number is a unique value identifying this call to the SCF and SSF. Usually this number would be a mixture of MSC identifier and a call counter.

This field is always populated in mobile networks, but for testing purposes is generally not necessary.

If creating a call reference number, any number 2 to 16 hex characters long will be suitable.

Examples

  • 0x1d3980e329

OCNCC Extension Interaction

When the IN Tester OCNCC Extensions are installed and configured on the OCNCC SLC being tested against, the call reference number will be included in any SLC CDR or VWS EDR generated by the call triggered by this test.

The EDR/CDR tag name is CALLREF, and the value is the hex representation of the call reference number. It will match the representation shown in the IN Tester UI, excluding the 0x prefix, if there is one.

For example:

BILLING_ENGINE_ID=1| SCP_ID=77481969| SEQUENCE_NUMBER=357800| CDR_TYPE=1| RECORD_DATE=20130910212934| ACCT_ID=21| ACCT_REF_ID=21| CLI=64220635462| TN=6463581140| TCS=20130910212933| CS=D| ACCOUNT_TYPE=24| NACK=WDIS| WALLET_TYPE=47| CALLREF=55445566

This VWS EDR example was generated with a call reference explicitly set to: 0x55445566 in the initiate call node of a test flow.


Call Time

optional

This field is always populated in mobile networks, but for testing purposes is generally not necessary.

If defining a call time, the format is: YYYYMMDDHH24MISSTZ, where:

YYYY
  The full year, e.g. 2012
MM
  The month, e.g. 04 (April)
DD
  The day, e.g. 09 (9th)
HH24
  The time in 24 hour time, e.g. 19 (7pm)
MI
  Minutes past the hour, e.g. 56
SS
  Seconds past the minute, e.g. 13
TZ
  The offset from GMT, in quarter hours - e.g. 48 is 12 hours, 32 is 8 hours.

Examples

  • 2012100415234532 is the 4th October 2012 at 3:23:45 pm, offset by 8 hours from GMT (e.g. Hong Kong).

OCNCC Extension Interaction

When the IN Tester OCNCC Extensions are installed and configured on the OCNCC SLC being tested against, the time given by the Call Time field will be used in call processing.

For example, if the current time is September 13th 2013 at 4:32pm, and the value of this field is set to 2013070122000000, then the OCNCC system will, for the test call, consider the time to be 10pm on the 1st July 2013 (GMT).

OCNCC will honor this call time when considering control plan nodes such as the day of week or day of year node, and time of day node.

With the appropriate version and patches to the OCNCC VWS, the OCNCC VWS will also honor this date and time, rating calls as at the time. This allows testing of discounts and other features specific to time of day, or day of year.

Note the timezone value is ignored by the OCNCC extensions.

Note the time is assumed to be in server time. In most cases this is GMT.


Event Type BCSM

required

The event that triggers this call (and InitialDP) to be sent from the SSF to the SCF.

Usually this will be Collected Info or Analysed Info for calls triggered by the caller dialling (where the calling party number is the subscriber), and Termination Attempt for calls where the called party number is number of interest.

Examples

  • 2 - Collected Info - Digits have been collected by the SSF but not analysed (e.g. not normalised).
  • 12 - Termination Attempt - A B-party connection is being attempted.

IMSI

optional

An International Mobile Subscriber Identity (IMSI) is a unique identification associated with all GSM, UMTS and LTE network SIM cards.

An IMSI is usually presented as a 15 digit long number.

An IMSI is not often required and can be left out of the InitialDP, unless a HLR lookup by the SCP is required.

Examples

  • 748381927423738

Location Number

optional

The location number is designed to identify the caller’s nominal “location” narrowing it to a general geographical area (usually derived from cell site the subscriber’s phone is communicating with).

E.g. 644 would be used to identify a caller as being within the Wellington Region (4) in New Zealand (64)

Note that this may not identify a physical location - especially in mobile phone networks - as it generally identifies where the switching hardware managing the call is, not where the subscriber is.

Often this field will be empty in mobile networks too (the vlrNumber and possibly mscAddress will be populated instead)

Examples

  • 649

MSC Address

optional

The MSC (Mobile Switching Center) identifies the switch handling the call.

The MSC address is coded as a E.164 number, identifying the MSC uniquely throughout the world.

Often in networks the value of this will match the vlrNumber

Examples

  • 64221422101

Service Key

required

The service key field must be set in the initial DP to identify to the SCF the service this call has triggered.

Usually the SSF would identify the service key from the trigger detection point, the calling party number or the dialled digits.

Examples

  • 100
  • 0x192000038

VLR Number

optional

The VLR (Visitor Location Register) holds details on mobile subscribers currently handled by a particular MSC. Most often this function is integrated into the MSC.

The VLR Number identifies which VLR the subscriber is currently associated with. It gives a full E.164 address of the VLR, uniquely identifying the VLR among all others.

This field is almost always populated in mobile networks, although sometimes the mscAddress field will only be populated. Often both the mscAddress and vlrNumber fields will be populated with the same value.

Examples

  • 64221422101

Cell Global ID

optional

The Cell Global ID (CGI) field indicates the geographic location of the mobile subscriber. Within the CAMEL specifications, It is composed from four separate fields:

  • Mobile Country Code (MCC): a three-digit code specifying the country, as defined in ITU-T E.212.
  • Mobile Network Code (MNC): a two- or three-digit code specifying the mobile network, also defined in ITU-T E.212.
  • Location Area Code (LAC): a two-byte (four hexadecimal digits) reference code indicating the served radio area within the mobile network. This is a freeform operator value.
  • Cell Identity or Service Area Code (CI/SAC): a two-byte (four hexadecimal digits) reference code indicating the specific serving cellular site the subscriber is attached to. As for LAC, this is a freeform operator value.

MCC and MNC are regulated by telecommunications authorities, whereas LAC and CI/SAC are locally administrated. The combination of MCC/MNC/LAC/CI is globally unique.

Note that all four fields must be specified to form a CGI.

Examples

  • 530 24 0x1234 0x5678

Location Information Age

optional

The age of the location information values, specified in minutes.

Examples

  • 15


Original Called Party ID

optional

The original called party field is used in call redirection scenarios to identify the original dialled number.

For example, If A-Party calls B-Party, and B-Party has a call redirection service enabled which triggers the call to be connected to a C-Party, then an IDP may be sent to deal with the A -> C party call. In this scenario the original called party field will hold the B-Party number.

For the first redirection in a chain, the original called party and redirecting party fields are most likely the same. In subsequent redirections (e.g. C-Party redirects to D-Party) the original called party will continue to be the B-Party, but the redirecting party number will be updated.

Examples


Redirection Counter

optional

The redirection counter identifies how often a call has been redirected. This will be 1 for the first redirection of a call, and incremented each time a further redirection occurs.

SS7 networks generally have checks in place to ensure that the redirection counter does not increase to high, avoiding circular redirections.

If call redirection has occurred, this must be set, along with the redirecting indicator and redirection reason fields.

Examples


Redirection Indicator

optional

Indicates why the call was redirected. Usually set to 1 for normal redirection cases.

Examples


Redirecting Reason

optional

The original and current redirecting reason fields identify to the network why the redirection occurred. This will be scenario specific.

Examples


Redirecting Party ID

optional

The redirecting party field is used in call redirection scenarios to identify the last party to redirect this particular call.

For example, If A-Party calls B-Party, and B-Party has a call redirection service enabled which triggers the call to be connected to a C-Party, then an IDP may be sent to deal with the A -> C party call. In this scenario the redirecting party field will hold the B-Party number.

Generally the SCP will use the redirecting party to identify who should be charged for calls, and so the redirecting party is used in preference to the calling party number.

For the first redirection in a chain, the original called party and redirecting party fields are most likely the same. In subsequent redirections (e.g. C-Party redirects to D-Party) the original called party will continue to be the B-Party, but the redirecting party number will be updated.

Examples