How audio forking affects audio routing
The configuration settings that affect audio routing the most are those that configure Voice Platform for audio forking. These are relevant only for bridged transfers in SIP deployments. NMS deployments do not need audio forking.
In a bridged transfer, the caller (party A) calls Voice Platform, Voice Platform connects the caller to the called party (party C) but stays connected to both callers, creating a bridge between the two. By default, audio is routed only between the two parties during the bridge. Audio forking enables Voice Platform to receive audio from one of the parties during the bridge. This is needed for:
- Recognizing a hot word: A hot word is a specific word or phrase that, once recognized, ends the bridged transfer and resumes the dialog between party A and the application (Voice Platform). Hot word occurs by default on party A (near end). To specify hot word on party C (far end), set the farendhotword attribute to true on the <transfer> element.
- Recording audio during the bridge in a whole call recording: Whole call recordings contain the contents of an entire call. By default, the recording includes audio from party A and Voice Platform before and after the bridged transfer, and only warning audio from Voice Platform during the bridge, if enabled. If warning audio is not enabled, the recording contains only silence during the bridge.
With audio forking enabled on Voice Platform, the recording captures party A’s audio during the bridge (default). If far-end hot word is also enabled, party C’s audio is captured during the bridge, as well as audio captured from party A.
To enable whole call recording, set server.rtp.wcr.enable to 1 on the Advanced tab for the Speech Server.
- Detecting tones on bridged transfers: By setting the devicedetection attribute on the <transfer> element, an application can detect if a call was answered by a supported tone. See Tone detection for more information. Note that if you have enabled whole call recording, audio from both parties is captured during the bridge.
There are two types of audio forking and they are distinguished by what component performs forking:
- Gateway forking: Gateway forks audio to two destinations. You must configure Voice Platform to receive forked audio from the gateway. You can do this statically or dynamically (described later).
- RTP bridging: Gateway doesn’t fork audio. You must configure Voice Platform to bridge the parties and fork the audio. You can do this statically or dynamically (described later).
These illustrations show the differences and what happens if you fail to configure Voice Platform to support audio forking.
Gateway forking
This illustration shows audio routing when the gateway supports audio forking and can route audio from party A to party C and Voice Platform. Below, Voice Platform is configured to receive forked audio from the gateway and monitors party A for hot word (default). If whole call recording is enabled, party A’s audio is captured during the bridge.
Note: If far-end hot word is enabled (not shown), party C’s audio is also captured during the bridge.
RTP bridging
This illustration shows audio routing when the gateway doesn’t support audio forking, but Voice Platform is configured to provide this function with RTP bridging. The Telephony Session service bridges the two parties and forks audio to the Speech Server for hot word recognition. If whole call recording is enabled, party A’s audio is captured during the bridge.
Note: If far-end hot word is enabled (not shown), party C’s audio is also captured during the bridge.
No gateway forking, no RTP bridging
This illustration shows the impact on audio routing when the gateway doesn’t support audio forking and Voice Platform is not configured to provide this function with RTP bridging:
- Hot word recognition isn’t possible.
- If whole call recording is enabled, the recording contains silence or Voice Platform warning audio, if enabled, during the bridge.
- Tone detection is not supported. The bridge transfer continues normally as if devicedetection wasn’t set on the call transfer.
Static audio forking
If your system receives inbound calls from a single gateway model or it does outbound calling, Nuance recommends you configure Voice Platform for static audio forking. Voice Platform uses the same forking method—either gateway audio forking or RTP bridging—for all calls coming in or going out.
If the gateway performs audio forking, set ts.APSIPGatewaySupportsForking to TRUE (and leave ts.RTPBridge to FALSE) on the Telephony Session service. The gateway bridges the audio between parties A and C and also sends audio to Voice Platform. See Gateway forking for an illustration.
If the gateway doesn’t perform audio forking, set ts.RTPBridge to TRUE (and leave ts.APSIPGatewaySupportsForking to FALSE) on the Telephony Session service. Voice Platform bridges the audio between the two parties and forks the audio. See RTP bridging for an illustration.
Dynamic audio forking
If your system receives inbound calls from multiple gateway models, Nuance recommends you configure Voice Platform for dynamic audio forking. Voice Platform determines the type of gateway sending the call and uses the appropriate forking method. For example, if one gateway model supports audio forking but the others do not, Voice Platform can set gateway forking for this gateway model and RTP bridging for the others.
To enable, set these service properties on the Advanced tab for the Telephony Session service:
|
Service property |
Description |
Default |
|---|---|---|
|
Enables Voice Platform to determine the appropriate forking method based on the gateway model. |
DISABLED |
|
|
Substring or specific model name and version of gateway that supports audio forking. The gateway identifies itself in the User-Agent header on the initial INVITE. If Voice Platform finds a match in the header, it uses audio forking on all calls coming from this gateway. Used only when ts.DynamicRTPMode = ALLOW_BRIDGING or DISALLOW_BRIDGING. The default value of IOS covers all gateway models having this substring as part of the name and version, for example:
|
IOS |
Outbound calls
Outbound calls cannot use dynamic audio forking since Voice Platform doesn’t know the gateway model at the time of the call. For these calls, set the appropriate service property to TRUE: ts.APSIPGatewaySupportsForking or ts.RTPBridge. You can still use dynamic audio forking for inbound calls.
Examples
These examples show the results of different scenarios:
|
Settings |
Results |
|---|---|
|
|
|
|
|
|
