Voice Call - Connect to B-Party

This node provides for full handling of the following activities within a call:


Test Fields

Connect Operation

Cut and Paste

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

  • 3

Use INAP Continue?

optional, custom

If the call flow should expect a INAP Continue instead of an INAP Connect, set this flag to "yes".


Destination Routing Address

required

The destination routing address (DRA) is send in the Connect message from the SCP to the SSP. The DRA tells the SSP which actual phone number to connect to and may be different to the called party number from the InitialDP

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.


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

BCSM Operations


BCSM Event

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.


BCSM Events

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.

The Oracle NCC options provided with this field will, when one is selected, choose the appropriate BCSM events for the product interaction model chosen.

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.


INAP Continue on oAnswer

optional, custom

If this flag is ticked, the test will expect an INAP continue in response to the oAnswer BCSM event that is sent to the SCP. If this flag is not ticked, then the test will not expect any message in response to the oAnswer ERBCSM event sent.


No Answer Timer

optional

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


Call Information Operations


Call Leg ID

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

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 Connected Elapsed 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 Stop 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: 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

optional

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


Release Cause

optional

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?

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.


Call Active Flag

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 ton 0.

If the call released by SSP flag is set, this field should be set ton 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

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.


Max Call Period Duration

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.

Examples

  • 300 deciseconds (30 seconds)

Release if Duration Exceeded

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.

Examples

  • 1 set the field to true.

Talk Time (Automated Handling)

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.

Examples

  • 300 deciseconds (30 seconds)

Talk Time

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.

Examples

  • 424 deciseconds.

Tone

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.

Examples

  • 0x3410

Apply Charging Operations (GENBAND)


Maximum Conversation Time

required

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

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.

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

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.

Examples

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

Used Time

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.

Examples

  • 30 indicates 30 seconds of talking occurred.

Release Cause

required

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