☰
Navigation :

SCC Messages

Introduction

The SIP Logic Hand-Off Application (LhoSipApp) uses SCC-... messages for SIP call control. These messages are transmitted over the n2svcd message bus between the LHO SIP Application (LhoSipApp) and the Logic Application (LogicApp).

The start of the message sequence is slightly different between incall and outcall scenarios.

However once the A-Leg is established, the subsequent SCC-... messages are identical.

The SCC-... message names are divided into two categories depending on which direction the message is flowing.

a. SCC-HANDLE-... messages from LhoSipApp to LogicApp to request service logic assistance. b. SCC-DO-... messages from LogicApp to LhoSipApp to perform service logic actions.

SIP Incall Messages

Initiated by LhoSipApp by sending SCC-HANDLE-ALEG-INBOUND-INVITE to LogicApp.

Handled by LhoSipLuaService which selects the Lua script to execute.

The internal messages used between LhoSipApp and LogicApp during incall setup are:

…plus the common messages.

Here is an example internal n2svcd message flow for the incall scenario with interaction, where the RTP stream for the interaction is generated by an Internal RTP resource (an instance of the RtpApp), not from an External INAP-controlled SRF.

SCC Message Flow (Incall)

SIP Outcall Messages

Initiated by LogicApp from an already-running Lua script. That Lua script must be initiated by some other mechanism, e.g. an inbound REST request.

The internal messages used between LhoSipApp and LogicApp during outcall setup are:

…plus the common messages.

Here is an example internal n2svcd message flow for the outcall scenario with interaction, where the RTP stream for the interaction is generated by an Internal RTP resource (an instance of the RtpApp), not from an External INAP-controlled SRF.

SCC Message Flow (Outcall)

SIP Common Messages

The following messages are common to both incall and outcall.

SCC-DO-ALEG-OUTBOUND-INVITE

The SCC-DO-ALEG-OUTBOUND-INVITE message is sent from the LogicApp to the LhoSipApp to instruct the LhoSipApp to send a SIP INVITE Request to connect an A-Leg.

This message will cause a new LhoSipInstance to be created, which initially has no leg control. The instance will send a new INVITE Request to connect the A-Leg, and will report back to the service logic once the result of that Request is known.

After sending this message, the service logic should send no further messages until it receives one of the following messages from the LhoSipApp:

If the A-Leg is connected successfully, the LhoSipApp will send the LogicApp an SCC-HANDLE-ALEG-ANSWER-ONGOING message. The service logic may then proceed to process the call in a manner essentially identical to the incall scenario where an inbound SIP INVITE Request causes an SCC-HANDLE-ALEG-INBOUND-INVITE message to be sent to the LogicApp. Specifically, the service logic may attempt to:

Otherwise the A-Leg was not connected successfully or an unexpected error occurred. The service logic should send no further messages. The LhoSipInstance has been shutdown and the associated call is over.

The attributes of the SCC-DO-ALEG-OUTBOUND-INVITE message are:

Field Type Description
scc Object [Required] The SIP call control parameters for the message.
.calling_party (+)Hex String [Required] The userinfo part of the calling party for the INVITE Request.
The protocol and domain parts of the address will be determined automatically.
The applicable configured calling_party denormalisation on the LhoSipApp will be applied.
The calling party will be placed in either the P-Asserted-Identity or From header, depending on whether presentation of the calling party is restricted or not.
.presented_calling_party (+)Hex String The userinfo part of the INVITE Request From header address.
The protocol and domain parts of the address will be determined automatically.
The applicable configured calling_party denormalisation on the LhoSipApp will be applied.
This parameter will have no effect if presentation of the calling party is restricted.
(Default = .calling_party).
.is_calling_restricted 0 / 1 Specify whether presentation of the calling party should be restricted.
When restricted, the outbound INVITE Request From and Contact headers will be anonymous, and a Privacy header containing the id flag will be included.
When not restricted, the outbound INVITE Request From and Contact headers will not be anonymous, and a Privacy header will not be included.
(Default = 0, not restricted).
.called_party (+)Hex String [Required] The userinfo part of the INVITE Request URI address.
The protocol and domain parts of the address will be determined automatically.
The applicable configured called_party denormalisation on the LhoSipApp will be applied.
This parameter value will also be used as the userinfo part of the INVITE Request To header address if the .original_called_party parameter is not specified.
.original_called_party (+)Hex String The userinfo part of the INVITE Request To header address.
The protocol and domain parts of the address will be determined automatically.
The applicable configured called_party denormalisation on the LhoSipApp will be applied.
(Default = .called_party).
.no_answer_timeout Positive Integer [Required] Specifies the desired time limit for INVITE Request processing in seconds.
The LhoSipApp will enforce a maximum bound for this value.
A CANCEL Request will be sent if a Final Response is not received within this time.
.extra_headers Object Additional user headers to include in the SIP INVITE Request.
The object keys are header names.
The object values are an array of header values.
(Default = do not add extra user headers).

SCC-DO-ALEG-PROCEEDING

The SCC-DO-ALEG-PROCEEDING message is sent from the LogicApp to the LhoSipApp to instruct the LhoSipApp to send a SIP INVITE Provisional Response (100-199) to the A-Leg, and optionally to refresh the service logic wait timer.

This message can only be sent for an incall A-Leg, when a Final Response has not yet been sent and the Provisional Response does not have to provide an SDP Offer.

Any of the following service logic actions may cause a Final Response to be sent:

An SDP Offer is required if the A-Leg INVITE Request does not contain an SDP Offer and requires reliable Provisional Response (i.e. 100rel, PRACK Request).

The ability to send this message is signalled using the proceed_ok attribute in the SCC-HANDLE-ALEG-INBOUND-INVITE, SCC-HANDLE-ALEG-PROCEEDED, SCC-HANDLE-BLEG-FAILURE-ONGOING, and SCC-HANDLE-ALEG-INTERACTION-COMPLETE-ONGOING messages.

Note that this SCC-DO-ALEG-PROCEEDING message should not (and cannot) be used for sending a 100 Trying Provisional Response. A 100 Trying Provisional Response is sent automatically by the LhoSipApp and cannot be user-controlled.

After sending this message, the service logic should send no further messages until it receives one of the following messages from the LhoSipApp:

If the A-Leg proceeded successfully, the LhoSipApp will send the LogicApp an SCC-HANDLE-ALEG-PROCEEDED message. The service logic may then attempt to:

Otherwise the A-Leg abandoned or an unexpected error occurred. The service logic should send no further messages. The LhoSipInstance has been shutdown and the associated call is over.

The attributes of the SCC-DO-ALEG-PROCEEDING message are:

Field Type Description
scc Object [Required] The SIP call control parameters for the message.
.code Integer [Required] The code to send in the SIP INVITE Provisional Response.
The code must be in the range 101-199.
.seconds Integer Requests a specific service logic wait timer extension.
This allows the service logic more time to complete processing while in the proceeding state.
(Default = do not refresh the service logic timer).
.extra_headers Object Additional user headers to include in the SIP INVITE Provisional Response.
The object keys are header names.
The object values are an array of header values.
(Default = do not add extra user headers).

Note that the initial service logic timer is defined in milliseconds, but the refresh timer value (if present) is specified in seconds.

SCC-DO-ALEG-DECLINE-FINAL

The SCC-DO-ALEG-DECLINE-FINAL message is sent from the LogicApp to the LhoSipApp to instruct the LhoSipApp to send a SIP INVITE Final Response (300-699) to the A-Leg.

