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
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. ExamplesAdditional Calling Party Number
2122
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 ExamplesBearer Capability
8090a3
, which is hex to indicate
that the capabilities are:
0x8090a3
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. ExamplesCalled Party Number
06 358 1140
optional The This field is generally used at the CollectedInfo (DP 2) trigger point and
contains the address digits as received by the SSF. ExamplesCalled Party (BCD) Number
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.
06 358 1140
optional The Call Forward Flag (callForwardingSS-Pending)
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.
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. ExamplesCalling Party Number
022 063 5462
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. ExamplesCalling Party’s Category
10
Ordinary Calling Subscriber32
Payphone
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 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 For example: This VWS EDR example was generated with a call reference explicitly set to:
Call Reference Number
0x1d3980e329
OCNCC Extension Interaction
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.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
0x55445566
in the initiate call node of a test flow.
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: YYYY Examples 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 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.Call Time
YYYYMMDDHH24MISSTZ
, where:
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.
2012100415234532
is the 4th October 2012 at 3:23:45 pm, offset by 8 hours from GMT (e.g. Hong Kong).OCNCC Extension Interaction
2013070122000000
, then the OCNCC system will,
for the test call, consider the time to be 10pm on the 1st July 2013 (GMT).
required The event that triggers this call (and InitialDP) to be sent from the SSF to
the SCF. Usually this will be ExamplesEvent Type BCSM
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.
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.
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. ExamplesIMSI
748381927423738
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. 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 ExamplesLocation Number
644
would be used to identify a caller as being within the Wellington
Region (4
) in New Zealand (64
)vlrNumber
and
possibly mscAddress
will be populated instead)
649
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 ExamplesMSC Address
vlrNumber
64221422101
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. ExamplesService Key
100
0x192000038
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 ExamplesVLR Number
mscAddress
field will only be populated. Often both the mscAddress and
vlrNumber fields will be populated with the same value.
64221422101
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: 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. ExamplesCell Global ID
530 24 0x1234 0x5678
optional The age of the location information values, specified in minutes. ExamplesLocation Information Age
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
06 358 1140
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
1
Redirection Indicator
optional
Indicates why the call was redirected. Usually set to 1
for normal
redirection cases.
Examples
1
Redirecting Reason
optional
The original and current redirecting reason fields identify to the network why the redirection occurred. This will be scenario specific.
Examples
3
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
06 358 1140