Navigation :

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

Connect To

This field specifies the 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.

Examples

06 358 1140

Multiple Addresses

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 Add another possibility button. Using this, add each destination routing address that may be expected.

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.

Use INAP Continue?

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 destinationRoutingAddress from the Connect To field.

Cut and Paste

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 destinationRoutingAddress in place of the digits cut from the called party number.

For example, if the subscriber dialled 09-456-7899, and the connect sent back 64 with a cutAndPaste of 1, the SSP would remove the leading 0 off the dialled digits and replace with 64.

Examples

Redirection Information

Original Called Party

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

Redirecting Party

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.

Examples

06 358 1140

Redirection Counter

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

Redirecting Indicator

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

Examples

Original and Current Redirection Reason

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

Examples

BCSM Operations

Requested Events

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.

No Answer Timer

The expected value of the “No Answer” application timer in the RRBCSM message.

Event Triggered

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.

Call Forward Flag

The 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

Call Leg

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 Attempt Time

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 Connected Time

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 Stop Time

If requested, the SSF will provide the exact second at which the call ended.

If defining a call stop 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. 50 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).

Called Adddress

If requested, the SSF will provide the telephone number of the called party in this field.

Release Cause

If requested, the SSF will provide the release cause for the call leg. This corresponds to the normal release causes:

Examples

3 No route to destination
16 Normal call clearing
21 Call rejected
31 Normal release

Apply Charging Operations (CAMEL)

Automatic or Explicit AC/ACR Handing

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.

Call Active Flag

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.

Examples

1 indicating the call is still active.

Call Released by SSP Flag

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.

Max Call Period Duration

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.

Examples

300 deciseconds (30 seconds)

Release if Duration Exceeded

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.

Examples

1 set the field to true.

Talk Time (Automated Handling)

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.

Examples

300 deciseconds (30 seconds)

Actual Talk Time

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.

Examples

424 deciseconds.

Tone

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.

Apply Charging Operations (GENBAND)

Maximum Conversation Time

The number of seconds that the caller is allowed to talk for prior to the switch disconnecting the call.

Examples

3600 indicates 1 hour of talk time is available to the caller.

Warning Time Before Expiry

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.

Examples

60 indicates that a tone should be played 60 seconds prior to the end of the call (as per Maximum Conversation Time).

Warning Tone Message ID

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.

Examples

15 Tone 15 should be played. The actual tone is dependent on switch configuration.

Used Time

The number of seconds that the caller and called party actual talked for. This will be equal to or less than Maximum Conversation Time.

Examples

30 indicates 30 seconds of talking occurred.

Release Cause

The release cause for the call - i.e. how the call disconnected.

This field is binary, rather than a straight number.

Examples

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