This message can only be sent for an incall A-Leg, when a Final Response has not yet been sent.

Any of the following service logic actions may cause a Final Response to be sent:

The ability to send this message is signalled using the decline_ok attribute in the SCC-HANDLE-ALEG-INBOUND-INVITE, SCC-HANDLE-ALEG-PROCEEDED, SCC-HANDLE-BLEG-FAILURE-ONGOING, and SCC-HANDLE-ALEG-INTERACTION-COMPLETE-ONGOING messages.

The SCC-DO-ALEG-HANGUP-FINAL message can be used if the SCC-DO-ALEG-DECLINE-FINAL message cannot be sent.

Note that codes 401, 403, and 491 are handled internally by the LhoSipApp, and the service logic does not need to (and should not) use this method to perform authentication or pending Request checks.

After sending this message, the service logic should send no further messages. The LhoSipInstance has been shutdown and the associated call is over.

The attributes of the SCC-DO-ALEG-DECLINE-FINAL message are:

Field Type Description
scc Object [Required] The SIP call control parameters for the message.
.code Integer The code to send in the SIP INVITE Final Response.
The code must be in the range 300-699.
(Default = 603 or other platform-configured default value).
.contact_user (+)Hex String The digits identifying an alternate contact, to include in the SIP INVITE Final Response Contact header.
The protocol and domain parts of the address will be determined automatically.
This is typically only used when .code = 302.
(Default = do not include a Contact header).
.reason Object This is a container for specifying the details for a Reason header. The header will be included in the SIP INVITE Final Response.
(Default = do not include a Reason header).
.protocol SIP/Q.850 The protocol value to include in the Reason header.
(Default = SIP).
.cause Integer The cause parameter value to include in the Reason header.
(Default = do not include a cause parameter in the header).
.text String The text parameter value to include in the Reason header.
(Default = do not include a text parameter in the header).
.extra_headers Object Additional user headers to include in the SIP INVITE Final Response.
The object keys are header names.
The object values are an array of header values.
(Default = do not add extra user headers).

SCC-DO-ALEG-HANGUP-FINAL

The SCC-DO-ALEG-HANGUP-FINAL message is sent from the LogicApp to the LhoSipApp to instruct the LhoSipApp to end the call.

The A-Leg will be torn down using one of:

If a B-Leg exists it will be torn down using one of:

After sending this message, the service logic should send no further messages. The LhoSipInstance has been shutdown and the associated call is over.

The attributes of the SCC-DO-ALEG-HANGUP-FINAL message are:

Field Type Description
scc Object [Required] The SIP call control parameters for the message.
.code Integer The code to send in the A-Leg SIP INVITE Final Response or BYE Request Reason header.
The code must be in the range 300-699.
(Default = 603 or other platform-configured default value).
.reason Object This is a container for specifying the details for a Reason header. The header will be included in the A-Leg SIP INVITE Final Response or BYE Request, depending on which is used.
(Default = do not include a Reason header).
.protocol SIP/Q.850 The protocol value to include in the Reason header.
(Default = SIP).
.cause Integer The cause parameter value to include in the Reason header.
(Default = do not include a cause parameter in the header).
.text String The text parameter value to include in the Reason header.
(Default = do not include a text parameter in the header).

SCC-DO-ALEG-INTERACTION-INTERNAL

The SCC-DO-ALEG-INTERACTION-INTERNAL message is sent from the LogicApp to the LhoSipApp to instruct the LhoSipApp to use the local Internal RTP resource (i.e. RtpApp) to perform an interaction on the A-Leg.

If the Internal RTP resource is not already connected to the A-Leg, RTP port(s) will be allocated and the A-Leg will be connected using one of:

If a Final Response to the A-Leg INVITE Request has not yet been sent and an SDP Offer/Answer exchange has not been completed, an INVITE Response will be used with the Offer or Answer included as appropriate.

If a Final Response to the A-Leg INVITE Request has not yet been sent but the SDP Offer/Answer exchange has already been completed (i.e. previous Early Media), a SIP INVITE Final Response with code 200 OK will be sent, then the SDP session will be renegotiated using a re-INVITE Request.

If a Final Response to the A-Leg INVITE Request has been sent, the SDP session will be renegotiated using a re-INVITE Request.

These are in fact the same standard options which would apply for a SIP Back-to-Back User Agent (B2BUA) connection to a B-Leg. Refer to the N2SIP Protocol Conformance Statement for a more thorough description of the supported SDP exchange mechanisms with specific reference to RFC 6337.

If there is currently a temporary B-Leg connection active for the purpose of performing interactions with an External INAP-controlled SRF, the LhoSipApp will disconnect the SRF to enable the interaction to proceed using the Internal RTP resource.

If there is currently a B-Leg end-to-end call in progress, this message will be rejected. That is to say: it is not permitted to use this internal interaction mechanism while a monitored or charged call is in progress. The service logic must explicitly end the B-Leg end-to-end call, or wait for it to be terminated by one of the parties.

After an interaction is complete, the connection between the A-Leg and the Internal RTP resource will remain established in anticipation of subsequent internal interactions. The connection between the A-Leg and the Internal RTP resource will be torn down when the subsequent action is not an internal interaction (i.e. subsequent action is decline, hangup, B-Leg termination, or external interaction).

Note that this message can be sent with no .announcement information, in which case the Internal RTP resource will be connected to the A-Leg without any interaction being performed. This is useful for IVR implementations where the desired behavior is:

  1. Receive inbound SIP INVITE Request for the purpose of being an IVR under external control.
  2. Establish A-Leg connection (i.e. send SCC-DO-ALEG-INTERACTION-INTERNAL without announcement details).
  3. Notify the external controller that we are ready for instructions (e.g. by sending INAP AssistRequestInstructions).
  4. Wait for interaction instructions from the external controller (e.g. receive INAP PlayAnnouncement).
  5. Execute the interaction instructions (using SCC-DO-ALEG-INTERACTION-INTERNAL with announcement details).
  6. Wait for the interaction to complete (i.e. receive SCC-HANDLE-ALEG-INTERACTION-COMPLETE-ONGOING).
  7. Return the interaction result to the external controller (e.g. by sending INAP SpecializedResourceReport).
  8. Go to step 4.

In the above scenario, the LogicApp, LhoSipApp, and RtpApp constitute a media server that can operate under locally-implemented service logic control, or - with the addition of SigtranApp - under external control from another node. This is the reverse of the scenario in which LogicApp sends SCC-DO-ALEG-INTERACTION-EXTERNAL messages and acts as the controller for an External INAP-controlled SRF.

After sending this message, the service logic should send no further messages until it receives one of the following messages from the LhoSipApp:

If the interaction completed with the A-Leg still connected, the LhoSipApp will send the LogicApp an SCC-HANDLE-ALEG-INTERACTION-COMPLETE-ONGOING message. The service logic may then attempt to:

Otherwise the A-Leg abandoned or an unexpected error occurred. The service logic should send no further messages. The LhoSipInstance has been shutdown and the associated call is over.

The attributes of the SCC-DO-ALEG-INTERACTION-INTERNAL message are:

Field Type Description
scc Object [Required] The SIP call control parameters for the message.
.early_media String The Early Media preference for the interaction.
This preference will always be honoured when establishing a new connection between the A-Leg and the Internal RTP resource.
When the A-Leg is already connected to the internal RTP resource, an Early Media connection will be "upgraded" to a 200 OK connection if the value is never. Otherwise the existing connection will be used without change, regardless of the value.
  • require - Early Media must be used. If not possible for any reason the call will be torn down.
  • prefer - Early Media will be used if possible for the SIP and RTP protocol layers, and the early_media_policy configured on the LhoSipApp is not never.
  • allow - Early Media will be used if possible for the SIP and RTP protocol layers, and the early_media_policy configured on the LhoSipApp is prefer.
  • never - Early Media will not be used.
