I'm involved in the following setup illustrated below. I am Site 4. I have a SIP trunk via the CUBE to Site 1. Calls route between Site 4 and Site 1 with no problem. Is it possible to use Site 1 CUCM, to route calls from Site 4 to Sites 3 or 2? Is it possible for a user from site 4 to call a user in site 2, using Site 1 as call route point? If so, what needs to be setup? Right now, on Site 4 CUBE, I receive a SIP/2.0 404 Not Found from the Site 1 CUCM. Mind you, I don't own Site 1, 2 or 3. But, I can make recommendations to them.
Ultimately I'm trying to avoid making additional SIP trunks to my CUBE.
Accepted Solutions
Users at Site 4 can potentially make calls to Sites 1 and 2 using the CUCM at Site 3, provided there is a trunk connecting these sites. The necessary configurations include a router pattern directed towards Sites 1 and 2 from the CUCM at Site 3 using the appropriate trunks. Additionally, the trunk between the Cube and the CUCM at Site 3 must have an inbound calling search space that can access the route pattern configured for Sites 1 and 2.
I would recommend you to put in these changes as with the configuration you have outlined above you open up for call loops, or at least hairpin calls, as the .T destination would match on none existing directory numbers in the 444.... range if your (Site 4) sends a 404 Not Found to your Cube.
voice class sip-options-keepalive 1
description Used for Site 1 SIP OPTIONS PING
!
voice class sip-options-keepalive 4
description Used for Site 4 SIP OPTIONS PING
!
voice class dpg 1
dial-peer 2000
!
voice class dpg 4
dial-peer 1000
!
voice class e164-pattern-map 1
description E164 Pattern Map for called number to Site 1
e164 1.BAD !Not actually used for call routing as that is done by DPG 1, but needed for the dial-peer to be in operational state
!
voice class e164-pattern-map 4
description E164 Pattern Map for called number to Site 4
e164 4.BAD !Not actually used for call routing as that is done by DPG 4, but needed for the dial-peer to be in operational state
!
voice class uri SITE1 sip
host ipv4:<site 1 CM IP> !Add more lines is needed
!
voice class uri SITE4 sip
host ipv4:<site 4 CM IP> !Add more lines is needed
!
dial-peer voice 1001 voip
desc Inbound CUCM to CUBE from Site 4
session protocol sipv2
destination dpg 1 !Use DPG to send calls to site 1
no incoming called-number .T
incoming uri via SITE4 !Use information in the VIA header to match the inbound calls
no voice-class sip options-keepalive !Not needed on inbound dial-peers
voice-class sip bind control source-interface fastethernet0/0
voice-class sip bind media source-interface fastethernet0/0
codec g711ulaw !It would be better likely if you where to have a voice-class codec list for this
no vad
!
dial-peer voice 1000 voip
desc Outbound CUBE to CUCM to Site 4
session protocol sipv2
no destination-pattern 444....
destination e164-pattern-map 4 !Define the destination number with a pattern map instead of having individual patterns on dial-peers
session-target ipv4:(CUCM4 IP)
no voice-class sip options-keepalive
voice-class sip options-keepalive profile 1 !Use the more modern way of defining SIP option ping
voice-class sip bind control source-interface fastethernet0/0
voice-class sip bind media source-interface fastethernet0/0
codec g711ulaw
no vad
!
dial-peer voice 2001 voip
desc Inbound CUCM to CUBE from Site 1
session protocol sipv2
destination dpg 4 !Use DPG to send calls to site 4
no incoming called-number 444....
incoming uri via SITE1 !Use information in the VIA header to match the inbound calls
no voice-class sip options-keepalive !Not needed on inbound dial-peers
voice-class sip bind control source-interface fastethernet0/1
voice-class sip bind media source-interface fastethernet0/1
codec g711ulaw !It would be better likely if you where to have a voice-class codec list for this
no vad
!
dial-peer voice 2000 voip
desc Outbound CUBE to CUCM to Site 1
session protocol sipv2
no destination-pattern .T
destination e164-pattern-map 1 !Define the destination number with a pattern map instead of having individual patterns on dial-peers
session-target ipv4:(CUCM1 IP)
no voice-class sip options-keepalive
voice-class sip options-keepalive profile 4 !Use the more modern way of defining SIP option ping
voice-class sip bind control source-interface fastethernet0/1
voice-class sip bind media source-interface fastethernet0/1
codec g711ulaw !It would be better likely if you where to have a voice-class codec list for this
no vad
If you use a codec list add this
voice class codec 1
codec preference 1 g722-64
codec preference 2 g711alaw
codec preference 3 g711ulaw
!
And on each dial-peer do this
no codec g711ulaw
voice-class codec 1
My suggested configuration uses dial peer groups to define the egress dial-peer for each call direction as all that you want to achieve is that any call from site 1 goes to site 4 and the reverse where all calls from site 4 goes to site 1. You can see DPGs as a way to hard code the path to use and not utilize the actual called numbers to do this.
Users at Site 4 can potentially make calls to Sites 1 and 2 using the CUCM at Site 3, provided there is a trunk connecting these sites. The necessary configurations include a router pattern directed towards Sites 1 and 2 from the CUCM at Site 3 using the appropriate trunks. Additionally, the trunk between the Cube and the CUCM at Site 3 must have an inbound calling search space that can access the route pattern configured for Sites 1 and 2.
There are some unclear details about this. In you picture you show that there is a SIP trunk via the Cube between site 4 and site 1, but in the text you state that there is a SIP trunk between site 4 and site 3. You also mentioned that there is a CM at site 1 and that you can make calls from site 4 to site 1, but you don’t give any details on what type of calling platform site 2 and 3 have. Are they connected with the same CM as site 1? From where is your Cube getting the 404 not found, is it the CM sending that or is it the Cube based on that it doesn’t know how to route calls to the directory numbers at site 2 and 3. If it’s the latter you need to look at the dial peer configuration in your Cube and if it’s the former you need to reach out to the CM admin at site 1 to ask them to check that the SIP trunk on their end has visibility of the partition(s) and any other configuration items needed to route calls to the directory numbers at site 2 and 3. Depending on your answer to my questions there are different options for how to handle your enquiry.
Apart from partitions visible in the inbound CSS of the SIP trunks there aren't all that much else that could be the cause of a routing call failure with a 404 Not Found. What could be at play is if you modify the called number on-route so that it no longer matches the directory number on the receiving end, that would also give a 404 Not Found.
Given that you’re prefixing the calls, it’s not just the Calling Search Space (CSS) and partitioning that you need to verify. You should also check the dial plan on Site 1’s CUCM. If you’re removing the prefix, you’ll need to add the prefixes for Site 2 and 3 to match the Route Pattern pointing towards these sites, assuming the router pattern configured on Site 1’s CUCM includes a prefix.
Let’s say a user at Site 1 dials 55XXX. If you have significant digits set to 3 on the SIP trunk at Site 1, it will only pass the last three digits. If the Route Pattern on the CUCM is configured as 55XXX, you might encounter a ‘not found’ error.
It’s crucial to collaborate closely with the CUCM admin at Site 1. It seems like this could be a simple issue of misconfigured call routing
I don't think the OP actually meant that the called number is prefixed when he wrote this " I have dial-peers configured for the prefix's of Site 1 and 2 (Soon Site 3), with a target of Site 1 CUCM.". How I read this is that he has a match on one or more dial-peer to send calls to the number prefix for the sites as was outlined in the picture in the original post, ie 222XXXX (Site 2), 333XXXX (Site 3) and 111XXXX (Site 1).
Have a look at this document for how you can optimise your dial peers. Explain Cisco IOS and IOS XE Call Routing Essentially you need one inbound dial peer that uses the VIA header to match incoming calls and one outbound dial peer that has an e164 number group with all the destination numbers, ie numbers for site 1, 2 and 3. There is no need to have individual inbound and outbound dial peers per site as you have it.
Do you mean that they have everything in the <none> partition? If not they sure do have CSSs and likely multiple ones.
