cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1468
Views
20
Helpful
8
Replies

CCA 3.2 Multisite - Better but still unsuitable

Scott Martin
Level 1
Level 1

CCA 3.2 adds a new feature allowing you to separate the VPN and inter-site dialling, which is a welcome change, as many of our customers have an MPLS network and don't require the VPN.

While this is great, most of my clients use 3-digit inter-site extension based dialling. Unfortunately this is not supported by CCA.

For example, a multisite setup as follows, we assign unique 3-digit extension ranges accordingly:

Site A: 300-399

Site B: 400-499

Site C: 500-599

Site B: 600-699 etc.

We also match our ISDN indial ranges to the extension numbers to keep things nice and simple. I notice that this is now no longer supported in CCA - which now requires you to map each and every individual DID - it's a lot of fun with 100 number ranges...

By keeping the extension ranges different for each site, it means there is no requirement for an inter-site dialling prefix, as we simply use a dial-peer to route the calls to the appropriate site.

I am wondering, are we the only partner that does this? Cisco seemed to think I was mad when I provided feedback. I just don't see the need for a dialing prefix - the system only supports 100 or so extensions per site anyway!

Also, as Cisco have advised that the 'out of band' config guides will not be updated, I'm taking a punt and putting all these dial-peers in the 5000+ range. I hope that CCA doesn't magically start using this range, but without an out of band guide, there is no way to know.

I can understand the reason for CCA to have a set configuration 'style', but it is turning into CCA's way or the highway, as I now have out of band potentially unsupported configurations out there, forced upon me for practical reasons. Luckily I have become very conversant with the CLI from back in the days of UC520s where CCA was... how do I put this... in its infancy...

If anyone wants to start a renegade club to compare notes on out of band configs, I'm happy to be the president ;-)  Considering Cisco don't wish to publish OOB guides, maybe I should write one myself ?

3 Accepted Solutions

Accepted Solutions

Scott Martin
Level 1
Level 1

Firstly, let me preface this by saying the Cisco no longer provide ANY CLI support to UC540/UC560 products, as support has fully transitioned to the SBSC, who only support GUI via CCA latest versions, as per the brave new world of Cisco Small Business Support Centre Policy. I will leave the politics and conjecture on that matter alone for the moment...

In reality, 3 digit dial-plan's have got be the simplest CME configuration to setup, with the slight exception in regard to some issues you can run into with DTMF.

DON'T TRY THIS AT HOME (as you will be without support from Cisco if you do any CLI configuration), but in theory, see the following example:

Let's imagine you are in Sydney on a UC560 and have a UC540 in Brisbane. All UC boxes need to be IP addressed accordingly. This will not work if you have all of your systems configured for the default Voice IP range of 10.1.1.1 / CUE 10.1.10.1 for example.

Once you have configured your Voice VLANs on each system with distinct IP ranges (this is key), and have setup your routing table so you can route around quite happily, you configure dial-peers for 3 digit dialling as follows:

dial-peer voice 9300 voip

description ** VoIP Trunk to Brisbane Office Extension Range

destination-pattern [3]..

session target ipv4:10.1.4.1

dtmf-relay h245-alphanumeric

codec g711ulaw

no vad

! The above config will send any call destined for the 300-399 range to terminate on the Brisbane UC540's Voice VLAN IP address.

! It's also best to setup a specific dial-peer for your CUE voicemail at the remote site, forcing SIP, and we've had good success with dtmf-relay rtp-nte in this scenario:

dial-peer voice 9390 voip

description ** CUE at BNE Voicemail Pilot Number **

destination-pattern 390

b2bua

session protocol sipv2

session target ipv4:10.1.14.1

dtmf-relay rtp-nte

codec g711ulaw

no vad

There's no reason you couldn't force all calls to go over SIP and force rtp-nte on a single dial-peer, if your Unity voicemail is in the same extension range. That might look like this:

dial-peer voice 9300 voip

description ** VoIP Trunk to Brisbane Office Extension Range

destination-pattern [3]..

b2bua

session protocol sipv2

session target ipv4:10.1.14.1

dtmf-relay rtp-nte

codec g711ulaw

no vad