(Default = nil, use the early_media_policy configured on the LhoSipApp).
.aleg_headers Object Additional user headers to include in the SIP INVITE Response or SIP re-INVITE Request sent to the A-Leg when the Internal RTP resource is connected.
The object keys are header names.
The object values are an array of header values.
(Default = do not add extra user headers).
.announcement Object An object specifying the parameters for the interaction which is to be performed.
This structure is passed through (with potential modifications as indicated) into the RTP-PLAY message sent to the RtpApp.
(Default = open the RTP connection but do not perform any interaction).
.message_id Integer A single message ID to play.
This ID must be configured within the RtpApp database or file-based configuration.
The definition of this ID may depend on the specified language, and may include a mixture of audio files and variable parts.
Specify exactly one of .message_id or .message_ids or .files.
.message_ids Array of Integer An array of one or more message IDs to play in sequence.
Each ID listed here must be configured within the RtpApp database or file-based configuration.
The definition of each ID may depend on the specified language, and may include a mixture of audio files and variable parts.
Each ID listed here may contain variable parts. The supplied variable parts list must contain sufficient variable parts for all message IDs.
Specify exactly one of .message_id or .message_ids or .files.
.files Array of String An array of one or more filenames to play in sequence.
Specifying this parameter will bypass the message ID translation process in RtpApp and allows the service logic to explicitly control the audio file fragments to be played.
All filenames must be associated with the announcement language. It is not possible to override the language per-file.
Filenames must not include the audio file type suffix part e.g. must not contain the .ul, or .amr.
Each filename must include the subdirectory announcements or variable_parts.
The directory name "a" is a supported abbreviation for "announcements".
The directory names "vp" and "v" are supported abbreviations for "variable_parts".
Example: { 'a/You_Entered', 'v/1', 'vp/4' }.
Specify exactly one of .message_id or .message_ids or .files.
.language String The name of a language to use instead of the default language configured on the RtpApp.
The RtpApp will use this when translating message ID/IDs and variable parts into a file list.
This language name must be configured within the RtpApp database or file-based configuration.
Refer to the RtpApp configuration documentation.
(Default = use the default language configured on the RtpApp).
.repetition Postive Integer The number of times to play the announcement.
(Default = 1, play the announcement only once).
.duration Postive Integer The total permitted duration of the interaction including repetitions and any silence.
(Default = use the rtp_max_play_secs configured on the LhoSipApp).
.variables Array of Object An array containing the values to substitute into pre-defined placeholders in the message structure.
Each entry in the table is a table which specifies exactly one of the attributes as follows.
(Default = no variables).
.integer Integer An integer value to speak as a variable part.
Construction rules for the chosen/default langage will be used.
.number_digits (+)Hex String A hexadecimal numeric string to speak as a variable part.
Each digit will be spoken individually.
Construction rules for the chosen/default langage will be used.
.time_hhmm <HHMM> An integer hour and minute to speak as a variable part.
Value must be in the range 0000 to 2400.
Construction rules for the chosen/default langage will be used.
.date_yymmdd <YYMMDD> A 6-digit integer year/month/day to speak as a variable part.
Construction rules for the chosen/default langage will be used.
.date_yyyymmdd <YYYYMMDD> An 8-digit integer year/month/day to speak as a variable part.
Construction rules for the chosen/default langage will be used.
.price_digits Integer An integer value of "cents" to speak as a variable part.
Construction rules for the chosen/default langage will be used.
.collect Object A container for parameters related to digit collection.
Digit collection will be performed if and only if this parameter is present.
(Default = do not collect digits).
.min_num_digits 1 - 32 [Required] The minimum number of digits to collect.
This value must be less than or equal to max_num_digits.
.max_num_digits 1 - 32 [Required] The maximum number of digits to collect.
This value must be greater than or equal to min_num_digits.
.end_digit #*A-D0-9 A digit which the caller can use to indicate End of Input.
(Default = use the internal_end_digit configured on the LhoSipApp).
.cancel_digit #*A-D0-9 A digit which the caller can use to clear all previous input.
(Default = use the internal_cancel_digit configured on the LhoSipApp).
.first_digit_timeout Postive Integer The number of seconds allowed for the caller to enter the first digit after the announcement completes playing.
(Default = use the default_first_digit_timeout configured on the RtpApp).
.inter_digit_timeout Postive Integer The number of seconds allowed for the caller to enter a subsequent digit after entering at least one digit.
(Default = use the default_inter_digit_timeout configured on the RtpApp).
.interruptable 0 / 1 When 1, the first digit entered by the caller will interrupt the playing of the announcement.
When 0, the announcement will play in full, even if digit collection is completed before the end of the announcement.
(Default = use the default_interruptable configured on the RtpApp).
.private_digits 0 / 1 When 1, the collected digits are considered private, and will not be logged to LhoSipApp EDRs.
(Default = use the default_private_digits configured on the LhoSipApp).

SCC-DO-ALEG-INTERACTION-EXTERNAL

The SCC-DO-ALEG-INTERACTION-EXTERNAL message is sent from the LogicApp to the LhoSipApp to instruct the LhoSipApp to use an External INAP-controlled SRF to perform an interaction on the A-Leg.

If the target SRF is not already connected to the A-Leg, the LhoSipApp will send a new SIP INVITE Request to connect the SRF, then - acting as a SIP Back-to-Back User Agent (B2BUA) - relay the relevant messages between the Legs as necessary to establish and maintain a connection.

In order to enable INAP control, the LhoSipApp will engage SigtranApp to coordinate a TCAP/INAP dialogue in parallel to the SIP dialog. The To header address user part in the SIP INVITE Request sent to the SRF will:

SigtranApp will notify LhoSipApp when the INAP AssistRequestInstructions operation is received from the SRF. At that point, LhoSipApp can use SigtranApp to control the SRF by sending INAP PlayAnnouncement and PromptAndCollectUserInformation operations as directed by the service logic. The SRF will be expected to respond with INAP SpecializedResourceReport operations, TCAP Return Results, or TCAP Return Errors as appropriate.

If the Internal RTP resource is currently connected to the A-Leg for the purpose of performing interactions, the LhoSipApp will disconnect the Internal RTP resource to enable the interaction to proceed using the External INAP-controlled SRF.

If there is currently a temporary B-Leg connection active for the purpose of performing interactions with a different SRF, the LhoSipApp will disconnect the other SRF to enable the interaction to proceed using the target SRF.

If there is currently a B-Leg end-to-end call in progress, this message will be rejected. That is to say: it is not permitted to use this external interaction mechanism while a monitored or charged call is in progress. The service logic must explicitly end the B-Leg end-to-end call, or wait for it to be terminated by one of the parties.

After an interaction is complete, the connection between the A-Leg and the SRF will remain established in anticipation of subsequent extternal interactions. The connection between the A-Leg and the SRF will be torn down when the subsequent action is not an external interaction with the same SRF (i.e. subsequent action is decline, hangup, B-Leg termination, internal interaction, or external interaction with a different SRF).

After sending this message, the service logic should send no further messages until it receives one of the following messages from the LhoSipApp:

If the interaction completed with the A-Leg still connected, the LhoSipApp will send the LogicApp an SCC-HANDLE-ALEG-INTERACTION-COMPLETE-ONGOING message. The service logic may then attempt to:

