cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
545
Views
8
Helpful
16
Replies

Can CUCM be used to route calls between different sites?

David Rollins
Level 1
Level 1

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.

DavidRollins_0-1713296617836.png

 

2 Accepted Solutions

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.



Response Signature


View solution in original post

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.



Response Signature


View solution in original post

16 Replies 16

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.



Response Signature


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.



Response Signature


@Roger Kallberg I corrected my text, thank you.
Site 1 has SIP trunks between 2 CUCM, 3 CUCM and 4 CUBE. I have dial-peers configured for the prefix's of Site 1 and 2 (Soon Site 3), with a target of Site 1 CUCM. Sites 2 & 3 are CUCM and are connected via SIP trunks. The SIP 404 not found, is from the debug on the CUBE, received from the CUCM at Site 1. 

I did not think of CSS or partition setup on Site 1 CUCM. But that could very well be it. 

If not CSS or partition, what else could it be?

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.



Response Signature


What I understood from your description is that your current setup is as follows:

 

  • You are at Site 4, which has a SIP trunk with CUBE.
  • Site 1's CUCM is interconnected with CUCM 2 and CUCM 3 using SIP trunks.
  • Site 1's CUCM communicates via SIP with Site 2's CUCM.
  • Site 1's CUCM communicates via SIP with Site 3's CUCM.

 

Site codes:

Hypothetically,

  • Site 1's CUCM: 55 (existing)
  • Site 2's CUCM: 66 (existing)
  • Site 3's CUCM: 77 (to be added soon)

 

When you call 55XXX from Site 4 (CUCM4), the call routes via CUBE, matches a dial peer, and is sent to CUCM 1. It may strip '55' and send calls to extension XXXX.

Now, if you want to send calls to CUCM 2 extensions:

  • On CUBE: Create a dial peer with a destination pattern of 66XXXX and session target CUCM 1.
  • On CUCM 1: Create a route pattern (RP) for 66XXXX with the target as the SIP trunk to CUCM 2. (Either strip '66' from CUCM 1 or from CUCM 2 and send the call to extension XXXX on CUCM 2.)
  • The same process applies if you are calling CUCM 3

This is the same as what Nitin initially mentioned. 

Disclaimer:

Responses are based on personal knowledge and experience. Consider them as guidance. Other members may offer different perspectives or better approaches. No responsibility is assumed for outcomes; discretion is advised.

@Shalid Kurunnan Chalil , thank you. And you provided a much better description of the setup. For that, I thank you again. 
I already have what you suggested, configured on the CUBE. I can see from Debugs and packet captures, the call is matched on the Dial-peer and the Invites are sent to CUCM 1. 
So with that being said, and with what you all have provided. I'm going to ask them how their CSS and partitions are setup. Thank you. I will provide more feedback once I know more. Thank you.

I believe their RPs are already setup to CUCM 2 and 3. They configured the RP with the Gateway of the associated SIP trunk.  

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



Response Signature


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).



Response Signature


I have a dial peers configured to match incoming and outgoing called numbers. Example snipt below. 

dial-peer 1000

incoming called number 222....

dial-peer 2000

destination-pattern 222....

session target ipv4:(cucm1 IP)

dial-peer 3000

incoming called number 111....

dial-peer 4000

destination-pattern 111....

session target ipv4:(cucm1 IP)

 

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.



Response Signature


Yes agreed, I thought the same thing. But I wanted to get it to work first. And I wanted to make sure it wasn't a dial-peer configuration issue.

They apparently don't use CSS or Partitions. Which could explain it. If any of their customers want to talk to each other, they create an adhoc conference. And everyone calls into that. I don't like the answer or solution, but again I don't manage it.
Thanks for the information.

Do you mean that they have everything in the <none> partition? If not they sure do have CSSs and likely multiple ones.



Response Signature


@Roger Kallberg I decided to go with the following. So if they ever setup CSS and RP, we will be good to go. Which is working for all 111.... numbers.

dial-peer voice 1001 voip
desc CUCM to CUBE Site 4
session protocol sipv2
incoming called-number .T
voice-class sip options-keepalive
voice-class sip bind control source-interface fastethernet0/0
voice-class sip bind media source-interface fastethernet0/0
codec g711ulaw

dial-peer voice 1000 voip
desc CUBE to CUCM Site 4
session protocol sipv2
destination-pattern 444....
session-target ipv4:(CUCM4 IP)
voice-class sip options-keepalive
voice-class sip bind control source-interface fastethernet0/0
voice-class sip bind media source-interface fastethernet0/0
codec g711ulaw


dial-peer voice 2001 voip
desc CUCM to CUBE Site 1
session protocol sipv2
incoming called-number 444....
voice-class sip options-keepalive
voice-class sip bind control source-interface fastethernet0/1
voice-class sip bind media source-interface fastethernet0/1
codec g711ulaw

dial-peer voice 2000 voip
desc CUBE to CUCM Site 1
session protocol sipv2
destination-pattern .T
session-target ipv4:(CUCM1 IP)
voice-class sip options-keepalive
voice-class sip bind control source-interface fastethernet0/1
voice-class sip bind media source-interface fastethernet0/1
codec g711ulaw