Hi, Community
I would like to tell you about UC 10.x -> 11.x upgrade (I mean CUCM, UCCX, IM&P, and PLM infrastructure) and ask some questions if you don't mind.
License ordering deserves additional mention but the hell I've passed through to update my licenses is offtopic at the moment. Just use licensing@cisco.com but not PUT and its ticket
system if you are in preparing to similar upgrade.
An upgrade was performed accordingly to migration plan offered by cisco, nothing interesting at this step. After the upgrade, I've faced strange CUCM software MTP behavior: it doesn't
recognize DTMF coming from PSTN anymore (CUBE uses SIP trunking with ISP and ticked as "Media Termination Point Required" in CUCM's trunk) so I cannot call additional extension while
listening UCCX's greating message as I could before. The CUBE configured with rtp-nte DTMF relay and configurations wasn't changed before and after UC upgrade. Re-ordering of MRGL that
attached to SIP trunk and contained both CUCM_MTP and CUBE_MTP to make CUBE_MTP first solved the problem.
Also MRGL that containd MTB and XCODE has changed its behavior. I can't transfer (or put on and off hold) a second call that comes from PSTN: it torns down when I try to get my call
back from holding on my deskphone. It's ok while I call from PSTN to my deskphone: the call is able to be held or transferred. But the second (concurrent) call isn't able to be held or
transferred. My MRGL contains one MRG with XCODE, MTP, and CFB resources registered from CUBE.
I've performed preliminary investigation with RTMT and found that CUCM sends BYE packet to PSTN while transfer/hold off attempt because it couldn't allocate a resource (Q.850;
cause=47). I've decided to run Performance Monitor in RTMT, added AllocatedResourceCannotOpenPort chart for my XCODE device (CUBE) and tried to hold on and off my second call (as I
mentioned before, the first call is always successful and able to be held/transferred). AllocatedResourceCannotOpenPort counter was increased from 0 to 3 while call failing.
Accordingly to SRND, XCODE acts as MTP too, and resource consuming depends on MRG order as you have both MTB and XCODE in the same MRG:
"An MRG may contain multiple types of resources, and the appropriate resource will be allocated
from the group based on the feature needed. MTPs and transcoders are a special case because a
transcoder may also be used as an MTP. For example, when both MTPs and transcoders exist in the
same MRG and an MTP is required, the allocation is done based on the order in which the resources
appear in the MRG. If transcoder devices appear earlier than MTPs in the MRG, transcoder
resources will be allocated for the MTP requirement until the transcoder resources are exhausted and
then the system will start allocating MTPs. For this reason, it is important to consider the order of
resources when creating MRGs and MRGLs."
But MRG doesn't support ordering, only MRGL.
Well, I've tried to diagnose current resource allocation by show dspfarm all command during the call:
SLOT DSP VERSION STATUS CHNL USE TYPE RSC_ID BRIDGE_ID PKTS_TXED PKTS_RXED
0 1 40.2.10 UP N/A FREE xcode 1 - - -
0 1 40.2.10 UP N/A FREE xcode 1 - - -
0 1 40.2.10 UP N/A FREE xcode 1 - - -
0 1 40.2.10 UP N/A FREE xcode 1 - - -
0 1 40.2.10 UP N/A FREE xcode 1 - - -
0 1 40.2.10 UP N/A FREE xcode 1 - - -
0 1 40.2.10 UP N/A FREE xcode 1 - - -
0 1 40.2.10 UP N/A FREE xcode 1 - - -
0 1 40.2.10 UP N/A FREE xcode 1 - - -
0 1 40.2.10 UP N/A FREE xcode 1 - - -
0 1 40.2.10 UP N/A FREE xcode 1 - - -
0 1 40.2.10 UP N/A FREE xcode 1 - - -
0 1 40.2.10 UP N/A FREE xcode 1 - - -
0 1 40.2.10 UP N/A FREE xcode 1 - - -
0 7 40.2.10 UP 1 USED xcode 1 597 571 1403
0 7 40.2.10 UP 1 USED xcode 1 604 1315 571
0 7 40.2.10 UP N/A FREE xcode 1 - - -
0 7 40.2.10 UP N/A FREE xcode 1 - - -
0 7 40.2.10 UP N/A FREE xcode 1 - - -
0 7 40.2.10 UP N/A FREE xcode 1 - - -
0 7 40.2.10 UP N/A FREE xcode 1 - - -
0 7 40.2.10 UP N/A FREE mtp 3 - - -
0 7 40.2.10 UP N/A FREE mtp 3 - - -
0 7 40.2.10 UP N/A FREE mtp 3 - - -
0 7 40.2.10 UP N/A FREE mtp 3 - - -
0 7 40.2.10 UP N/A FREE mtp 3 - - -
0 7 40.2.10 UP N/A FREE mtp 3 - - -
0 7 40.2.10 UP N/A FREE mtp 3 - - -
0 7 40.2.10 UP N/A FREE mtp 3 - - -
0 7 40.2.10 UP N/A FREE mtp 3 - - -
0 7 40.2.10 UP N/A FREE mtp 3 - - -
0 7 40.2.10 UP N/A FREE mtp 3 - - -
0 7 40.2.10 UP N/A FREE mtp 3 - - -
0 7 40.2.10 UP N/A FREE mtp 3 - - -
0 7 40.2.10 UP N/A FREE mtp 3 - - -
0 7 40.2.10 UP N/A FREE mtp 3 - - -
0 8 40.2.10 UP N/A FREE conf 2 - - -
0 8 40.2.10 UP N/A FREE conf 2 - - -
0 8 40.2.10 UP N/A FREE conf 2 - - -
0 8 40.2.10 UP N/A FREE conf 2 - - -
0 8 40.2.10 UP N/A FREE conf 2 - - -
Total number of DSPFARM DSP channel(s) 40
As you can see, there are a lot of free resources to serve second call's hold and transfer, but CUCM wasn't able to perform this.
As I didn't need transcoder between PSTN and my UC, temporary resolution was to delete XCODE resource from MRG attached to PSTN to force CUCM to use MTP that exist in this MRG.
I know the best practices about making MRGL in relation with resource type but not device, but Cisco allows MTP and XCODE combining.
Summing up, do you know why CUCM's software MTP ceased up to recognize DTMF and why CUCM can't allocate more the one XCODE resource to serve a call that requires MTP?