Otherwise the A-Leg abandoned or an unexpected error occurred. The service logic should send no further messages. The LhoSipInstance has been shutdown and the associated call is over.

The attributes of the SCC-DO-ALEG-INTERACTION-EXTERNAL message are:

Field Type Description
scc Object [Required] The SIP call control parameters for the message.
.srf_name String [Required] The name of the SRF to use to perform the interaction, as configured on the LhoSipApp.
.calling_party (+)Hex String The userinfo part of the INVITE Request From header address.
The protocol and domain parts of the address will be determined automatically.
The applicable configured calling_party denormalisation on the LhoSipApp will be applied.
Set to undef to suppress the network-supplied presented calling party (if any).
This parameter will have no effect if presentation of the calling party is restricted.
(Default = for an A-Leg initiated by an outbound INVITE Request, the A-Leg presented called party; for an A-Leg initiated by an inbound INVITE Request, the A-Leg presented calling party).
.is_calling_restricted 0 / 1 Specify whether presentation of the calling party should be restricted.
This parameter will have no effect if:
  • The A-Leg was initiated by an inbound INVITE Request that contained a Privacy header with value none.
  • The A-Leg was initiated by an outbound INVITE Request with a Response that contained a Privacy header with value none.
Otherwise, when restricted, the SRF INVITE Request From and Contact headers will be anonymous, and a Privacy header containing the id flag will be included. Other flags from any Privacy headers in the A-Leg INVITE Request or Response will be included in the SRF INVITE Request Privacy header.
When not restricted, the SRF INVITE Request From and Contact headers will not be anonymous, and a Privacy header will not be included.
(Default = for an A-Leg initiated by an inbound INVITE Request, the restriction requested by the calling party; for an A-Leg initiated by an outbound INVITE Request, the restriction requested by the called party).
.original_called_party (+)Hex String The userinfo part of the INVITE Request To header address.
The protocol and domain parts of the address will be determined automatically.
The applicable configured called_party denormalisation on the LhoSipApp will be applied.
(Default = use the SRF INVITE Request called party).
.announcement Object [Required] A container specifying the parameters for the interaction which is to be performed.
.message_id Integer A single message ID to play.
This ID will be conveyed to the SRF in the informationToSend.messageID.elementaryMessageID or informationToSend.messageID.variableMessage.elementaryMessageID IE within the INAP PA or PACUI message.
The ID must be coordiated with the SRF.
The definition of this ID may depend on the specified language, and may include a mixture of audio files and variable parts.
Specify exactly one of .message_id or .message_ids.
.message_ids Array of Integer A table of one or more message IDs to play in sequence.
These IDs will be conveyed to the SRF in the informationToSend.messageID.elementaryMessageIDs IE within the INAP PA or PACUI message.
The IDs must be coordiated with the SRF.
The definitions of these IDs may depend on the specified language, but are only expected to include audio files (no variable parts).
Specify exactly one of .message_id or .message_ids.
.language String The name of a language to prefer instead of any default used by the SRF.
If possible, the language preference will be conveyed to the SRF along with the interaction parameters. The LhoSipApp language map configuration may be used to map the language to an integer ID that the the SRF will understand.
(Default = use any default language used by the SRF).
.repetition Positive Integer The value for the informationToSend.inbandInfo.numberOfRepetitions IE within the INAP PA or PACUI message.
(Default = do not send this value to the SRF).
.duration Integer The value for the informationToSend.inbandInfo.duration IE within the INAP PA or PACUI message.
(Default = do not send this value to the SRF).
.interval Integer The value for the informationToSend.inbandInfo.interval IE within the INAP PA or PACUI message.
(Default = do not send this value to the SRF).
.variables Array of Object An array containing the values to substitute into pre-defined placeholders in the message structure.
Each entry in the table is a table which specifies exactly one of the attributes as follows.
(Default = no variables).
.integer Integer An integer value to speak as a variable part.
This will be conveyed to the SRF in the VariablePart.integer IE.
.number_digits (+)Hex String A hexadecimal numeric string to speak as a variable part.
This will be conveyed to the SRF in the VariablePart.number IE.
.time_hhmm <HHMM> An integer hour and minute to speak as a variable part.
This will be conveyed to the SRF in the VariablePart.time IE.
Value must be in the range 0000 to 2400.
.date_yymmdd <YYMMDD> A 6-digit integer year/month/day to speak as a variable part.
This will be conveyed to the SRF in the VariablePart.date IE.
.date_yyyymmdd <YYYYMMDD> An 8-digit integer year/month/day to speak as a variable part.
This will be conveyed to the SRF in the VariablePart.date IE.
.price_digits Integer An integer value of "cents" to speak as a variable part.
This will be conveyed to the SRF in the VariablePart.price IE.
.collect Object A container for parameters related to digit collection.
Digit collection will be performed if and only if this parameter is present.
(Default = do not collect digits).
.min_num_digits 1 - 32 [Required] The minimum number of digits which the SRF must collect.
This value will be conveyed to the SRF in the collectedInfo.collectedDigits.minimumNbOfDigits IE within the INAP PACUI message.
This value must be less than or equal to max_num_digits.
.max_num_digits 1 - 32 [Required] The maximum number of digits which the SRF must collect.
This value will be conveyed to the SRF in the collectedInfo.collectedDigits.maximumNbOfDigits IE within the INAP PACUI message.
This value must be greater than or equal to min_num_digits.
.end_digit #*A-F0-9 The value for the collectedInfo.collectedDigits.endOfReplyDigit IE within the PACUI message.
If the digit is * or #, the digit will be translated according to the star_digit and hash_digit configured on the LhoSipApp for the SRF.
(Default = use the end_digit configured on the LhoSipApp for the SRF).
.cancel_digit #*A-F0-9 The value for the collectedInfo.collectedDigits.cancelDigit IE within the PACUI message.
If the digit is * or #, the digit will be translated according to the star_digit and hash_digit configured on the LhoSipApp for the SRF.
(Default = use the cancel_digit configured on the LhoSipApp for the SRF).
.first_digit_timeout Postive Integer The value for the collectedInfo.collectedDigits.firstDigitTimeOut IE within the PACUI message.
(Default = do not send this value to the SRF).
.inter_digit_timeout Postive Integer The value for the collectedInfo.collectedDigits.interDigitTimeOut IE within the PACUI message.
(Default = do not send this value to the SRF).
.interruptable 0 / 1 The value for the collectedInfo.collectedDigits.interruptableAnnInd IE within the PACUI message.
(Default = do not send this value to the SRF).
.private_digits 0 / 1 When 1, the collected digits are considered private, and will not be logged to LhoSipApp EDRs.
Note that the SRF is a separate, independent element, and this flag does prevent the SRF from logging the collected digits.
(Default = use the default_private_digits configured on the LhoSipApp).

SCC-DO-BLEG-TERMINATION-ATTEMPT

The SCC-DO-BLEG-TERMINATION-ATTEMPT message is sent from the LogicApp to the LhoSipApp to instruct the LhoSipApp to send a SIP INVITE Request to connect a B-Leg.

In this context LhoSipApp acts as a SIP Signaling Plane Signaling-only Back-to-Back User Agent (B2BUA) as described by RFC 7092 section 3.1.2.

If there is currently a connection between the A-Leg and the Internal RTP resource or an External INAP-controlled SRF, that connection will be disconnected to enable the termination attempt to proceed.