That's it. You're done. You apply a similar reverse configuration on the other sites, and you have 3-digit internal dialling. Apparently we are stupid for requesting such a thing, and Cisco have absolutely no interest in including it in CCA. I am pleased to see we aren't the only people who want this functionality.

You can also get clever and setup toll bypass (don't tell your Telco, they get upset ) by something like the following:

dial-peer voice 9301 voip

description ** BNE Pattern via VOIP **

destination-pattern 007........

session target ipv4:10.1.4.1

dtmf-relay h245-alphanumeric

codec g711ulaw

no vad

! The above will send any calls destined for a 07 number to that site to dial out as a local call saving on STD/IDD charges. Note we use 0 as our outside line access digit, so replace the first digit in the destination-pattern to match yours.

I hope this gives you an idea about how you might do this in theory (but not practice) just in case you wanted to do this in your customer lab environment.

Also, best keep your dial-peers up in the high ranges. We've used the 9000 range which seems to steer well clear of CCA (at least until the next release when it may all change).

Note: None of the above config is supported by Cisco, and we provide it as-is with no warranty either express or implied.

Cheers,

Scott

View solution in original post

Except you can't get the specialisation, as the certification has expired and has not been replaced.

View solution in original post

For those of us that only work in the SMB space, the only practical achievable certification is:

UC Express, which as you state, is end of life, so cannot be obtained. UC Advanced is also EOL.

Due to this, and a number of lacking configuration options which seem to become more and more restrictive with each CCA/Software pack release, we have dropped the product portfolio entirely for new customers.

The latest one we have is that you now can't use an AA to transfer to a BACD when using a SIP trunk. This is basic stuff, but apparently 'unsupported'.

I have voiced my disapproval of this strategy at the highest level, to no avail, however it seems the UC540/560 must be destined for EOL themselves in the near future.

View solution in original post

8 Replies 8

mcasimirc63
Level 4
Level 4

OOB Guides! I hope you aren't actually hoping they will be compatible with CCA .  You'll spend a lifetime doing debugs.  Your best bet since you have the will power, is to pass the IP Comm exam and get a co-worker to pass the sales exam.  That will you can fully configure your system via CLI and Cisco will have to support you. At that point the possibilites are endless and everything is supported.

Actually to be honest, I have not hit many issues when using dial-peers in the 5000+ range.

I try to keep as much config in CCA as possible, but I constantly hit a wall on items such as:

- multiple SIP trunks requiring separate digest authentication (forget about using CCA)

- inter-site dialling (as above)

- dodgy Australia dial plans (may be fixed now) - we mostly use 0 as an access digit - try dialling 0,0011 for international and you'll get 000 emergency services... at least you can fix this in CCA.

I have received clarification in the past that these configurations will be supported. Knock on wood, I haven't had to call on support for some time.  I don't believe the tech requirements are 'enforced' but if you call up and say 'what's a dial-peer' they may pull the pin.

timsoto25
Level 1
Level 1

Scott,

I too have a couple of multisite configurations in which i have set up extension ranges to be different.  however, i am not as well versed as you in CLI to have the systems just dial 3 digits.  i have:

Site 1 - 100-199

Site 3 - 300-399

Site 4 - 400-499

I left out site 2 because they have another iste without a UC that may potentially be added later.  We have another site with only one phone that i have set up as the operator for all sites.  she works from home and just answers calls all day.  She has a phone behind an SA520 that VPN's to all sites for data(for callconnector) but voice only on the site 1.  her phone is an extension of the site 1.  It has been somewhat difficult in getting the Smart Callconnector Operator to work right.  (ie, transferring calls, transfer to voicemail, etc.)  i have call transfers working correctly now, but when clicking on the "transfer to voicemail" for an ext on site 3 or 4, it will not work.  she has to transfer manually with the 8 + site id + 6 to steer to vmail + extension.

Anywho, how do i configure the sites to interdial without 8 + Site ID + Extension?  Can you send me sample code?

Thanks in advance.

Scott Martin
Level 1
Level 1

Firstly, let me preface this by saying the Cisco no longer provide ANY CLI support to UC540/UC560 products, as support has fully transitioned to the SBSC, who only support GUI via CCA latest versions, as per the brave new world of Cisco Small Business Support Centre Policy. I will leave the politics and conjecture on that matter alone for the moment...

In reality, 3 digit dial-plan's have got be the simplest CME configuration to setup, with the slight exception in regard to some issues you can run into with DTMF.

DON'T TRY THIS AT HOME (as you will be without support from Cisco if you do any CLI configuration), but in theory, see the following example:

Let's imagine you are in Sydney on a UC560 and have a UC540 in Brisbane. All UC boxes need to be IP addressed accordingly. This will not work if you have all of your systems configured for the default Voice IP range of 10.1.1.1 / CUE 10.1.10.1 for example.

Once you have configured your Voice VLANs on each system with distinct IP ranges (this is key), and have setup your routing table so you can route around quite happily, you configure dial-peers for 3 digit dialling as follows:

dial-peer voice 9300 voip

description ** VoIP Trunk to Brisbane Office Extension Range

destination-pattern [3]..

session target ipv4:10.1.4.1

dtmf-relay h245-alphanumeric

codec g711ulaw

no vad

! The above config will send any call destined for the 300-399 range to terminate on the Brisbane UC540's Voice VLAN IP address.

! It's also best to setup a specific dial-peer for your CUE voicemail at the remote site, forcing SIP, and we've had good success with dtmf-relay rtp-nte in this scenario:

dial-peer voice 9390 voip

description ** CUE at BNE Voicemail Pilot Number **

destination-pattern 390

b2bua

session protocol sipv2

session target ipv4:10.1.14.1

dtmf-relay rtp-nte

codec g711ulaw

no vad

There's no reason you couldn't force all calls to go over SIP and force rtp-nte on a single dial-peer, if your Unity voicemail is in the same extension range. That might look like this:

dial-peer voice 9300 voip

description ** VoIP Trunk to Brisbane Office Extension Range

destination-pattern [3]..

b2bua

session protocol sipv2

session target ipv4:10.1.14.1

dtmf-relay rtp-nte

codec g711ulaw

no vad

That's it. You're done. You apply a similar reverse configuration on the other sites, and you have 3-digit internal dialling. Apparently we are stupid for requesting such a thing, and Cisco have absolutely no interest in including it in CCA. I am pleased to see we aren't the only people who want this functionality.

You can also get clever and setup toll bypass (don't tell your Telco, they get upset ) by something like the following:

dial-peer voice 9301 voip

description ** BNE Pattern via VOIP **

destination-pattern 007........

session target ipv4:10.1.4.1

dtmf-relay h245-alphanumeric

codec g711ulaw

no vad

! The above will send any calls destined for a 07 number to that site to dial out as a local call saving on STD/IDD charges. Note we use 0 as our outside line access digit, so replace the first digit in the destination-pattern to match yours.

I hope this gives you an idea about how you might do this in theory (but not practice) just in case you wanted to do this in your customer lab environment.

Also, best keep your dial-peers up in the high ranges. We've used the 9000 range which seems to steer well clear of CCA (at least until the next release when it may all change).

Note: None of the above config is supported by Cisco, and we provide it as-is with no warranty either express or implied.

Cheers,

Scott

Hello Scott,

CLI is supported without any problem with SBSC when one have specialization for it.

Best regards,

Alex

Except you can't get the specialisation, as the certification has expired and has not been replaced.

Hello,

I just want to clarify the CLI/CCA policy. Here is the official policy(document available to partners only):

http://www.cisco.com/en/US/partner/prod/collateral/netmgtsw/ps7256/ps7287/cisco_cca_cli_support_policy.pdf

Here are the certifications accepted for CLI support(you most also have a service contract on the UC in addition to the Specialization):

  • UC Express(This specialization is end of life)
  • UC Advanced
  • UC Master
  • Advanced Collaboration Architecture
  • Business Edition Partner

Thanks,

-john

For those of us that only work in the SMB space, the only practical achievable certification is:

UC Express, which as you state, is end of life, so cannot be obtained. UC Advanced is also EOL.

Due to this, and a number of lacking configuration options which seem to become more and more restrictive with each CCA/Software pack release, we have dropped the product portfolio entirely for new customers.

The latest one we have is that you now can't use an AA to transfer to a BACD when using a SIP trunk. This is basic stuff, but apparently 'unsupported'.

I have voiced my disapproval of this strategy at the highest level, to no avail, however it seems the UC540/560 must be destined for EOL themselves in the near future.

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: