Implementation guidelines for local treatment vectors

Last Updated : Aug 27, 2019 |
Important:
Read the guidelines before you implement the local treatment feature.
Implementation of the local treatment feature requires use of specific vector steps to generate the correct ISDN or SIP messages between the local and remote Communication Manager.
For polling vectors: You must be careful to administer your local treatment polling vectors so that calls are not unintentionally dropped or phantom calls are generated. If the queue-to best step is followed by vector steps that include any commands other than announcement, wait, or goto, the trunk to the remote queue are dropped. For example, the addition of consider steps after a queue-to best command can cause intermittent call behavior. The addition of a queue-to step after a queue-to best step can cause phantom calls to be queued to the remote server.
Tip:
You can also exploit this functionality to allow the local server to take back calls that remain in queue on a remote server after a specified time limit is exceeded. For more information, see the Take back example in the example vector for local Communication Manager.
Interflow local treatment vectors on the remote Communication Manager: When the BSR Local Treatment feature is enabled, specific ISDN or SIP messages must be exchanged between the remote and local Communication Manager. If additional vector steps are included either before or after the consider steps and queue-to best in the interflow vector on the remote server, the following results occur:
  • Either an ALERTING or PROGRESS message, with in-band information, is returned from the remote server to the local server.
  • In response to the message, trunk bandwidth is immediately allocated and the call is removed from the local queue.
  • Local treatment operations cease, trunk bearer resources are allocated for the call sooner than required and cost savings associated with the local treatment feature are not realized.