If there is currently a B-Leg end-to-end call in progress, this message will be rejected. That is to say: it is not permitted to connect more than one B-Leg at any given time. The service logic must explicitly end the existing B-Leg end-to-end call, or wait for it to be terminated by one of the parties.

After sending this message, the service logic should send no further messages until it receives one of the following messages from the LhoSipApp:

If the termination attempt was successful and the A-Leg is successfully connected to the B-Leg, the LhoSipApp will send the LogicApp an SCC-HANDLE-BLEG-ANSWER-FINAL or SCC-HANDLE-BLEG-ANSWER-ONGOING message.

An SCC-HANDLE-BLEG-ANSWER-FINAL message will be sent when neither monitoring nor charging was requested. In this case the service logic should send no further messages. The A-Leg and B-Leg are connected, and LhoSipApp will remain in the SIP signalling path until either or both parties hang up. However, call control is no longer available.

An SCC-HANDLE-BLEG-ANSWER-ONGOING message will be used when either monitoring or charging was requested. The service logic must “sweep” for subsequent messages until either or both parties hang up, or the service logic decides to end the call using SCC-DO-ALEG-HANGUP-FINAL:

If the termination attempt was not successful but the A-Leg is still connected, the LhoSipApp will send the LogicApp an SCC-HANDLE-BLEG-FAILED-ONGOING message. The service logic may then attempt to:

Otherwise the A-Leg abandoned or an unexpected error occurred. The service logic should send no further messages. The LhoSipInstance has been shutdown and the associated call is over.

The attributes of the SCC-DO-BLEG-TERMINATION-ATTEMPT message are:

Field Type Description
scc Object [Required] The SIP call control parameters for the message.
.address_digits (+)Hex String [Required] The userinfo part of the INVITE Request URI address.
The protocol and domain parts of the address will be determined automatically.
The applicable configured called_party denormalisation on the LhoSipApp will be applied.
This parameter value will also be used as the userinfo part of the INVITE Request To header address if the .original_called_party parameter is not specified.
.calling_party (+)Hex String The userinfo part of the INVITE Request From header address.
The protocol and domain parts of the address will be determined automatically.
The applicable configured calling_party denormalisation on the LhoSipApp will be applied.
Set to undef to suppress the network-supplied presented calling party (if any).
This parameter will have no effect if presentation of the calling party is restricted.
(Default = for an A-Leg initiated by an outbound INVITE Request, the A-Leg presented called party; for an A-Leg initiated by an inbound INVITE Request, the A-Leg presented calling party).
.is_calling_restricted 0 / 1 Specify whether presentation of the calling party should be restricted.
This parameter will have no effect if:
  • The A-Leg was initiated by an inbound INVITE Request that contained a Privacy header with value none.
  • The A-Leg was initiated by an outbound INVITE Request with a Response that contained a Privacy header with value none.
Otherwise, when restricted, the B-Leg INVITE Request From and Contact headers will be anonymous, and a Privacy header containing the id flag will be included. Other flags from any Privacy headers in the A-Leg INVITE Request or Response will be included in the B-Leg INVITE Request Privacy header.
When not restricted, the B-Leg INVITE Request From and Contact headers will not be anonymous, and a Privacy header will not be included.
(Default = for an A-Leg initiated by an inbound INVITE Request, the restriction requested by the calling party; for an A-Leg initiated by an outbound INVITE Request, the restriction requested by the called party).
.original_called_party (+)Hex String The userinfo part of the INVITE Request To header address.
The protocol and domain parts of the address will be determined automatically.
The applicable configured called_party denormalisation on the LhoSipApp will be applied.
(Default = use the .address_digits parameter).
.no_answer_timeout Positive Integer [Required] Specifies the desired time limit for INVITE Request processing in seconds.
The LhoSipApp will enforce a maximum bound for this value.
A CANCEL Request will be sent if a Final Response is not received within this time.
.extra_headers Object Additional user headers to include in the SIP INVITE Request.
The object keys are header names.
The object values are an array of header values.
(Default = do not add extra user headers).
.max_call_secs Positive Integer Specifies the desired maximum permitted call duration in seconds.
The LhoSipApp will enforce minimum and maximum bounds for this value.
(Default = use the max_call_secs configured on the LhoSipApp).
.monitored 0 / 1 Set this value to indicate that this is a "Monitored" call attempt.
Only one of .monitored or .charged may be set to 1.
If this call attempt is answered, the service logic must use the .monitor_check method to monitor the call until it completes.
SIP re-INVITE Requests will be sent to both the A-Leg and B-Leg at intervals specified by .monitor_interval_secs to check that the call is still active. Corresponding monitor reports will be sent to the service logic.
(Default = 0, the call is not monitored).
.monitor_interval_secs Positive Integer Specifies the desired interval in seconds between the SIP re-INVITE Requests / monitor reports.
The LhoSipApp will enforce minimum and maximum bounds for this value.
Valid only when .monitored is 1.
(Default = use the activity_interval_secs configured on the LhoSipApp).
.charged 0 / 1 Set this value to indicate that this is a "Charged" call attempt.
Only one of .monitored or .charged may be set to 1.
If this call attempt is answered, the service logic must use the .charge_check and .charge_extend methods to authorise extensions on the charged call until it completes.
SIP re-INVITE Requests will be sent to both the A-Leg and B-Leg at the end of grant periods to check that the call is still active. Corresponding charge reports will be sent to the service logic.
(Default = 0, the call is not charged).
.grant_secs Positive Integer [Required if .charged is 1] Specifies the desired period in seconds from when the call attempt is answered until the initial SIP re-INVITE Requests / charge report.
The LhoSipApp will enforce minimum and maximum bounds for this value.
Valid only when .charged is 1.

SCC-DO-CHARGE-EXTEND

The SCC-DO-CHARGE-EXTEND message is sent from the LogicApp to the LhoSipApp to instruct the LhoSipApp to allow an ongoing charged call to continue.

This message should only be sent for charged calls after the LhoSipApp has sent an SCC-HANDLE-CHARGE-REPORT-ONGOING message to the LogicApp.

After sending this message, the service logic should send no further messages until it receives one of the following messages from the LhoSipApp:

If both Legs are still connected at the end of the granted extension, the LhoSipApp will send the LogicApp another SCC-HANDLE-CHARGE-REPORT-ONGOING message. The service logic may then attempt to:

If the B-Leg hangs up during the granted extension but the A-Leg is still connected, the LhoSipApp will send the LogicApp an SCC-HANDLE-BLEG-TEARDOWN-ONGOING message. The service logic may then attempt to:

Otherwise the A-Leg abandoned or an unexpected error occurred. The service logic should send no further messages. The LhoSipInstance has been shutdown and the associated call is over.

The attributes of the SCC-DO-CHARGE-EXTEND message are:

Field Type Description
scc Object [Required] The SIP call control parameters for the message.
.grant_secs Positive Integer [Required] Specifies the desired period in seconds until the next SIP re-INVITE Requests / charge report.
The LhoSipApp will enforce minimum and maximum bounds for this value.

SCC-DO-SHUTDOWN

The SCC-DO-SHUTDOWN message is sent from the LogicApp to the LhoSipApp to instruct the LhoSipApp to shutdown an LhoSipInstance and clean up the associated call.

This message indicates that service logic processing has failed unexpectedly and cannot continue.

The LhoSipApp should perform any necessary SIP transaction and dialog closure using Final Response, CANCEL Request, or BYE Request as applicable, then shutdown the LhoSipInstance.

No further SCC-... messages should be exchanged after this message.

The attributes of the SCC-DO-SHUTDOWN message are:

Field Type Description
error String [Required] A description of the error that occurred.

