Problem Statement
There might be a situation where doing a consultative transfer, you might either get dead air, or the call will drop. This happens when the agent completes the transfer while the caller is still in queue. It causes the mid call media change for the voice browser on the VXML gateway, which currently not supported by the VXML gateway.
This situation is referenced in defect CSCsm12716 - Mid Call Reinvites Not Handled By IVR Application On VXML Gateway.
This is also mentioned in the CVP 7.0(2) Release Notes
Release-Notes discuss this issue in more details and have a detailed workaround as well.
Conditions
Please note that
- MTP on SIP Trunk is not required for the blind transfers (with or without the ICM "network transfer").
- This problem doesn't happen with H.323 trunks so MTP is not required on H.323 trunks
- MTP can get allocated on a SIP Trunk call automatically, even if you have it disabled. This can happen when DTMF capabilities mismatch is detected by SIP Trunk.
- This problem doesn't happen for ICM Network Transfer Scenarios
Solution 1
This defect is resolved now. And the solution is to upgrade the gateway to the fixed version mentioned in the bug toolkit.
Solution 2
You can mitigate MTP usage by setting the CVP/CUPS SIP Trunk with MTP **unchecked**. Create a second SIP Trunk with MTP checked to the same CVP/CUPS destination, then put the VRU label route pattern on this MTP trunk. This will allow you to only use MTP allocation on the warm transfers with queueing. All the inbound calls will avoid MTP allocation.
CVP/CUPS-----inbound call/MTP unchecked----->CUCM
CVP/CUPS<----warm transfer/first agent completes transfer/MTP Checked-----CUCM (VRU lable/5065 listen Port)
You need to create an alternate SIP Trunk Security Profile, apart from the default one "non secure sip security profile". Use all the same settings as the default one, just change the Listen Port to something else, like 5065. Now on your second trunk that has the MTP, apply this security profile, and reset it.
The reason for this is because you cannot create 2 duplicate sip trunks in CUCM with the same host/ip and listen port. Again, you are never using this trunk for inbound calls, so you never need to make a static route from CUPS/CVP to port 5065 for example.
Just use 5060 that is associated on the other non-MTP trunk. Also, if you are going to have other DNs for the IP originated callers, not the warm transfer with queuing calls, then use the non-MTP trunk on that route pattern.
Hardware MTP is suggested over Software MTP for performance considerations.
