juice-qr
asked on
cisco UC560 - new extension can't dial out
Our Cisco ucs560 is working fine, today I needed to add a few new users, our internal user extensions use the range 820 thru 867 or so. I added the new extensions 880-884. Internal calls back and forth between these new extensions and other existing extensions (820-867) work fine. Incoming DID calls also route just fine to these new 880-883 ext's.
However from an 880-883 extension, I'm not able to press 9 and dial out, when dialing 9, then a 1+10 digit outside # (or even without the 1, which works fine on all other exts), I just get a dial tone, then a fast busy instead of the system accessing our t1 trunk and dialing out like all other existing ext's do.
I've added lots of new users and extensions before with no problem. Could it be due to the fact that these new extensions use the format 88x ? edit - I tried adding a new 84x extension, and the same behavior occurs, so it's not related to the 88x numbering. It's something to do with a new extension that the system hasn't used before.
Outgoing calls accessing the trunk is the only issue, feel like I've just missed something simple.
However from an 880-883 extension, I'm not able to press 9 and dial out, when dialing 9, then a 1+10 digit outside # (or even without the 1, which works fine on all other exts), I just get a dial tone, then a fast busy instead of the system accessing our t1 trunk and dialing out like all other existing ext's do.
I've added lots of new users and extensions before with no problem. Could it be due to the fact that these new extensions use the format 88x ? edit - I tried adding a new 84x extension, and the same behavior occurs, so it's not related to the 88x numbering. It's something to do with a new extension that the system hasn't used before.
Outgoing calls accessing the trunk is the only issue, feel like I've just missed something simple.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Check the extension setting to make sure it is not limited (permissions) there are seven options:
Internal (I think this is the only one that will restrict the user from dialing 9)
Local
Local-plus
The above two may cause the fast busy
National
National-plus
International
Unrestricted
Another thought for fast busy, you might exceed the available simultaneous sessions.
How many simultaneous calls are you provided?
Internal (I think this is the only one that will restrict the user from dialing 9)
Local
Local-plus
The above two may cause the fast busy
National
National-plus
International
Unrestricted
Another thought for fast busy, you might exceed the available simultaneous sessions.
How many simultaneous calls are you provided?
ASKER
Thanks, the fast busy doesn't occur immediately ... there are about 10 secs of just 'dial tone' after the pstn # is dialed from these ext's, then the fast busy happens.
When I wast testing these, it was after hours, my test outgoing call would have been the only call going on in the system, we have a small office.
When I wast testing these, it was after hours, my test outgoing call would have been the only call going on in the system, we have a small office.
A fast busy means that there is a problem. you can use debug to see what is going on when you dial out.
What is your default permission settings on the extension? unrestricted, local, local plus, national, national plus?
Do you have all extensions that are working mapped to a callerID in the outgoing dial plan?
Double check whether your outgoing dialplan's default caller ID is no longer "valid" this too will lead to a fast busy as the vendor will deny the establishment of the call (they often enforce the no spoofing) by only allowing CallerIDs based on the allocated numbers that you have.
What is your default permission settings on the extension? unrestricted, local, local plus, national, national plus?
Do you have all extensions that are working mapped to a callerID in the outgoing dial plan?
Double check whether your outgoing dialplan's default caller ID is no longer "valid" this too will lead to a fast busy as the vendor will deny the establishment of the call (they often enforce the no spoofing) by only allowing CallerIDs based on the allocated numbers that you have.
ASKER
Not sure where to find the default permissions on the extension, where would that be at ?
Yep, all extensions that are working for dialing outbound to pstn do have their own outgoing DiD assigned. So that leads me to belive that's the issue here. (The new ext's don't have an outgoing DiD specifically assigned)
Thanks
Yep, all extensions that are working for dialing outbound to pstn do have their own outgoing DiD assigned. So that leads me to belive that's the issue here. (The new ext's don't have an outgoing DiD specifically assigned)
Thanks
In CCA, when configuring the phone/extension select the extension in question and you will see on the right where you have the options for the call options. Then you have permissions and how/what the behavior should be when call no answer, busy, etc.
Do not think there is a CCA set default permissions.
Double check the default CALLER ID and make sure it is still VALID for the organization.
I.e. it should be the main number (realize that you know that, but want to be thorough should someone else references this when they are troubleshooting their own issues.).
Do not think there is a CCA set default permissions.
Double check the default CALLER ID and make sure it is still VALID for the organization.
I.e. it should be the main number (realize that you know that, but want to be thorough should someone else references this when they are troubleshooting their own issues.).
ASKER
On our extensions, the permission is 'unrestricted' on all of them.
Our default caller id is our main # ... so that seems correct. Not sure why new ext's wouldn't use that as the default, like the text says in CCA.
Well, I'll confirm in the am if that is in fact the issue. (new ext's need specific outgoing DiD's set to override the default)
Thanks
Our default caller id is our main # ... so that seems correct. Not sure why new ext's wouldn't use that as the default, like the text says in CCA.
Well, I'll confirm in the am if that is in fact the issue. (new ext's need specific outgoing DiD's set to override the default)
Thanks
ASKER
Just called the # that I THOUGHT was one of our main #'s ... turns out I get 'you have reached a non working #' ... Well duhh !!! That explains a few things.
So for some reason the # that I thought would be the default for outgoing (and that CCA says is the default outgoing) is either not provisioned or is not configured in our ucs560 ...
Thanks for the insight on this !
So for some reason the # that I thought would be the default for outgoing (and that CCA says is the default outgoing) is either not provisioned or is not configured in our ucs560 ...
Thanks for the insight on this !
No doubt we all run into these things, where someone else makes a determination that a number, a resource is no longer needed and "forgets" to let us know. Then they wonder how come stuff is not working today while it worked without any issues yesterday.
"Wild Goose chase, begins"
"Wild Goose chase, begins"
ASKER
Agreed.
I thought on this some more, the fact that I can't dial the # in question (the DiD that is set for default outgoing), just means that it doesn't have an ext assigned where it'll ring to. That doesn't necessarily mean that it's not assigned to our org ...
Anyway, hopefully this is the quick fix tomm am, just assign an outgoing DiD for these new ext's.
I thought on this some more, the fact that I can't dial the # in question (the DiD that is set for default outgoing), just means that it doesn't have an ext assigned where it'll ring to. That doesn't necessarily mean that it's not assigned to our org ...
Anyway, hopefully this is the quick fix tomm am, just assign an outgoing DiD for these new ext's.
A fast BUSY means that your provider does not allow for the establishment of the outgoing call. Even if the number has no inbound handling, as far as the provider is concerned it is a valid number for the organization and should not have an issue to be used as an outgoing number
Try to assign the outgoing CALLER ID to one of the newly created extensions on the incoming dial plan handling and see whether it is or is not a functional number for your organization.
and try calling it again. See if the behavior changes.
Try to assign the outgoing CALLER ID to one of the newly created extensions on the incoming dial plan handling and see whether it is or is not a functional number for your organization.
and try calling it again. See if the behavior changes.
ASKER
Yep, will test that tomm. Thanks!
ASKER
Thanks!
ASKER
Adding dedicated DiD #'s for outgoing caller id was the fix on this, confirmed this am.
Curiously it seems I'm only able to add 14 dedicated outgoing caller id's ? With the 4 new ext's, when I went to add the 4th, the 'add' button was grayed out!
Curiously it seems I'm only able to add 14 dedicated outgoing caller id's ? With the 4 new ext's, when I went to add the 4th, the 'add' button was grayed out!
ASKER
From what I've found online, looks like CCA is limited to 14 outgoing caller id overrides. Up to 100 can be added via cli apparently.
ASKER
I do use CCA to configure the system. On the outgoing dial plan it says there is a default caller id for that trunk that'll be used if one isn't assigned, I wonder why it doesn't just use that?
I'll try assigning a specific cid for these new extensions tomm. But that would match up with my troubleshooting so far, all extensions that have been assigned an outgoing cid can call out no problem, it's only these new ext's that don't have one assigned that are having trouble.
Thanks