SCC-HANDLE-ALEG-FAILURE-FINAL

The SCC-HANDLE-ALEG-FAILURE-FINAL message is sent from the LhoSipApp to the LogicApp to inform the LogicApp that an attempt to connect an A-Leg (initiated as a result of a previously received SCC-DO-ALEG-OUTBOUND-INVITE message) was not successful.

This message will be sent when:

I.e. No SIP INVITE Response at all was received from the far end within the SIP state machine timer and/or service logic no-answer timer.

I.e. At least one Provisional Response (code 100-199) was received, but no Final Response (code 200-699) was received.

The service logic should send no further messages. The LhoSipInstance has been shutdown and the associated call is over.

The attributes of the SCC-HANDLE-ALEG-FAILURE-FINAL message are:

Field Type Description
scc Object [Required] The SIP call control parameters for the message.
.reason No Route / Declined / No Answer [Required] The reason why this message was sent.
.code Integer A SIP Final Response code (in the range 200-699) associated with the A-Leg outcall attempt.
This value is present only when the A-Leg outcall attempt received a SIP INVITE Final Response.

SCC-HANDLE-ALEG-ANSWER-ONGOING

The SCC-HANDLE-ALEG-ANSWER-ONGOING message is sent from the LhoSipApp to the LogicApp to inform the LogicApp that an attempt to connect an A-Leg (initiated as a result of a previously received SCC-DO-ALEG-OUTBOUND-INVITE message) was successful.

This message will be sent when a SIP INVITE Final Response with code 200 OK is received.

The service logic must provide call control instructions:

The attributes of the SCC-HANDLE-ALEG-ANSWER-ONGOING message are:

Field Type Description
scc Object [Required] The SIP call control parameters for the message.
.reason Answered [Required] The reason why this message was sent.
.code Integer [Required] The received SIP INVITE Final Response code (in the range 200-299).
At present LhoSipApp will only accept Response code 200.
.call_id String [Required] The Call-ID header value from the sent SIP INVITE Request.
.privacy Object This value is present only when one or more Privacy headers are present in one of the received SIP INVITE Responses.
This object will have entries with keys matching each of the Privacy flags which are present in the headers from the first Response that contains one or more headers. Object values will be 1.
For example if a Privacy header has value user;id then this object will be { user = 1, id = 1 }.
(Default = not present, the header was not present in any Response).
.p_preferred_identities Array of String Array of P-Preferred-Identity header values from one of the received SIP INVITE Responses.
This value is present only when the first Response containing one or more P-Preferred-Identity or P-Asserted-Identity headers contains one or more P-Preferred-Identity headers.
(Default = not present, the header was not present in any Response or the first Response containing P-Asserted-Identity headers).
.p_asserted_identities Array of String Array of P-Asserted-Identity header values from one of the received SIP INVITE Responses.
This value is present only when the first Response containing one or more P-Preferred-Identity or P-Asserted-Identity headers contains one or more P-Asserted-Identity headers.
(Default = not present, the header was not present in any Response or the first Response containing P-Preferred-Identity headers).
.p_charging_vector String The P-Charging-Vector header value from the sent SIP INVITE Request or the most recently received Response containing a P-Charging-Vector header.
This value is present only when a P-Charging-Vector header is present in the Request or one of the Responses.
(Default = not present, the header was not present in the Request or any Response).
.calling_party (+)Hex String [Required] Calling Party.
This is the .calling_party specified in the associated SCC-DO-ALEG-OUTBOUND-INVITE message, sent in the userinfo part of the SIP INVITE Request P-Asserted-Identity or From header Address.
It is guaranteed to contain only 0-9A-F digits.
.is_calling_restricted 0 / 1 [Required] Is presentation of the Calling Party restricted?
This value will be 1 if presentation restriction was applied to the calling party in the sent SIP INVITE Request.
.presented_calling_party (+)Hex String This is the userinfo part of the SIP INVITE Request From header Address.
It is guaranteed to contain only 0-9A-F digits.
This value is present only when:
  • .presented_calling_party was specified in the associated SCC-DO-ALEG-OUTBOUND-INVITE message, and
  • the specified .presented_calling_party differed from the specified .calling_party, and
  • .is_calling_restricted is 0
(Default = not present, the described value pre-conditions are not met).
.called_party (+)Hex String [Required] Called Party.
In most cases this is the .called_party specified in the associated SCC-DO-ALEG-OUTBOUND-INVITE message, sent in the userinfo part of the SIP INVITE Request URI Address.
The specified called party will be overridden if an INVITE Response containing a parseable P-Asserted-Identity header that includes an Address userinfo part is received.
It is guaranteed to contain only 0-9A-F digits.
.presented_called_party (+)Hex String This is the userinfo part of the SIP INVITE Request To header Address.
It is guaranteed to contain only 0-9A-F digits.
This value is present only when:
  • an INVITE Response containing a parseable P-Asserted-Identity header is received, and
  • the P-Asserted-Identity header includes an Address userinfo part, and
  • the userinfo differs from the .called_party specified in the associated SCC-DO-ALEG-OUTBOUND-INVITE message
(Default = not present, the described value pre-conditions are not met).
.is_called_restricted 0 / 1 [Required] Is presentation of the Called Party restricted?
This value will be 1 if .privacy contains the id or user flags.
.original_called_party (+)Hex String This is the .original_called_party specified in the associated SCC-DO-ALEG-OUTBOUND-INVITE message, sent in the userinfo part of the SIP INVITE Request To header Address.
It is guaranteed to contain only 0-9A-F digits.
This value is present only when:
  • .original_called_party was specified in the associated SCC-DO-ALEG-OUTBOUND-INVITE message, and
  • the specified .original_called_party differed from the specified .called_party
(Default = not present, the described value pre-conditions are not met).

SCC-HANDLE-ALEG-INBOUND-INVITE

The SCC-HANDLE-ALEG-INBOUND-INVITE message is sent from the LhoSipApp to the LogicApp to inform the LogicApp that an inbound SIP INVITE Request has been received and needs to be handled.

The LhoSipApp is configured with the name of the LogicApp to which the message should be sent. The LogicApp must have a configured LhoSipLuaService present to receive and process the message. The LhoSipLuaService will compare the message contents and with its configured triggers list in order to determine which Lua script to execute. The Lua script may be loaded from disk, database, or elsewhere depending on the service.

The service logic must provide call control instructions:

The attributes of the SCC-HANDLE-ALEG-INBOUND-INVITE message are:

Field Type Description
scc Object [Required] The SIP call control parameters for the message.
.request_uri Object [Required] The decoded object representation of the received SIP INVITE Request URI.
.string String [Required] The complete original Request URI.
.display_name String The display-name part of the Request URI, if present.
.parameters Object A map of top-level parameter values (not the address parameters).
Parameters without a value (e.g. ;urgent) will be present with a value of undef.
.address Object [Required] Container for the Address attributes.
.uri String [Required] The complete Address URI including parameters, but not including any < >.
.protocol String [Required] The Address protocol - sip or tel.
.user String [Required] The userinfo part (the part preceding the @) of the Address.
.host String [Required] The host part of the Address.
.port Integer The port part of the address, if explicitly present.
.parameters Object The Address parameters (not the top-level parameters).
This will include the transport parameter (if explicit), and could include otg or other site-specific parameters.
Parameters without a value (e.g. ;exdirectory) will be present with a value of undef.
.from Table [Required] The decoded object representation of the From header from the received SIP INVITE Request.
The object structure is identical to the structure described for the .request_uri value.
.to Object [Required] The decoded object representation of the To header from the received SIP INVITE Request.
The object structure is identical to the structure described for the .request_uri value.
.call_id String [Required] The Call-ID header value from the received SIP INVITE Request.
.privacy Object This value is present only when one or more Privacy headers are present in the received SIP INVITE Request.
This object will have entries with keys matching each of the Privacy flags which are present in the headers, each with the value 1.
For example if a Privacy header has value user;id then this object will be { user = 1, id = 1 }.
(Default = not present, the header was not present in the Request).
.p_preferred_identities Array of String Array of P-Preferred-Identity header values from the received SIP INVITE Request.
This value is present only when one or more P-Preferred-Identity headers are present in the Request.
(Default = not present, the header was not present in the Request).
.p_asserted_identities Array of String Array of P-Asserted-Identity header values from the received SIP INVITE Request.
This value is present only when one or more P-Asserted-Identity headers are present in the Request.
(Default = not present, the header was not present in the Request).
.p_charging_vector String The P-Charging-Vector header value from the received SIP INVITE Request.
This value is present only when a P-Charging-Vector header is present in the Request.
(Default = not present, the header was not present in the Request).
.extra_headers Object A container of extra headers "of interest" from the received SIP INVITE Request.
These are only headers specifically configured in the <invite_headers> configuration block.
The object keys are header names. Header names are upper/lower case as defined in the name attribute of the <invite_header> configuration, even though the matching for header names in the Request is performed using case-insensitive matching.
The object values are non-empty arrays of raw header values parsed for the corresponding header name.
(Default = not present, no headers of interest were matched).
.calling_party (+)Hex String [Required] Calling Party.
This is the userinfo part of the P-Asserted-Identity or From header Address.
It is guaranteed to contain only 0-9A-F digits.
.normalised_calling_party (+)Hex String [Required] Normalised Calling Party.
This is the .calling_party after any configured 'calling_party' normalisation rules have been applied.
It is guaranteed to contain only 0-9A-F digits.
.is_calling_restricted 0 / 1 [Required] Is presentation of the Calling Party restricted?
This value will be 1 if:
  • there are no Privacy headers in the received SIP INVITE Request, or the none flag is not present, and
  • the userinfo part of the From header Address is anonymous
.presented_calling_party (+)Hex String This is the userinfo part of the From header Address.
It is guaranteed to contain only 0-9A-F digits.
This value is present only when:
  • a parseable P-Asserted-Identity header is received, and
  • the userinfo part of the From header Address is not anonymous, and
  • after normalisation, the userinfo part of the From header Address differs from .normalised_calling_party
(Default = not present, the described value pre-conditions are not met).
.normalised_presented_calling_party (+)Hex String This is the .presented_calling_party after any configured 'calling_party' normalisation rules have been applied.
It is guaranteed to contain only 0-9A-F digits.
(Default = not present, there is no .presented_calling_party).
.called_party (+)Hex String [Required] Called Party.
This is the userinfo part of the Request URI Address.
It is guaranteed to contain only 0-9A-F digits.
.normalised_called_party (+)Hex String [Required] Normalised Called Party.
This is the .called_party after any configured 'called_party' normalisation rules have been applied.
It is guaranteed to contain only 0-9A-F digits.
.original_called_party (+)Hex String This is the userinfo part of the To header address.
It is guaranteed to contain only 0-9A-F digits.
This value is present only when, after normalisation, the userinfo part of the To header Address differs from .normalised_called_party.
(Default = not present, the described value pre-conditions are not met).
.normalised_original_called_party (+)Hex String This is the .original_called_party after any configured 'called_party' normalisation rules have been applied.
It is guaranteed to contain only 0-9A-F digits.
(Default = not present, there is no .original_called_party).
.pending_tn (+)Hex String [Required] Pending termination number digits.
The normalised pending termination number inferred from the SIP INVITE Request.
It is guaranteed to contain only 0-9A-F digits.
.proceed_ok 0 / 1 [Required] Can the service logic still send the SCC-DO-ALEG-PROCEEDING message?
This value will be 1 if an SDP Offer would not be required to proceed.

SCC-HANDLE-ALEG-PROCEEDED

The SCC-HANDLE-ALEG-PROCEEDED message is sent from the LhoSipApp to the LogicApp to inform the LogicApp that an attempt to proceed the A-Leg (initiated as a result of a previously received SCC-DO-ALEG-PROCEEDING message) was successful.

This message will be sent when:

The service logic must provide call control instructions:

The attributes of the SCC-HANDLE-ALEG-PROCEEDED message are:

Field Type Description
scc Object [Required] The SIP call control parameters for the message.
.reason Proceeded [Required] The reason why this message was sent.

SCC-HANDLE-ALEG-INTERACTION-COMPLETE-ONGOING

The SCC-HANDLE-ALEG-INTERACTION-COMPLETE-ONGOING message is sent from the LhoSipApp to the LogicApp to inform the LogicApp that an interaction with the A-Leg (initiated as a result of a previously received SCC-DO-ALEG-INTERACTION-INTERNAL or SCC-DO-ALEG-INTERACTION-EXTERNAL message) has completed and the A-Leg is still connected.

The service logic must provide call control instructions:

The attributes of the SCC-HANDLE-ALEG-INTERACTION-COMPLETE-ONGOING message are:

Field Type Description
scc Object [Required] The SIP call control parameters for the message.
.error String A description of the first error that occurred in connection with the interaction.
One of .digits or .error will be present when digit collection was requested.
If this value is defined, the service logic should assume that the intended audio was not played in full to the caller, and/or that digit collection was not completed successfully.
This value may be defined when e.g. the SRF could not be reached, some audio files were missing, some interaction parameters were invalid, etc.
.digits #*A-F0-9 Digits collected from the caller.
One of .digits or .error will be present when digit collection was requested.
This value will be present but empty if insufficient digits were collected from the caller.
.proceed_ok 0 / 1 [Required] Can the service logic still send the SCC-DO-ALEG-PROCEEDING message?
This value will be 1 if we have not yet sent a Final Response, and an SDP Offer would not be required to proceed.
.decline_ok 0 / 1 [Required] Can the service logic still send the SCC-DO-ALEG-DECLINE-FINAL message?
This value will be 1 if we have not yet sent a Final Response.

SCC-HANDLE-ALEG-INTERACTION-ABANDONED-FINAL

The SCC-HANDLE-ALEG-INTERACTION-ABANDONED-FINAL message is sent from the LhoSipApp to the LogicApp to inform the LogicApp that an interaction with the A-Leg (initiated as a result of a previously received SCC-DO-ALEG-INTERACTION-INTERNAL or SCC-DO-ALEG-INTERACTION-EXTERNAL message) has completed because the A-Leg abandoned.

The service logic should send no further messages. The LhoSipInstance has been shutdown and the associated call is over.

The attributes of the SCC-HANDLE-ALEG-INTERACTION-ABANDONED-FINAL message are:

Field Type Description
scc Object [Required] The SIP call control parameters for the message.
.reason Abandoned [Required] The reason why this message was sent.

SCC-HANDLE-ALEG-ABANDON-FINAL

The SCC-HANDLE-ALEG-ABANDON-FINAL message is sent from the LhoSipApp to the LogicApp to inform the LogicApp that the A-Leg has abandoned the call.

This message will be sent when the abandon is not associated with an interaction. Otherwise the SCC-HANDLE-ALEG-INTERACTION-ABANDONED-FINAL message will be used.

The service logic should send no further messages. The LhoSipInstance has been shutdown and the associated call is over.

