Based on these two facts about the internal configuration of an SBS call, the following general observations about feature interactions with SBS calls can be made.
Most features work with SBS
A significant number of the features that can interact with an SBS call work as those features do with any other QSIG trunk call.
Delay applies to all SBS calls
For features that do work with SBS calls, the standard SBS delay applies. However, some of the following feature interaction descriptions do not specifically mention SBS delay.
Call status
Any query or report that is related to an endpoint user on an SBS call indicates the call ID of the SBS signaling call, and the trunk ID of the signaling trunk, but not the bearer trunk. For example, a status station command that is issued against a telephone on an SBS call shows the telephone that is connected to an SBS trunk.
Feature signaling interworks to and from SBS signaling calls
Any feature information that is interworked from a non-SBS leg of a call to an SBS leg of a call is transported on the SBS signaling call, and not on the SBS bearer call. Likewise, any feature information that is interworked from an SBS leg of a call to a non-SBS leg of a call is taken from the SBS signaling call, and not from the SBS bearer call.
Two records per SBS call
Any feature that reports or records status for a call can create two different reports or records for a single SBS call. The feature can create one report or record for the signaling trunk, and a second report or record for the bearer trunk. For example, with Call Detail Recording (CDR), the number of reports or records depends on whether both trunks groups are administered to produce call detail records.
Bearer trunk signaling features
Features that require signaling over a non-QSIG type of trunk do not work with SBS calls. The endpoint users are not parties on the SBS bearer call. Therefore, user activity cannot drive any feature signaling on the bearer call. Similarly, any feature signaling that is received on the bearer call cannot drive any notification or displays to the endpoint user. For example, public or private network-specific (non-QSIG) Malicious Call Trace (MCT) network notification and Advice of Charge (AOC) display functionality do not work with SBS calls.
Bearer trunk user features
Features that are related to the SBS bearer call and require activation or acknowledgement from an endpoint user do not work with SBS calls. Such features do not work with SBS calls because the endpoint user is not a party on the bearer call. For example, queuing of the SBS bearer call does not work because the real originating party is not on the bearer call.
Early-answer features
Features that require early answer do not work with SBS calls. Such features do not work with SBS calls because when the signaling call is answered, the bearer call is not started. When the bearer call is first answered, the call is for the SBS extension at the terminating node. For example, authorization code collection on incoming calls and direct calls to remote access does not work with SBS calls.
Network features that send tones when the bearer call answers do not work
Network features that send tones when the bearer call answers do not work with SBS. When the bearer call is answered, the call is for the SBS extension. The final telephone user is not on the call to hear the tones. For example, the user does not hear the dual-tone multifrequency (DTMF) notification when a network call is eligible to be transferred, such as with Take-back and Transfer.
