Cisco Cisco MediaSense Release 9.1(1) Guia Do Desenho

Página de 39
One of the great advantages of using CUBE to fork media is its ability to capture the entire conversation from the caller's perspective, no
matter where the call goes inside the enterprise.  That includes contact center agents, non-contact center personnel, IVR systems, and even
users on non-Cisco ACD and PBX systems.
The above diagram shows three ways in which Cisco MediaSense and CUBE may be deployed in a heterogeneous enterprise environment. 
Any given call might experience one or a combination of these flows, and the entire caller's experience will be recorded.  Additional
combination are possible as well; for example a call may be handled by an IP-based or TDM-based IVR system.
II (d). CUBE Deployment Variation: Using TDM Ingress
In order to fork media, CUBE must be dealing with a SIP to SIP call.  If calls are arriving via TDM, then a separate TDM gateway should be
provisioned as shown in the diagram above.  Forking should then be configured as usual on the outside dial peer of the CUBE.
If your application is designed to transmit DTMF signals to the PSTN, such as to perform PSTN-controlled transfers (also known as *8
Transfer Connect), then you must ensure that both the CUBE and the TDM gateway are configured to use the same method for DTMF
signaling.  You can do so by adding the same "dtmf-relay" configuration to the connecting dial peers in both devices.  Relay type "rtp-nte" is
the most standard, preferred method.  The dial peer going to CVP should also be configured with rtp-nte.
III. CUBE Deployments with CVP