Connect to B-Party
Voice Call - Connect to B-Party
This node provides for full handling of the following activities within a call:
- Requesting connection to a B-Party.
- Being informed if the B-Party connection succeeded or failed (through BCSM events).
- Limiting and managing call length of the call for charging purposes (through the ApplyCharging operations).
Test Fields
Connect Operation
required This field specifies the Examples In freephone services, it is often desirable for the company with the
freephone number to spread calls among multiple addresses - e.g. so calls
reach regional support centers. The test system supports testing for this scenario with the The test will then ensure that the address received from the SCF is one of the
addresses input. Note that only the digits of each address are checked - the
NOA and other additional data values are not. In addition, in load test situations it will count the number of times each
address is seen. This allows testing of scenarios where multiple addresses are
used in a proportional (or load sharing) fashion.Connect To
destinationRoutingAddress
(DRA) that is sent in the
Connect
message from the SCP to the SSP. The DRA tells the SSP the actual
phone number to connect to and may be different to the called party number from
the InitialDP
received.
06 358 1140
Multiple Addresses
Add another
possibility
button. Using this, add each destination routing address that may
be expected.
optional, custom If the call flow should expect a INAP Continue instead of an INAP Connect, set
this flag to “yes”. Note that an INAP Continue will not include the
Use INAP Continue?
destinationRoutingAddress
from the Connect To
field.
optional Indicates the number of leading digits to be deleted from the called party
number dialled by the subscriber. The SSP will then place the digits from the For example, if the subscriber dialled 09-456-7899, and the connect sent back
64 with a ExamplesCut and Paste
destinationRoutingAddress
in
place of the digits cut from the called party number.cutAndPaste
of 1, the SSP would remove the leading 0 off the
dialled digits and replace with 64.
3
Redirection Information
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. ExamplesOriginal Called Party
06 358 1140
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. ExamplesRedirecting Party
06 358 1140
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. ExamplesRedirection Counter
1
optional Indicates why the call was redirected. Usually set to ExamplesRedirecting Indicator
1
for normal
redirection cases.
1
optional The original and current redirection reason fields identify to the network why
the redirection occurred. This will be scenario-specific. ExamplesOriginal and Current Redirection Reason
3
BCSM Operations
required The Basic Call State Model (BCSM) is the flow-chart model under which the SSP
and SCP interact. Within this model a number of events can occur, such as
“Call Answered” and “B-Party No Answer”. The SCP can ask the SSP to inform it when certain events within a call occur.
Such requests take place in a Request Report BCSM Event (RRBCSM) operation. The Oracle NCC, OCCAS, Nokia and Squire IWF options provided with this field will,
when one is selected, choose the appropriate BCSM events for that product
interaction model. Events can also be added or removed individually as
required. The Connect to B-Party node will automatically include an oAnswer ERBCSM
message when the “oAnswer” event is selected and a A or B party disconnect
is selected as the Event Triggered.Requested Events
optional The expected value of the “No Answer” application timer in the RRBCSM message.No Answer Timer
required In most cases, if the SCP requests from the SSP to be informed of events when
they occur, the SSP will response with an event report identifying which event
did occur. For some events, such as “oAbandon”, the SCP is informed and the SSP continues
to process the call (in the oAbandon case the call is ended by the SSP without
further SCP interaction). In others, such as “oNoAnswer”, the SCP is informed of the event occurring,
and the SSP waits for further instructions from the SCP. The SCP therefore has
a chance to direct the call to another phone number, play an announcement or
end the call.Event Triggered
optional The Call Forward Flag
Call Forward Flag
indicates whether a “tNoAnswer” and/or “tBusy” event
has been triggered by call forwarding configuration at the MSC level.
Call Information Operations
optional When requesting call information, the A or B leg can be explicitly specified
to identify which leg of the call should be reported on. In most cases this
will be the A leg for MO calls, and the B leg for MT calls.Call Leg
optional If requested, the SSF will provide the number of seconds prior to the call leg
being connected (or a hangup occured). This essentially reflects the number of
seconds that the phone was ringing.Call Attempt Time
optional If requested, the SSF will provide the number of deci-seconds the call leg was
connected. This generally reflects the number of deci-second the A and B party
were connected and able to communicate.Call Connected Time
optional If requested, the SSF will provide the exact second at which the call ended. If defining a call stop time, the format is: YYYY
MM
DD
HH24
MI
SS
TZ
ExamplesCall Stop Time
YYYYMMDDHH24MISSTZ
, where:
The full year, e.g. 2012
The month, e.g. 04 (April)
The day, e.g. 09 (9th)
The time in 24 hour time, e.g. 19 (7pm)
Minutes past the hour, e.g. 56
Seconds past the minute, e.g. 13
The offset from GMT, in quarter hours - e.g. 50 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).
optional If requested, the SSF will provide the telephone number of the called party in
this field.Called Adddress
optional If requested, the SSF will provide the release cause for the call leg. This
corresponds to the normal release causes: ExamplesRelease Cause
3
No route to destination16
Normal call clearing21
Call rejected31
Normal release
Apply Charging Operations (CAMEL)
required, custom The software system allows tests to be executed with automated or explicit
handling of the ApplyCharging/ApplyChargingReport messages. When using Explicit handling, each AC and ACR message must be defined in
full, and if multiple are expected, each pair must be listed. When using Automated handling, the test software will handle as many AC/ACR
messages as necessary to match the call talk time requested by the test. Unless you specifically need to, we suggest using automatic AC/ACR handling.Automatic or Explicit AC/ACR Handing
optional This is a flag field indicating whether the call is still active. If an ACR was requested by the SCP (as it sent an AC), and the call did not
connect to the B party, the ACR should set this field to 0. If the A or B party have hung up, and this is the final ACR, this field should
be set to 0. If the call released by SSP flag is set, this field should be set to 0. This field should be set to 1 only when the SSP is expecting to receive
further time (in the form of another ACR) from the SCP so the call can
continue. ExamplesCall Active Flag
1
indicating the call is still active.
optional This flag should be set only if the previous ApplyCharging message included
the “release if exceeded” flag set to 1, and the SSP was forced to end the
call as the A or B party did not hang up prior to the end of the time they
were allowed to talk for.Call Released by SSP Flag
required The ApplyCharging from the SCP to the SSP includes this field to tell the SSP
how long the A and B party can be connected before the SSP must request
further time from the SCP. If the release if duration exceeded field is set to 1, then this field
indicates the length of time the A and B party can be connected before the
call must be ended, and the SSP must not request further time from the SCP. ExamplesMax Call Period Duration
300
deciseconds (30 seconds)
required If the SSP should end the call once the given max call period duration is
past, without requesting any further time, this field should be set to 1. ExamplesRelease if Duration Exceeded
1
set the field to true.
required, custom When using automated AC/ACR handling, the total time the A and B party are
connected for is given. This time is given in 10ths of a second (deciseconds)
so 10 deciseconds equates to 1 second. When executing the test, if the first ApplyCharging provided by the SCP is not
enough to cover the entire requested talk time, the test execution will
requires further time by sending back a properly crafted ApplyChargingReport. ExamplesTalk Time (Automated Handling)
300
deciseconds (30 seconds)
required When the SSP returns an ApplyChargingReport to the SCP, this field should be
filled to indicate the total time the A and B parties have been connected for. This should be the total time across all AC/ACR messages prior to this
message. The value of this field is given in deci-seconds. ExamplesActual Talk Time
424
deciseconds.
optional If a audible tone should be played to the subscriber at the end of the
duration given by the ApplyCharging message, then the tone ID can be
identified in this field. This is sometimes called the low balance warning indicator tone.Tone
Apply Charging Operations (GENBAND)
required The number of seconds that the caller is allowed to talk for prior to the
switch disconnecting the call. ExamplesMaximum Conversation Time
3600
indicates 1 hour of talk time is available to the caller.
optional The number of seconds prior to the end of the talk time given given by
“Maximum Conversation Time” that the caller should be given a ‘end of call
soon’ tone. This is equivalent to a low balance warning in CAMEL, but the switch will play
it in the future. ExamplesWarning Time Before Expiry
60
indicates that a tone should be played 60 seconds prior to the end of the call (as per Maximum Conversation Time).
optional The message ID (a simple integer) indicating the message ID that should be
played as the tone to indicate call end is occurring in the near future (as
defined by Warning Time Before Expiry) The IN Tester UI hard codes the associated data for the message ID (number of
repetitions, duration and interval) to 1, 0, 0 respectively. ExamplesWarning Tone Message ID
15
Tone 15 should be played. The actual tone is dependent on switch configuration.
optional The number of seconds that the caller and called party actual talked for. This
will be equal to or less than Maximum Conversation Time. ExamplesUsed Time
30
indicates 30 seconds of talking occurred.
required The release cause for the call - i.e. how the call disconnected. This field is binary, rather than a straight number. ExamplesRelease Cause
0x0000
indicates the call disconnected due to expiry of the permitted conversation duration.0x0020
indicates the call disconnected due to other SSP action.0x8090
unknown but identified in real world scenarios