Ladies and gentlemen, I have a customer site with a 2821 running IOS 12.4(24)T2. They currently have a single PRI running over a VWIC-1MFT-T1 but would like to add an additional circuit for more capacity. They settled on a local SIP provider who can provide PRI handoff so we installed a second VWIC-1MFT-T1 to handle the circuit. Unfortunately when I brought the second PRI up it was getting multiple error/slip seconds - my best guess is having "network-clock-participate" on both VWICs is the culprit, so I removed the network-clock-participate command but now I'm unable to bring up the pri-group:
2821(config-controller)#pri-group timeslots 1-24
%Please configure network-clock-participate wic 1 first
%Insufficient resources to create pri-group - it has been removed
I've done the multiple carrier config a few times before but it's been a while and I'm a little rusty on my PRI test and turn-up. What am I missing here? How can I properly configure the PRIs to accomodate dual carriers (and apparently dual clocking domains)?
In short, you can't. You will inevitably have slips error on the interface that is not the primary clock reference.
Unfortunately, in the ISR architecture, there can be only one clock reference when DSPs are involved.
Maybe this SIP provider can bring the circuit as such, and you'll avoid the issue completely.
I admit that it's been 18 months since I was in a role where my primary focus was Unified Communications but I've worked with several customers who used different carriers for local and long distance. Does that mean all those deployments were ("officially") unsupported by Cisco and it was just a gamble that the dual-carrier scenario would work?
In theory yes, all HWIC slots on ISR routers clock of off the internal oscillator and hence are all on the same clocking domain, in order to provide separate clocking you need NMs with separate DSPs. In reality though most of the time clocking is fine as even LD provider typically uses the same LEC as local provider for physical connection, same LEC = same clocking. This is not always the same case though.
Thanks Chris. I knew I'd done dual carriers before but in this case I guess the fact that one circuit comes via LEC and the other via SIP to a 2800 with PRI handoff is why the clocking isn't syncing up.
I don't follow SIP via PRI handoff? There is no such thing, it's either SIP trunk which is an IP connection, perhaps over a T1 handoff on this router or straight up digital TDM PRI. If you can post your configuration we can see exactly what you mean.
The customer's (second) carrier has a SIP trunk coming into the building (somehow) and terminates it to a voice gateway the carrier has provided. As far as I know that VG has a VWIC (or something similar) for the customer to plug into. Rather than getting a demarc like a typical carrier would provide my customer is attached to the carrier voice gateway with a crossover T1 cable to their own VWIC-1MFT-T1.
Right, so this is not a PRI circuit but simply T1 "WAN" connection, this is very odd, normally Ethernet handoff would be desired from provider's handoff equipment, but it is what it is. You should not need to do any clocking on the SIP connection, and only clock of off the PRI circuit.
It's not a PRI circuit when it comes into the building but it's terminated and presented to us as one. The carrier is giving it to us as a Voice PRI.
Well, that's even more bizarre, please post config if you can. My suggestion would be to look for competent SIP trunk provider if this is the case.
This isn't that bizarre. Many CLECs use the IAD hardware to convert from an IP network into TDM handoff for legacy PBX deployments. In these scenarios the IAD is using it's backplane clock to drive the T1. This will be entirely out of sync with the LEC's clock. You need to separate your two circuits into isolated clocking domains.
Yes, there is, and I've seen it in various plaes and countries. Many telco makes no mistery of having a totally based SIP infrastructure, then use an IAD or gatway to provide PRI service. Curiosly, some of the then do not provide pure SIP trunk services.
This can only be done if you isolate the PRIs into separate clocking domains. The ISR architecture allows for multiple clocking domains as long as you put the hardware in the router correctly. The motherboard with it's VWIC slots and DSPs are domain zero (aka voice card 0). An NM-HDV2 network module can be a separate clocking domain as long as you do not enable DSP Sharing through the "dspfarm" command (just use "dsp services dspfarm" instead). In this case you can place a T1 VWIC with its own DSPs on that NM and it will not experience slip errors.
Ok, so it would seem that the configuration as it stands is broken so let me ask the obvious question: what's the cheapest way to fix it? I currently see two options:
1) Per Jonathan - Buy NM-HDV2 and a PVDM2-32. Will any older model of NM work?
2) Per Chris - Drop the PRI altogether and take a raw SIP trunk instead. This wouldn't require any additional DSPs and the customer is already running Advanced IP Services-K9 on the gateway so the IOS should take a basic SIP termination just fine.
Does that sound about right?
A SIP trunk would be highly preferred if it's viable; however, there are a lot of considerations (e.g. codec selection, fax/modem relay, DTMF relay interactions with apps such as UCCX, etc) and it's more than just Advanced IP Services. You also need a Cisco Unified Border Element (CUBE) license. This is ordered in concurrent calls and referred to as sessions. There's a 25-session license which is equivelent to a 23-channel PRI essentially.
Firrst of all, is not like some slip error makes things not work. They only affect fax, voice is virtually unaffected.
Then, if your capplication cannot tolerate the above, I recommend you use the SIP trunking alternative. That is ebcause the NM-HDV is quite an outdated platform, only used in some corner cases nowadays.