Multiple SIP Trunks on CUBE - URI based Dial-peer Matching

b.winter · ‎03-02-2022

Symptoms

With multiple SIP Trunks on the CUBE, it can be hard to correctly separate the incoming calls from CUCM to CUBE to the correct provider SIP Trunk.

With this post, I'd like to present (in my opinion currently the most) convenient solution to that problem.

Some background information about "older" or inconvenient solutions:

Based on called-number:

In CUCM you would prefix the called number with a delimiter, before sending it to the CUBE (e.g *90* for provider 1 and *91* for provider 2)
In CUBE, the incoming (and also the outgoing) dial-peer could be matched based on these delimiters, which then can be stripped of with voice translation-rules

Based on different IP address in the SIP Trunks configuration in CUCM:

You could use something like loopback interfaces, or interfaces in different VRFs on the CUBE
In CUCM you then point the SIP Trunk destinations to these different IP addresses
In CUBE, the incoming dial-peer would be match based on the different interfaces, where the call comes in to
But: It isn't that easy, to get all those IP addresses for the loopbacks or set up VRFs and all the routing and so on

Solution

In CUCM every SIP Trunk needs to have a SIP Trunk security profile --> take this as your advantage
In the SIP Trunk security profile, the incoming port will be changed (e.g. port 5560 for provider 1 and port 5561 for provider 2)
And yes, it says "incoming port"
But: This port is also used in the "Via" header of the outgoing SIP INVITE from CUCM to CUBE
- Example: Via: SIP/2.0/TCP 62.153.198.123:5560;branch=z9hG4bK21960
In CUCM, one SIP Trunk is added per each provider, with a different SIP Trunk security profile.
Taking this information into account and that CUBE has the ability, not only to match dial-peers based on numbers, but also based on the URIs of different SIP headers, you are now able to do the incoming dial-peer matching (from CUCM to CUBE) based on that port.
Matching based on URIs in generally gives you the power, to be independent of any calling or called numbers, using to match dial-peers (Awesome, isn't it?)

Ok, let's look at a configuration example on CUBE:

! From CUCM to CUBE
voice class uri 1000 sip
 pattern :5560 --> Matches a pattern in the Via header, in this case the pattern is ":5560"
!
voice class dpg 1000
 dial-peer 2000
!
dial-peer voice 1000 voip
 description ### Incoming from CUCM ###
 incoming uri via 1000
 destination dpg 1000 --> Automatically assigns the correct outbound dial-peer
!
!
! From CUBE to CUCM
voice class server-group 1001
 ipv4 [CUCM-IP] port 5560
!
dial-peer voice 1001 voip
 description ### Outgoing to CUCM ###
 session server-group 1001
!

"bind interface…" commands are configured in the tenants or in the dial-peer configuration, to use the correct interface for sending internal traffic via the internal interface, and external traffic via the external interface.

What are the advantages:

No need to use number prefixes in CUCM / CUBE and all the hazzle adding and stripping them off again. Also, if configured in the wrong place in CUCM, the prefixes could be reflected on the phone display after translations (which isn't nice for the users)
No need for additional IP addresses on the CUBE and possible problems with IP routing
In CUCM it is still possible to add more SIP Trunks with the same destination IP addresses, since the port in the SIP Trunk security profile assigned to the trunks are different (CUCM checks for a combination of IP address + incoming port)

Full example config attached.

Open to suggestion and recommendations.

Hope, this post helps people.

Roger Kallberg · ‎03-02-2022

Great post Björn!

LibinBenedict · ‎03-03-2022

Great post.

b.winter · ‎04-25-2022

Update to the post, like Cisco heard the technicians:

New feature in IOS-XE 17.8.1a: "Configurable SIP Trunk Listen Port"

LibinBenedict · ‎04-25-2022

That's great news!