Redirect old numbers to new numbers on a new PBX

[UrbanPeasant]

Hello,

We're in a process of transition and moving all staff to a new number range and new PBX. This requires being able to dial the new numbers directly from the PSTN via our existing CUBES, and redirecting calls placed to our old numbers to those new numbers, which I thought I knew how to do from CUCM, but maybe not!

Inbound calls to the new number range hit a CUBE (ISR) on a specific dial peer and are sent onwards, via another dial peer, to another CUBE (CSR) which receives the call on the expected incoming dial peer, performs normalisation, and routes onwards via another dial peer successfully. The outbound DP is only hit if the normalisation occurs first.

It's the bit from the old numbers on CUCM that I'm struggling with.

I need to redirect all the existing (~900) DNs, hunt pilots, CTIs to their new DNs/service numbers.

I thought I'd do this by CallFwdAll each number to its new short-dial number. Then create a xlation pattern to prefix the area code to the range for the new numbers. And create a route pattern to collect the now prefixed new number, and send the call across an internal trunk to the CSR. This failed - 'No Matching Outbound Dial Peer' because the call is collected on DP 0, so no normalisation is happening.

So I tried a straight forward route pattern, and added the prefix there. Same result as above.

I tried an unused old number. Created a straightforward xlation pattern for it (predot strip, insert transform, add prefix) > route pattern > CSR, and this fails too. But the called number is the same as for the call coming direct from the PSTN.
 

When I look at debug voice dialpeer inout I see the calling number is the same as the called number, which is peculiar. And ccsip messages I'm getting back a 404, not found which is fed back into RTMT.

Call flow that works: mobile calls to new number 01524511XXX > ISR > CSR > new PBX > end station.

Call flow that fails: mobile calls to old number > ISR > old PBX > CSR ----- no matching outbound dial peer, because the call was picked up on DP 0 and that's not helpful.

Anyone got an idea of how I should be going about this?

Config available if you want it, but the post is getting a bit long-winded now, so I've only included the CSR receiving DP that gets hit for calls direct from the PSTN, but not from Call Manager.

Thanks, and in the mean time I'll keep wrestling with it.

Nathan.

CSR Receives

dial-peer voice 190 voip

description *WANSide INBOUND from CUBES*

translation-profile incoming 100

rtp payload-type comfort-noise 13

session protocol sipv2

incoming uri via 190

voice-class codec 1

voice-class sip tenant 100

dtmf-relay rtp-nte

no vad

voice translation-profile 100

translate calling 100

translate called 100

voice translation-rule 100

rule 1 /^0/ /+44/

voice class uri 190 sip

host ipv4:x.x.x.x

host ipv4:y.y.y.y

host ipv4:z.z.z.z

voice class codec 1

codec preference 1 g711alaw

codec preference 2 g711ulaw

voice class tenant 100

options-ping 60

session transport udp

bind control source-interface GigabitEthernet1

bind media source-interface GigabitEthernet1

no pass-thru content custom-sdp

sip-profiles 100

early-offer forced

voice class sip-profiles 100

rule 10 request ANY sdp-header Audio-Attribute modify "a=sendonly" "a=inactive"

rule 20 response ANY sdp-header Audio-Attribute modify "a=candidate.*" "a=label:main-audio"

rule 30 request ANY sdp-header Audio-Attribute modify "a=sendonly" "a=inactive"

[Roger Kallberg · Accepted solution]

Not all that easy to give you an answer without the full configuration and output from appropriate debug. From the information shared I see that you match on the via header by “incoming uri via 190” on the dial peer that I assume you want it to match. Do you have the IPs of the old PBX in the voice class uri 190 sip and do you have the IPs of the old PBX in either a destination on a outbound dial peer or in the allowed trust list?

[UrbanPeasant]

Roger you bloody beauty!
Much of the time when I write out a request for help I manage to land on the answer because of the process of setting-out-my-stall. And with this, that should have happened because I took apart that incoming DP, noted the addresses in the uri, checked them off against the CUBEs and continued scratching my head. But the traffic wasn't coming from the CUBEs. Even in the debugs I was observing the traffic coming from each of the 4 subscribers! And I still didn't put it together. The subs are indeed in the trust list, and they are now in the uri - and the calls route. I'm relieved about that. 
What I need to get to the bottom of now is why the calls route as 'Unknown' instead of showing the original calling number, something I need to set on the trunk perhaps.

Then I need to settle on the best way of dealing with the migration from old to new numbers.

For now though, I'll sleep a little happier tonight, knowing that I'm not carrying a problem into the weekend.

Thanks Roger.

[Roger Kallberg]

Glad to hear that.

About your unknown number what do you have this set to on the trunk in CM?

If you look at output from debug ccsip message in the CSR for the call what do you get as the calling number for this call leg? Possibly you might need to play around with the options for Calling Line ID Presentation and/or it could also be that you should send Redirecting Division Header in the outbound direction.

[Elliot Dierksen · Accepted solution]

My suggestion would be to configure a dial peer in the CUBE that prefers the new PBX/cluster. If the new cluster is CUCM, make sure the phones in the new cluster DO NOT have a CFUR (call forward unregistered) destination (like voicemail). Then have the CUBE have a less preferred dial peer that goes to the old cluster. As you bring destinations live on the new cluster, the calls will start being delivered there. Once the migration is complete, you can re-enable CFUR if need be.

[UrbanPeasant]

Hi Elliot,
Thinking your idea through, and I like the use of preference in this way, but in my case I'm not sure it'll help because the new cluster won't be serving the old numbers. However, it does present a possible different way forward that enables the existing number ranges to be used in two different clusters served by the same SBCs in perpetuity if I understand correctly. That gives some food for thought, is something I'd not considered, and may present a way of proceeding without renumbering and not having a problem with the old numbers that will have to remain on the old cluster. So I'm going to try and test that tomorrow. Excellent!

Thanks Elliot. 

[UrbanPeasant]

Hi Elliot, bit of closure for you suggestion - nice idea, being pushed forward now: offer all calls to the new PBX first, if the number doesn't exist a 404 comes back and the call is offered to the old PBX where the number will be found. Even at a time when all numbers exist on both PBXs there's no problem as the second PBX never gets offered the call. This will work well because there are numbers that I can't move to the new PBX, but there in the three ranges of numbers where most WILL be moving to the new PBX. But the CUBEs handle this nicely.

I've got a little issue to sort out with a bit more investigation because a call declined on the new PBX side, doesn't get terminated on the calling station (mobile, for testing). Haven't looked into it yet, just noticed it happening. Early days, but this simplifies a load of things for us internally.

Many thanks

Nathan.

[Elliot Dierksen]

Glad to hear that worked for you. I have used this for cluster migration for a number of customers over the years.