Applying Audio Tones
Audio tones can be generated either as all-party consent or one-party consent:
- All-party consent requires that all parties in the call being recorded to hear the audio tone periodically.
- One-party consent requires one of the parties in the call to hear the audio tone. The consent is configurable on Media Server.
There is a difference between all-consent/one-party-consent and applying the beep to certain calls:
- All-consent/one-party-consent setting is a global system setting on the MCP process.
- Applying a beep to certain calls can be done one of two ways:
- Use a recording rule (for example, with Zoom) to add the beep src URI in the Tlib call to SIP Server to trigger the beep tone for a specific call.
- Set up a separate tenant SIP Server that maps to a different GVP IVR Profile that controls the beep tone settings for that tenant.
When additional recording parameters are included when the MSML conference is instantiated, Media Server can apply the periodic audio tone. Additional states are kept in Media Server to keep track of the audio tone to be applied to the call.
Note: This is a custom Genesys extension to MSML conference to apply the audio tone.
The following parameters are configurable in the deployment and they follow the same conventions used for other parameters that can be applied to call recording. These parameters can be set either in the IVR Profile as service parameters, or as extensions in RequestPrivateService.
|Audiosrc|| The URI of the audio tone.If the URI resolves to a bad URI, then no audio tone is applied to the call, and recording error is notified to SIP server. If empty or not present then the recording will proceed without a tone.
|Tonesilenceduration||The length of time, in milliseconds, between playing the audio tone. This is a mandatory parameter if the audiosrc parameter is defined, otherwise no audio tone is applied. The minimum accepted value is 1500 (if a smaller value is specified, 1500 will be used). Also, if the tonesilenceduration parameter is not present, MCP applies the default value of 30000 instead of not applying tone.|
These parameters can be passed as additional parameters in RequestPrivateService (AttrExtensions). For example:
‘rec ord’ ‘source’
The MSML code snippet would show as follows:
<msml> <createconference name=”recorder”> <gvp:recorder> <gvp:params> <gvp:param name=”record”>source</gvp:param> <gvp:param name=”id”>2134980asdf320990adsflkjag</gvp:param> <gvp:param name=”dest”>sip:10.0.0.101</gvp:param> <gvp:param name=”name”>value</gvp:param> <gvp:param name=”audiosrc”>http://example.com/tone.wav</gvp:param> <gvp:param name=”tonesilenceduration”>30000</gvp:param> <gvp:param name=”recordDN”>9000</gvp:param> </gvp:params> </gvp:recorder> </createconference> <join id1=”conf:recorder” id2=”conn:1234”/> <join id1=”conf:recorder” id2=”conn:2345”/> </msml>
The same parameters can also be configured as service parameters in the IVR Profile. When the parameters are configured in the IVR Profile, they are treated as the default values for the IVR Profile, and the parameters can be overridden by AttrExtensions in the RequestPrivateService event on a per-call basis.
For example, the IVR Profile contains the gvp.service-parameters section with the following parameters:
Whenever Resource Manager passes the initial INVITE from SIP Server for instantiating the call recording, Resource Manager will insert the service parameters as additional request URI parameters:
The parameters defined in the Request URI are considered as <gvp:param> in the MSML message for the conference. Media Server takes the parameters in Request URI first and then the parameters in <gvp:param> overrides the parameters in the Request URI. This means that the parameters defined in the TrequestPrivateService event has higher precedence than those defined in IVR Profile.
Other Media server considerations:
- When the recording is paused, no audio tone is generated.
- When the recording is resumed, the audio tone is applied.