Rebranching is a message handling option that applies only to Connect operations that a service sends and the SIS processes. The rebranching option lets a service restart composition script evaluation mid-call, so a new initial request can retrigger services that follow the one doing the rebranching.

Tip This is a SIS feature for IN.
Note Rebranching only applies when the SIS sends a Connect response to a leg-terminating event report; for example, "called party busy", "no answer", "disconnect", and so on.

Example

As an example, consider the following call flow:

rebranching call flow example

In this scenario:

  1. The initial request invokes both services.

  2. Service-A responds by arming some BCSM events (including oCalledPartyBusy and sending a Connect).

  3. Service-B simply responds with a Continue and drops out of the dialog interaction.

  4. Some time later, the network reports oCalledPartyBusy, which the SIS delivers to Service-A.

  5. Service-A responds to the event report by sending a second Connect operation to an alternative destination number.

Without the rebranching option, the SIS would simply send the second Connect operation back to the network as a final response to the ERB. However if Service-A’s message handling options specify invoking rebranching, then the SIS behaves as if the Connect operation was a response to the initial request originally sent to the service. This means the SIS:

  • generates a new initial request, based on the original initial request that Service-A received, but modified as necessary by the parameters contained in the new Connect operation

  • restarts composition script evaluation, using the generated initial request as input, at the script statement immediately following the invoke statement for Service-A (that is, at the same point composition evaluation would have continued after the first Connect that the service sent).

How retriggered services affect SIS responses to the network

Retriggered services may affect what final response the SIS sends to the network for the ERB in the same way that would apply during initial composition evaluations. In particular:

  • A Continue response has no effect — the previously stored Connect remains the final response.

  • A Connect response replaces the previously stored Connect response, to be sent as the final response.

  • A Release response overrides any other response. The SIS immediately sends it to the network; terminates composition evaluation; and notifies services still active in the composition of the call termination (as normal).

Previous page Next page