The attributes of the SCC-HANDLE-ALEG-ABANDON-FINAL message are:

Field Type Description
scc Object [Required] The SIP call control parameters for the message.
.reason Abandoned [Required] The reason why this message was sent.
.talk_dsm Integer The talk-time duration in deci-seconds, as measured by the LhoSipApp.
This value is present only when the A-Leg abandoned an answered in-progress call.
(Default = 0, no talk-time was confirmed).

SCC-HANDLE-BLEG-ANSWER-FINAL

The SCC-HANDLE-BLEG-ANSWER-FINAL message is sent from the LhoSipApp to the LogicApp to inform the LogicApp that a termination attempt (initiated as a result of a previously received SCC-DO-BLEG-TERMINATION-ATTEMPT message) has completed and the B-Leg answered the call.

The call is in progress, but the service logic did not request monitoring or charging.

The LhoSipApp will stay in the signalling path, performing its role as a SIP Back-to-Back User Agent (B2BUA) until the call is over. Then the LhoSipInstance will be shutdown.

No further SCC-... messages should be exchanged after this message.

The attributes of the SCC-HANDLE-BLEG-ANSWER-FINAL message are:

Field Type Description
scc Object [Required] The SIP call control parameters for the message.
.reason Answered [Required] The reason why this message was sent.
.code Integer [Required] The received SIP INVITE Final Response code (in the range 200-299).
.ring_dsm Integer [Required] The ring-time duration in deci-seconds, as measured by the LhoSipApp.
.max_call_secs Positive Integer [Required] The actual maximum permitted call duration in seconds.
This may differ from the requested value because the LhoSipApp applies a default, and minimum and maximum bounds.

SCC-HANDLE-BLEG-ANSWER-ONGOING

The SCC-HANDLE-BLEG-ANSWER-ONGOING message is sent from the LhoSipApp to the LogicApp to inform the LogicApp that a termination attempt (initiated as a result of a previously received SCC-DO-BLEG-TERMINATION-ATTEMPT message) has completed and the B-Leg answered the call.

The call is in progress, and the service logic requested either monitoring or charging.

The service logic must “sweep” for subsequent messages until either or both parties hang up, or the service logic decides to end the call using SCC-DO-ALEG-HANGUP-FINAL:

The LhoSipApp will stay in the signalling path, performing its role as a SIP Back-to-Back User Agent (B2BUA) until the call is over or the service logic chooses to end the call.

The attributes of the SCC-HANDLE-BLEG-ANSWER-ONGOING message are:

Field Type Description
scc Object [Required] The SIP call control parameters for the message.
.monitored 1 This value is present only when the call is a monitored call.
Exactly one of .monitored or .charged will be present.
.charged 1 This value is present only when the call is a charged call.
Exactly one of .monitored or .charged will be present.
.reason Answered [Required] The reason why this message was sent.
.code Integer [Required] The received SIP INVITE Final Response code (in the range 200-299).
.ring_dsm Integer [Required] The ring-time duration in deci-seconds, as measured by the LhoSipApp.
.max_call_secs Positive Integer [Required] The actual maximum permitted call duration in seconds.
This may differ from the requested value because the LhoSipApp applies a default, and minimum and maximum bounds.
.monitor_interval_secs Positive Integer The actual monitor interval in seconds.
This may differ from the requested value because the LhoSipApp applies a default, and minimum and maximum bounds.
This value is present only when .monitored is present.
.grant_secs Positive Integer The actual first grant duration in seconds.
This may differ from the requested value because the LhoSipApp applies minimum and maximum bounds.
This value is present only when .charged is present.

SCC-HANDLE-BLEG-FAILED-ONGOING

The SCC-HANDLE-BLEG-FAILED-ONGOING message is sent from the LhoSipApp to the LogicApp to inform the LogicApp that a termination attempt (initiated as a result of a previously received SCC-DO-BLEG-TERMINATION-ATTEMPT message) has completed, the B-Leg did not answer the call, and the A-Leg is still connected.

The service logic must provide call control instructions:

The attributes of the SCC-HANDLE-BLEG-FAILED-ONGOING message are:

Field Type Description
scc Object [Required] The SIP call control parameters for the message.
.reason No Route / Declined / No Answer [Required] The reason why this message was sent.
.code Integer A SIP Final Response code (in the range 300-699) associated with the B-Leg termination attempt.
This value is present only when the B-Leg termination attempt received a SIP INVITE Final Response.
.proceed_ok 0 / 1 [Required] Can the service logic still send the SCC-DO-ALEG-PROCEEDING message?
This value will be 1 if we have not yet sent a Final Response, and an SDP Offer would not be required to proceed.
.decline_ok 0 / 1 [Required] Can the service logic still send the SCC-DO-ALEG-DECLINE-FINAL message?
This value will be 1 if we have not yet sent a Final Response.

SCC-HANDLE-BLEG-TEARDOWN-ONGOING

The SCC-HANDLE-BLEG-TEARDOWN-ONGOING message is sent from the LhoSipApp to the LogicApp to indicate to the LogicApp that a monitored or charged call (initiated as a result of a previously received SCC-DO-BLEG-TERMINATION-ATTEMPT message) has ended because the B-Leg has hung up, but the A-Leg is still connected.

The service logic must provide call control instructions:

The attributes of the SCC-HANDLE-BLEG-TEARDOWN-ONGOING message are:

Field Type Description
scc Object [Required] The SIP call control parameters for the message.
.reason Abandoned [Required] The reason why this message was sent.
.talk_dsm Integer [Required] The talk-time duration in deci-seconds, as measured by the LhoSipApp.

SCC-HANDLE-MONITOR-REPORT-ONGOING

The SCC-HANDLE-MONITOR-REPORT-ONGOING message is sent from the LhoSipApp to the LogicApp to indicate to the LogicApp that a monitored call (initiated as a result of a previously received SCC-DO-BLEG-TERMINATION-ATTEMPT message) is ongoing, and to update confirmed talk-time.

The service logic may provide call control instructions:

The attributes of the SCC-HANDLE-MONITOR-REPORT-ONGOING message are:

Field Type Description
scc Object [Required] The SIP call control parameters for the message.
.monitored_secs Positive Integer [Required] The accumulated talk-time in seconds confirmed by this and all previous reports, as measured by the LhoSipApp.

SCC-HANDLE-CHARGE-REPORT-ONGOING

The SCC-HANDLE-CHARGE-REPORT-ONGOING message is sent from the LhoSipApp to the LogicApp to indicate to the LogicApp that a charged call (initiated as a result of a previously received SCC-DO-BLEG-TERMINATION-ATTEMPT message) is ongoing, to update confirmed talk-time, and request a further talk-time allocation.

The service logic must provide call control instructions:

The attributes of the SCC-HANDLE-CHARGE-REPORT-ONGOING message are:

Field Type Description
scc Object [Required] The SIP call control parameters for the message.
.charged_secs Positive Integer [Required] The accumulated talk-time in seconds confirmed by this and all previous reports, as measured by the LhoSipApp.

SCC-HANDLE-SHUTDOWN

The SCC-HANDLE-SHUTDOWN message is sent from the LhoSipApp to the LogicApp to indicate to the LogicApp that call processing failed unexpectedly and could not continue.

The LhoSipInstance has been shutdown and the associated call is over.

The service logic should cleanup as appropriate.

No further SCC-... messages should be exchanged after this message.

The attributes of the SCC-HANDLE-SHUTDOWN message are:

Field Type Description
error String [Required] A description of the error that occurred.