New SBCs, new number from ITSP, same old CUCM, can't get phone to ring

[Nathan Millward]

I've just got 2 new CSR8000V. They connect to our existing ITSP but will handle a new number range (just one number in config presently.)

On CUCM the 2 new trunks are up using same config as the old pair of trunks for the older CSRs
I've created a single new DN in the internal partition, given it national css dialing privileges and assigned it to my test phone on my desk. So far, so apparently straightforward. In config it looks just like any other of our 5 digit DNs. 

The incoming call hits the SBC, is processed, is passed out to a sub, but can't find the find hardphone on which the DN resides.

On the new SBCs there's a bit of number manipulation going on.

Incoming calls are collected by dial peer 1

dial-peer voice 1 voip
description * WANSide INBOUND from ITSP L1 via ISP1 *
translation-profile incoming 100
call-block translation-profile incoming CALL_BLOCK
call-block disconnect-cause incoming call-reject
rtp payload-type comfort-noise 13
session protocol sipv2
incoming called-number <area>37689
voice-class codec 1
no voice-class sip asserted-id
voice-class sip profiles 10 inbound
dtmf-relay sip-kpml sip-notify rtp-nte
no vad

voice translation-profile 100
translate calling 100
translate called 100

voice translation-rule 100
rule 10 /^0/ /+44/

After translation-profile 100 has run, the incoming call is collected by outbound dial peers 3 or 5 (same thing but aimed at 2 different subscribers by preference.)

dial-peer voice 3 voip
 description * LANside OUTBOUND to IS-SUB01 *
 translation-profile outgoing PSTN_inbound_44
 preference 1
 session protocol sipv2
 session target ipv4:10.42.18.72
 destination e164-pattern-map 50
 voice-class sip bind control source-interface GigabitEthernet1
 voice-class sip bind media source-interface GigabitEthernet1
 dtmf-relay sip-kpml sip-notify rtp-nte
 codec g711alaw
 no vad

voice class e164-pattern-map 50
 description * EXPLICIT INBOUND MAP for CUCM *
  e164 +44<area>37689

voice translation-profile PSTN_inbound_44
 translate calling 10
 translate called 11

voice translation-rule 10
 rule 1 /^\+44\(.%\)/ /80\1/

voice translation-rule 11
  rule 1 /^\+44<area>\(37689\)/ /\1/

The inbound call for extension 37689 reaches CUCM, but despite it being configured as a line on my phone, the sip messaging returns SIP/2.0 404 Not Found from the subscriber.

IF the DN is on the phone why can't CUCM route the call to the phone? I can't spot what I'm missing. I hoped that typing this out would help clarify to my own mind what I'd done and hence what I've missed, but I'm drawing a blank. The number is allocated to my phone, so I can't figure out what I've missed here.

I've collected debug ccsip and debug voip dialpeer inout, but the answer isn't in there because that bit appears to be working fine.
And the sdl log just tells me it's not found

I'd be grateful if someone could suggest what I've missed.
Thanks
Nathan.

[Roger Kallberg]

Is the Internal partition where you have the directory number in the calling search space that is set as used for the inbound CSS on the SIP trunk in CM for the SBCs? Have you done a DNA for the trunk, if so what does it say?

[Nathan Millward]

Hi Roger, thanks for looking.

All the DNs are in the 'Internal' partition. There isn't a different partition that we use for any numbers. The Inbound CSS is 'Internal' on all the trunks and the Internal partition is already in that CSS. I think the following images are what you need to see that: an old example of a number that works, 95223, and the new number 37689.

I did a trunk DNA on older SBC01 and new SBC03: the call to 37689 can't come in across the trunk from SBC01 because the call isn't sent to that SBC from the ITSP, but the CUCM processing is the same once the SBC has done its translations work and sent the call onwards. I don't think I'm missing anything here, or am I?

Older SBC01

New SBC03

[Nathan Millward]

Worth adding that I can dial out. The outbound call from the new DN is processed by CUCM properly, handled by the receiving dial peer on the new SBC, runs through outbound xlation, and gets sent onwards by the ITSP-facing dial peer.

I still haven't caught on to what I've got wrong on CUCM for the inbound call.

[Roger Kallberg]

Looks all correct to me. I guess you’ll have to deep dive into the SDL logs. There has to be something that is making the CM to respond with 404.

[Nathan Millward]

I've picked through SDL logs now and pulled out what I think is relevant. I placed a call outbound. Answered. Hung up. Returned the call, and received the 'You dialled an incorrect number' message. In the logs excerpt attached (doesn't display well posted inline here) there is a glaring !!ERROR!! line. But I can't make out what is wrong.

I deleted the DN and started again, but with no success. I'm just not getting something right.

[Carlo Poggiarelli]

Hi Nathan,

Can you please activate a debug ccsip message on your  SBC and post the output of a failed call?

Thanks

Regards

Carlo

[Carlo Poggiarelli]

Hi again,

Just another hint,

On Route Plan report, search for destination extension and see if there is another entry on a BLANK partition. Thaks could be a cause of this behaviour.

Please let us know.

Regards

Carlo

[Nathan Millward]

Thanks Carlo. Easy to answer this one quickly before I collect SBC debugs.

[Nathan Millward]

Second post of the day for my thread. Here's the SBC output of my failed call. 
Correct outbound dial peers matched in debug dialpeer output. Tries both of those subscriber destinations. Gets a 404 for both. Then a final 'No outbound dialpeer message' to the ITSP which, to my shaky grasp on things, means 'I've tried 2 paths for an answer, but now there's nothing else to try.'
I'm gonna stare at this until my brain leaks out of my ears! There's going to be an almighty 'NO WAY' face plant at some point.

Kept getting invalid file type messages for the debugs so had to mess around until I found a file type that would be accepted, but the file won't open in TranslatorX. Saving the file as MS-DOS file type works for TranslatorX, but not for uploading.