cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
729
Views
3
Helpful
16
Replies

Shortage of "CUBE v14 Trunk Standard Session" license' alert

mm322
Level 1
Level 1

Migrating our customer to a new UC infrastructure made up by CUCM 14 + a number of CUBEs (ISR4331).

The ISRs were originally configured as H323 Gateway on the CUCM 11.5 still in production, and were upgraded to version 17.06.‎06a. which required to configure SIP trunks instead of H323 original configuration (as per 'End of Support for the H.323 call control features in Cisco IOS XE Software' note - https://www.cisco.com/c/en/us/products/collateral/unified-communications/unified-border-element/bulletin-c25-2479306.html).

Testing has been done for weeks on an ISR router with active ISDN connections, many calls to and from PSTN were placed and configurations were tuned up based on that.

Now, around one month ago another one of such ISRs entered the production phase: everything works fine, but it was noticed that on the CSSM licensing portal a 'The Virtual Account "XXXXX" reported a shortage of 1 "CUBE v14 Trunk Standard Session" license' alert is showing up.

Such kind of alert never showed up on the test-ISR and we are wondering why.

It may depends on the amount of concurrent calls (anyway much lower for the test-ISR than the ISR now in production), or perhaps there may be some different configuration between the two which in case is not easy to understand.

Also, in case the customer does not want to purchase new licenses, should we go back to Cisco IOS XE Bengaluru 17.5 and h323 configuration?

Attempted to find out more with the help of show voice sip license status and show voice sip license stats but the outputs do not appear that easy to understand.

Any tip or possibly easy explanation on how CUBE v14 Trunk Standard Session license mechanism works?

To how many concurrent calls corresponds 1 license usage (which is what we show on the CSSM)?

What may (or may not) triggers such kind of alert?

Thanks for your help.

1 Accepted Solution

Accepted Solutions

Jonathan Schulenberg
Hall of Fame
Hall of Fame

 

CUBE trunk licenses are consumed per-concurrent call. If you enabled CUBE functionality (mode border-element) and a call matches VoIP dial-peers for the incoming and outgoing call legs, a CUBE license is consumed. My shot-in-the-dark guess is that CUCM sent the router a call that also matched the CUCM-facing dial-peers. CUCM hopefully denied that to prevent a loop from forming but the CUBE license would already have been consumed by that point.

Reverting to H.323 would be very shortsighted in my opinion. IOS XE 17.5 has already reached end of software maintenance - so no further bug or vulnerability fixes.

PS- CUCM 11.5 has reached end of support. Upgrade to 15 or migrate to Webex Calling.

View solution in original post

16 Replies 16

Thanks jrsteele21 I'll have definitely a look into it!

Jonathan Schulenberg
Hall of Fame
Hall of Fame

 

CUBE trunk licenses are consumed per-concurrent call. If you enabled CUBE functionality (mode border-element) and a call matches VoIP dial-peers for the incoming and outgoing call legs, a CUBE license is consumed. My shot-in-the-dark guess is that CUCM sent the router a call that also matched the CUCM-facing dial-peers. CUCM hopefully denied that to prevent a loop from forming but the CUBE license would already have been consumed by that point.

Reverting to H.323 would be very shortsighted in my opinion. IOS XE 17.5 has already reached end of software maintenance - so no further bug or vulnerability fixes.

PS- CUCM 11.5 has reached end of support. Upgrade to 15 or migrate to Webex Calling.

Thanks Jonathan! I absolutely woud love staying on SIP and rolling back to H323 is the worst case scenario.

Mode border-element line is actually not included in the configuration.

"%CALL_CONTROL-6-CALL_LOOP: The incoming call has a global identifier already present in the list of currently handled calls. It is being refused." was noticed in the output of the show logging and being investigated either.

In your opinion could this be related with the license consumption in question?

PS Jonathan as I am sure you understood already I have limited skills on call routing on ISRs and dial-peers: can I ask you to give me an example of a desired case in which "a call matches VoIP dial-peers for the incoming and outgoing call legs"?

Inbound it would be recommended to use information in the VIA header to match the inbound dial peer and then if you'd want to not run the risk of call loops I would either use Dial Peer Group, DPG in short, or use COR to limit the dial peer(s) that can be used in each direction. Have a look at this document for more information on how call routing operates in IOS. Explain Cisco IOS and IOS XE Call Routing 



Response Signature


Thanks Roger, will look into the doc that you shared!

Jonathan, your tip was the good one: I managed to remove the call loop which I found in the logs, and the alert on CSSM is gone.

We have a dial-peer going to the ISR itself for when SRST mode is active, and for a specific number only that dial-peer was matched causing a loop.

Fixed that by assigning a preference to such dial-peer.

Still to be tuned up though as preference not always offer an exact match of calls intended to SRST and those to CUCM.

Thanks!

PS added voice-class sip options-keepalive command to the dial-peers with CUCM nodes so that in case of CUCM being unreachable from the branch, those dial-peers should not be matched. Hopefully it should do the job.

Can you please share a little more detail on this “We have a dial-peer going to the ISR itself for when SRST mode is active”? What do you mean by that?



Response Signature


We have 4 dial-peers matching the E164 pattern 12345XXX and sending the calls to the CUCM nodes in normal operation conditions.

Now as the ISR acts also as a SRST server, it was configured one dial-peer matching the above E164 pattern 12345XXX but sending calls to the ISR itself for when the CUCM is not reachable.

 

If the devices that have the E164 patterns 12345XXX register to the gateway when they are in SRST state there should be no need to have a dial peer that hair-pins the call to the gateway itself.



Response Signature


Got your point Roger, but in that case the translation from E164 12345XXX to internal pattern XXXX should occur on the ISR and not on the CUCM (as per the configuration found), correct?

That is absolutely correct. When you have SRST in the mix you should be doing any translation of phone numbers on ingress from PSTN in the gateway. Best would in fact be if you were to use directory numbers in +E.164 format and then if you have a short number call format you’ll put that as an overlay on top of your E.164 numbers.



Response Signature