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.
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?
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
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.
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.
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.
-------------
Tried again with a straight copy of output from the console into a new txt file. Still not having it for the post.
-------------
Apols for the delay in reply.
CUCM Trunk config
SBC03 Trunk config:
interface GigabitEthernet1
description *LANSide SBC03 to CUCM*
ip address 10.42.18.104 255.255.255.192
ip nat outside
negotiation auto
no mop enabled
no mop sysid
Dial peer to a sub
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
The xlation profile
voice translation-profile PSTN_inbound_44
translate calling 10
translate called 11
The xlation rules
voice translation-rule 10
rule 1 /^\+44\(.%\)/ /80\1/
voice translation-rule 11
rule 2 /^\+4415245\(6798.\)/ /\1/
rule 3 /^\+4415242\(37689\)/ /\1/
The pattern-map
voice class e164-pattern-map 50
description * EXPLICIT INBOUND MAP for CUCM *
e164 +441524237689
The call reaches the sub, but then there is the small matter of that 404 Not Found / Unallocated Number message even though I have a registered Jabber client awaiting the call (no different if I put the DN on a hardphone).
I'm not finding a clue from cway, just what I already know.
Requested SDL attached.
Evening Carlo (well, morning for you I guess)
dbrepl looks good
Dial peer 3 aimed at the publisher (10.42.18.71) - unallocated number.
