cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
939
Views
0
Helpful
11
Replies

Number of Phone Licenses Question, Too Many?

A customer's UC560 has 17 phones connected, but only 16 paid licenses.

Will this cause calling issues?

We have advised the customer to upgrade their number of user licenses.

If I can get more info to give the customer to back up that there call issues may be caused because of unauthorized phone(s).

Thank you, Paul

1 Accepted Solution

Accepted Solutions

We do offer 4 extra since we default the FXS to common area type (Only user mode use licenses) + 2 for teleworkers, so 8 gets 14; 16 gets 22.

Steve

View solution in original post

11 Replies 11

Steven DiStefano
VIP Alumni
VIP Alumni

Hi Paul,

I think not.  16 Licenses actually yields more usable SCCP licenses.

Is it possible that the phones are registering, but just have no automatic extension assigned?   We do that on purpose in the latest release.

Is it possible the phone type is built wrong (token error will be seen):

(debug tftp events; debug ephone reg)

But a quick test would be to go to CCA Maintenance Drawer and activate the evaluation license, whoch should crank you up to max capacity for 2 months (time bomb), and if that works, then your right.

Hi Steve,

Does Cisco still offer an extra couple of usable licenses like they once did for every block of 8 that was purchased? For instance if you had an 8 user system you would have 2 spare licenses on the system to allow for 2 CIPC (Or even a normal phone) to connect to the system, I think this was a courtesy thing, but not to sure if you do this anymore.

Also if he had an 16 user license and it was locked down to 16 users and a 17th one was plugged in, wouldnt he get an authorisation error message on the screen?

Cheers,

David.

Cheers, David Trad. **When you rate a persons post, you are indicating a thank you or that it helped, but at the same time you are also helping to maintain the community spirit - You don't have to rate posts and you wont be looked down upon :) *

We do offer 4 extra since we default the FXS to common area type (Only user mode use licenses) + 2 for teleworkers, so 8 gets 14; 16 gets 22.

Steve

Hi Steven,

Thank you for clarifying that this is still the case, good to see it

Cheers,

David.

Cheers, David Trad. **When you rate a persons post, you are indicating a thank you or that it helped, but at the same time you are also helping to maintain the community spirit - You don't have to rate posts and you wont be looked down upon :) *

rcastill
Level 1
Level 1

This will absolutely be an issue for your customer.  Enable the evaluation licensing in CCA under license management and tell the customer to order additional licensing.  By enabling the evaluation licensing you will give your customer 8 weeks and 4 days to still use the phone while they are waiting for licensing. Click on the image below for a more detailed view.

Steven and all, thank you for your responses.  I really appreciate this

Community Site for this reason.

To clarify, the 17th phone does register, pull an extension and work fine.

They also have a remote warehouse that has 2 phones/extensions registering to the

UC560 via a 871 and VPN.

I think now that the number of phones is not causing the issue.

The issue being when a user goes to make an outbound call there is a long pause then a busy signal.


If they retry the call will go out and ring fine.  Now that I can eliminate the licenses as a cause I will

look at the voice circuit provider.

Thank you again for clearing this matter up.  Paul

Hi Paul,

The issue being when a user goes to make an outbound call there is a long pause then a busy signal.

I may have missed this but what type of service is being delivered to you?

If they retry the call will go out and ring fine.  Now that I can eliminate the licenses as a cause I will

look at the voice circuit provider.

I see this happen all the time on ISDN services where the carrier sometimes does not provision the circuit to have layer one always active (Or Up), and this sometimes results in call attempts not making it through, but an immediate redial get through as the channel becomes active, ok for old legacy systems but not so good with digital systems such as the Cisco.

In any even you should debug the issue (Either yourself or with the assistance of support) and then notify the carrier if it is a layer issue, this way when you go to them you are armed with information and they can not blame the system as they like to do from time to time.

Cheers,

David.

Cheers, David Trad. **When you rate a persons post, you are indicating a thank you or that it helped, but at the same time you are also helping to maintain the community spirit - You don't have to rate posts and you wont be looked down upon :) *

David, the hand off is a SIP trunk.

Which "debug" in CCA would give the best info for Support?

Troubleshoot:  VOice Debug Log:  Voip(SIP)  <-- just cloick that box and apply.

It sets up the Logging"

config t
no logging console
no logging monitor
no logging rate-limit
no logging queue-limit
service timestamps debug datetime localtime msec
logging buffered 1000000 debugging
end

And then enables all these debugs.

UC_560#sh debug

DIALPEER:

  debug voip dialpeer error call is ON (filter is OFF)

  debug voip dialpeer error call informational is ON (filter is OFF)

  debug voip dialpeer error software is ON

  debug voip dialpeer error software informational is ON

  debug voip dialpeer function is ON (filter is OFF)

  debug voip dialpeer inout is ON (filter is OFF)

  debug voip dialpeer detail is ON (filter is OFF)

voip translation-rule

  voip translation debugging is on (Filter is OFF)

CCAPI:

  debug voip ccapi error call is ON (filter is OFF)

  debug voip ccapi error software is ON

  debug voip ccapi inout is ON (filter is OFF)

VOIP RTP ALL Named Events debugging is on

CCSIP SPI: SIP Call Message tracing is enabled  (filter is OFF)

Then make the call and Click Generate Troubleshooting Log when complete, then OK (which turns it all off).

Steve

Steven, I applied the debugs.  I had someone there make calls.

They said that out of 5 calls 2 did the "silence then busy signal"

I am attaching the log file.  Let me know if you see anything.

Regards, Paul

Paul,

I see they didnt use CCA and tried to paste in the output of "sh debug" into the CLI.

That wont work for all of it.  So data is missing.  SBSC or TAC will need the whole trace with a logged case.

I also see that they never turned off logging.  PLEASE have them get back in and do a ''undebug all" ASAP.

This could have devastating consequence.

I did see a Cause code 17

in there:

Cause No. 17 - user busy.

This cause is used to indicate that the called party is unable to  accept another call because the user busy condition has been  encountered. This cause value may be generated by the called user or by  the network. In the case of user determined user busy it is noted that  the user equipment is compatible with the call.What is means:  Calling end is busy.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: