Cisco Cisco Customer Voice Portal 8.0(1) Release Notes
Release Notes for Cisco Unified Customer Voice Portal, Release 7.0(2)
14
You can mitigate this MTP usage with a "dual SIP Trunk" configuration. The first
CVP/CUPS SIP Trunk with MTP *unchecked* and the second SIP Trunk with MTP
checked to the same CVP/CUPS destination. The VRU label route pattern should be
applied 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.
When a warm transfer with no queuing (ie no vru label + corr id) is performed, there will
be no second call from the trunk to Unified CVP. There will only be the SIP reinvite to
the caller on the transfer completion. The MTP outbound call is only made when EAPIM
VRU label is routed out the trunk to Unified CVP, ie the outbound call.
For the above to work, it is necessary 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, but change the Listen Port to something else, like 5065. Now on the
second trunk that has the MTP, apply this security profile, and reset both SIP Trunks.
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.
IOS-based Hardware MTP should be used over CUCM Software MTP for performance
considerations.
CVP/CUPS SIP Trunk with MTP *unchecked* and the second SIP Trunk with MTP
checked to the same CVP/CUPS destination. The VRU label route pattern should be
applied 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.
When a warm transfer with no queuing (ie no vru label + corr id) is performed, there will
be no second call from the trunk to Unified CVP. There will only be the SIP reinvite to
the caller on the transfer completion. The MTP outbound call is only made when EAPIM
VRU label is routed out the trunk to Unified CVP, ie the outbound call.
For the above to work, it is necessary 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, but change the Listen Port to something else, like 5065. Now on the
second trunk that has the MTP, apply this security profile, and reset both SIP Trunks.
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.
IOS-based Hardware MTP should be used over CUCM Software MTP for performance
considerations.
The Takeback-and-Transfer (TNT) feature is not supported with the SigDigit feature.
CVP does not support T.38. When implementing FAX services within the CVP
environment you must match FAX calls with separate dial-peers on the ingress GW and
send the call to the relevant call control entity - either CUCM or FAX server directly.
environment you must match FAX calls with separate dial-peers on the ingress GW and
send the call to the relevant call control entity - either CUCM or FAX server directly.
The RAI logic in CVP depends on four different parameters:
RAIThreshold
maxTotalCalls
maxIVRPorts