Avaya Communication Manager Administrator's Manual page 1660

Feature Reference
Separation of Bearer and Signaling
Two important facts related to the internal configuration of an SBS call are:
1
The SBS Bearer and SBS Signaling calls will be tracked internally as separate calls for the life of
the SBS call. Separate call records will be created internally for each call. This is necessary to
allow the SBS Bearer call to be carried over almost any type of trunk, utilizing the standard call
establishment and tear down code for that trunk type. This would not be possible if the bearer
trunk were somehow "buried" as a non-standard party in a "merged" signaling/bearer call record.
2
The endpoint users will be parties on the SBS Signaling call, not on the SBS bearer call. Another
way to look at this is the SBS Signaling call will be the "controlling" call. This is necessary to
support QSIG functionality on SBS calls. Since endpoint user activity drives QSIG signaling only
if a QSIG trunk is a party on the call, the SBS Signaling call must be the controlling call. A QSIG
trunk is only guaranteed if the endpoint user is associated with the SBS trunk, not with the bearer
trunk.
Understanding Potential Interactions
Given these two facts, 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 will simply work as they would 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 and is not specifically mentioned in the feature interaction sections that follow.
•
Call status: Any query or report related to an endpoint user on an SBS call will indicate the call
ID of the SBS signaling call, and will indicate the trunk ID of the signaling (not the bearer) trunk.
An example of this would be the status station x command. This command issued against a station
on an SBS call would show the station connected to an SBS trunk.
•
Feature signaling interworks to/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 will be transported on the SBS
signaling call, not on the SBS bearer call. Likewise, any feature information interworked from an
SBS leg of a call to a non-SBS leg of a call will be taken from the SBS signaling call, not from the
SBS bearer call.
•
Two records per SBS call: Any feature that reports or records status for a call potentially will
create two different reports or records for a single SBS call, one report or record for each leg
(signaling and bearer) of the call. An example of this would be Call Detail Recording (CDR). In
the CDR example, the result will depend on whether both trunks groups are administered to
produce call detail records.
•
Bearer trunk signaling features will not work: Features that require signaling over a non-QSIG
type trunk will not work with SBS calls. The endpoint users will not be parties on the SBS Bearer
call, and so 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/displays to the
endpoint user(s). For example, public or private network-specific (non-QSIG) Malicious Call
Trace network notification and Advice of Charge Display functionality will not work with SBS
calls.
•
Bearer trunk user features will not work: Features related to the SBS Bearer call that require
activation or acknowledgement from an endpoint user cannot work with SBS calls, because the
endpoint user is not a party on the bearer call. For example, queuing of the SBS Bearer call will
not work because the real originating party is not on the bearer call.
1660 Administrator's Guide for Avaya Communication Manager
November 2003