Using an ISR4321 CUBE as a basic POTS-to-SIP gateway

[TedM]

I have an Asterisk PBX and a Cisco ISR4321 with voice cards running isr4300-universalk9.16.09.08.SPA.bin and plugged into a POTS line.  Neither of these are touching the Internet or have port forwards to them from the Internet, this is entirely on a private network.

I want to setup the Cisco as a voice gateway for 911 calls from the Asterisk system to the PSTN.  It's working when I dial the POTS line but not in reverse, when I try sending a call from the Asterisk system out the POTS line.  Here's the config in the ISR, am I missing anything here? (passwords, licenses have been suffocated)

CUBE#sh run
Building configuration...


Current configuration : 6153 bytes
!
! Last configuration change at 07:44:44 PDT Fri Oct 17 2025
!
version 16.9
service tcp-keepalives-in
service tcp-keepalives-out
service timestamps debug datetime msec localtime show-timezone
service timestamps log datetime localtime show-timezone
service password-encryption
service compress-config
service sequence-numbers
platform qfp utilization monitor load 80
no platform punt-keepalive disable-kernel-core
!
hostname CUBE
!
boot-start-marker
boot system flash bootflash:isr4300-universalk9.16.09.08.SPA.bin
boot-end-marker
!
!
vrf definition Mgmt-intf
 !
 address-family ipv4
 exit-address-family
 !
 address-family ipv6
 exit-address-family
!
no logging console
enable password 7 0505551735F03585450
!
no aaa new-model
clock timezone PST -8 0
clock summer-time PDT recurring
!
ip name-server 172.16.1.30
ip domain name c.org
!
!
!
login on-success log
!
!
!
!
!
!
!
subscriber templating
!
!
!
!
!
multilink bundle-name authenticated
!
!
!
!
!
!
crypto pki trustpoint TP-self-signed-3535480316
 enrollment selfsigned
 subject-name cn=IOS-Self-Signed-Certificate-3535480316
 revocation-check none
 rsakeypair TP-self-signed-3535480316
!
!
crypto pki certificate chain TP-self-signed-3535480316
 certificate self-signed 01
  30820330 30820218 A0030201 02020101 300D0609 2A864886 F70D0101 05050030
  AE654EDA D770ACB5 95EB45B4 84EAFBF4 154EC2BF 413BB93E 90E83EC4 D1C599D6
  7BBB2CD7 CF1079CF B7AA4FCB AA69AF8C 8314060D
        quit
!
!
voice rtp send-recv
!
voice service pots
!
voice service voip
 mode border-element
 allow-connections sip to sip
 fax protocol pass-through g711ulaw
 modem passthrough nse codec g711ulaw
 sip
  bind control source-interface GigabitEthernet0/0/1
  bind media source-interface GigabitEthernet0/0/1
  session transport tcp
!
voice class codec 1
 codec preference 1 g711ulaw
 codec preference 2 g729r8
 codec preference 3 g726r32
 codec preference 4 g722-64
!
!
!
!
!
!
!
!
!
!
!
voice-card 0/1
 no watchdog
!
voice-card 0/2
 no watchdog
!
voice-card 0/4
 no watchdog
!
license udi pid ISR4321/K9 sn FDO21429HZ0
license accept end user agreement
license boot level securityk9
no license smart enable
diagnostic bootup level minimal
!
spanning-tree extend system-id
archive
 path tftp://ce.d.com/$h-confg-$t
 write-memory
 time-period 10080
!
!
!
username nes privilege 15 password 7 1217560F0718417677E
username on privilege 15 password 7 153F04030A0A27B
!
redundancy
 mode none
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
interface GigabitEthernet0/0/0
 no ip address
 shutdown
 negotiation auto
!
interface GigabitEthernet0/0/1
 description To LAN Network
 ip address 172.16.160.3 255.255.255.0
 negotiation auto
!
interface Service-Engine0/1/0
!
interface Service-Engine0/2/0
!
interface Service-Engine0/4/0
!
interface GigabitEthernet0
 vrf forwarding Mgmt-intf
 no ip address
 shutdown
 negotiation auto
!
ip forward-protocol nd
no ip http server
ip http authentication local
no ip http secure-server
ip tftp source-interface GigabitEthernet0/0/1
ip route 0.0.0.0 0.0.0.0 172.16.160.1
ip route 172.16.0.0 255.255.0.0 172.16.160.1
!
ip ssh version 2
!
!
ip access-list extended TerminalAccess
 permit tcp 172.16.0.0 0.0.255.255 any eq 22
 deny   tcp any any
!
!
!
!
control-plane
!
!
voice-port 0/1/0
!
voice-port 0/1/1
!
voice-port 0/1/2
!
voice-port 0/1/3
!
voice-port 0/2/0
!
voice-port 0/2/1
 timeouts interdigit 3
 timing hookflash-out 50
 connection plar 8672455292
 description trunk 867-245-5292
 caller-id enable
!
mgcp behavior rsip-range tgcp-only
mgcp behavior comedia-role none
mgcp behavior comedia-check-media-src disable
mgcp behavior comedia-sdp-force disable
!
mgcp profile default
!
!
!
!
dial-peer voice 1 voip
 preference 1
 destination-pattern ^8672455292$
 modem passthrough nse codec g711ulaw
 session protocol sipv2
 session target sip-server
 incoming called-number .
 voice-class codec 1
 dtmf-relay rtp-nte h245-signal h245-alphanumeric
 fax protocol pass-through g711ulaw
 no vad
!
dial-peer voice 911 pots
 preference 1
 destination-pattern 911
 port 0/2/1
 forward-digits 3
!
!
sip-ua
 retry invite 3
 retry response 3
 retry bye 3
 retry cancel 3
 timers trying 1000
 timers expires 300000
 sip-server ipv4:172.16.160.10:5060
!
!
line con 0
 transport input none
 stopbits 1
line aux 0
 stopbits 1
line vty 0 4
 access-class TerminalAccess in
 exec-timeout 0 0
 login local
!
ntp server 172.16.160.1
!
!
!
!
!
end

CUBE#

[Elliot Dierksen]

The config of the router is a start, but how is the SIP connection to the router defined in Asterisk? The output from "debug ccsip mess" while Asterisk is trying to send a call would provide some helpful information.

[Roger Kallberg]

What you’re setting up is a traditional TDM voice gateway as one interface is POTS based. That doesn’t require Cube functionality as it doesn’t act as a Session Boarder Controller, SBC in short. This document might be of help for you. Explain Cisco IOS and IOS XE Call Routing 

[TedM]

I know it does not require CUBE functionality, a regular 29xx ISR would work and I've also built one of these before on a 1760.  But, I -have- the ISR.  As the joke goes, Free is a Very Good Price. LOL  Besides, who knows what the future might bring.  I might get hit by a bus tomorrow and the new guy might decide to throw the Asterisk system (that costs nothing) out the window and replace it with a CUCM for $50k or so.  Unlikely, perhaps, but when you build systems you always keep an eye on the future - and besides, the ISR is rack mounted and a Grandstream FXO gateway would require my spending an additional $50 on a shelf, lol.

Seriously, we also have a number of other 800's in the network also serving as 911 voice gateways at other sites so I'd rather just deal with 1 vendors peculiaritys than several.

Right now the trunk in the Asterisk system isn't showing as registered into the ISR so that's a problem.  I'll take a look at the docs you linked to and try some more stuff out on it.  Sooner or later I'll get a working config then post it back here in case someone else is interested.

[Roger Kallberg]

Cube is a function in Cisco routers, it works on anything after ISR 29xx/39xx.

[Nithin Eluvathingal]

If I understood your problem correctly, you have an Asterisk server connected to a router, which is through SIP, and the router has an analog line connected for receiving and making calls to the PSTN, which is connected to 0/2/1.
Your problem is that when a call arrives from outside on this POTS line, the call is landing on the 8672455292 (assuming this number is on the PBX). However, when you try to call from the Asterisk to an outside number, it doesn't work.

If your issue is as described above, I would suggest trying the following:

1. Check Asterisk configurations.
2. Collect debug information from the gateway with "Debug Voice ccapi inout" and "Debug csip messages" to see if the calls are really landing on the router and how they are processed.

Note: I can see an ACL configured on the router; does this have any impact on the calls?

[TedM · Accepted solution]

I stumbled over the solution entirely by accident.

Note the configuration section from my post:

voice service voip
 mode border-element

That mode border-element is a critical piece of the puzzle.  Officially, it does nothing technical other than turn on some SBC/CUBE commands that you have to have a license for (I do, on this router)

unofficially, it completely screws over debugging.  With it turned on, I was getting NOTHING of any usability or substance from the debug ccsip debugging output.   Not being familiar with normal Cisco debugging output, I did not realize I was being shortchanged.

After turning off that line (and rebooting) now the debugging output was FAR MORE copious.  And, because of that, the problem was now clear.  I needed to add

voice service voip
 ip address trusted list
 ipv4 172.16.160.10

 and once I did that - volia, trunk came up, and outbound calls worked.

The rest of the stuff, like checking if calls were landing on the router, etc. - is all basic troubleshooting stuff I had already checked.  Nothing was changed on the Asterisk side of the trunk - that had been configured properly.

I SUSPECT that this ip address trusted list thing was added by Cisco rather late in the game since I don't believe IOS 12 has it.  But I'm not an expert on historical IOSes.  And I suspect I could turn back on the CUBE license now that the trust list is in there but it seems to me that giving up copious debugging in exchange for some speculative CUBE-only commands isn't a good tradeoff.

Hope this helps someone else!

[Roger Kallberg · Accepted solution]

mode border-element

This command turns on Cube functionality in your router to allow it to act as a Session Border Controller, SBC in short. As mentioned multiple times what you have does not require the router to act as an SBC as you do not route calls from one IP interface to another IP interface. Your setup comprises of one IP interface and one TDM interface. This do not need Cube functionality. I would advice you to not turn on Cube functionality by the mode border-element command if you do not require that functionality.

Based on your shared information I'm guessing that the IP 172.16.160.10 is not what you defined sip-server to be. With that the built in toll-bypass protection kicks in and blocks the traffic from the unknown IP. This isn't anything that is new, it's been apart of IOS for many years.

[TedM]

Wow Roger, going back and editing your initial response to me to ADD in what I said later I stumbled over?  And then adding in multiple "knocks" against me saying I've been told "multiple times"   When were those times?  Oh, yeah.  AFTER your initial post.  I posted my complete config and you could have simply responded "you need to add in the command "no ip address trusted authenticate" and sent me on my way.

Instead, you sent me to a document link that went on and on about it and only obliquely mentions it:

in it's config it says:

voice service voip
 no ip address trusted authenticate

but it does not explain the significance, nor does it refer to as "toll restriction"

The Cisco documentation you linked to did does not state that turning CUBE / SBC functionality will prevent the device from working as a POTS gateway.  In fact with complex VOIP environments where the ISR is used as a CUBE it is quite likely if they have a pots gateway involved, they WILL be using POTS ports in it.  This is the problem - the Cisco documentation omits the issue with debugging output changing when that command is used.

IP addresses on a public post are often obscured by changing them, this is a basic security precaution.  Your guess is correct.  Since I said in the original post that the setup was working for inbound POTS calls, so logically if that is correct then the actual IPs in use are also correct.

I happen to have a 1700 running IOS 12 I just checked and no, the toll restriction did NOT exist in it.  Cisco added that in IOS 15.1(2)T and I presume moved it into the mainline in ISO 16 I don't call that "many years"  More importantly, virtually every guide out there on the Internet taking about using a Cisco device as a voice to pots GW, including many posts on this in this very forum, were written based on older IOS versions like 12 which lacked this so those guides lack it.

Speaking of documentation a much better link than yours would have been:

Cisco Unified Border Element (CUBE) - Cisco Unified Border Element (CUBE) / SIP Trunking Solutions - Cisco

"

Cisco Unified Border Element to Third-Party IP PBX

These application notes detail configurations to use when connecting the Cisco Unified Border Element to various non-Cisco devices using SIP or H.323 protocol."

Although, sadly, since those were all written BEFORE ios 15.1(2)T they wouldn't talk about it - except- wait a minute - clicking on the suggested Zoom config for IOS 14.1 reveals - drumroll - a config for ISO 17 which DOES have the troublesome "toll block" statement.

Too bad I didn't stumble over this appnote:

Toll-Fraud Prevention Feature in IOS Release 15.1(2)T

But there you have it - sure is easy to turn up documentation links warning about the problem AFTER you have figured out what the problem actually is.

[Roger Kallberg]

Sorry you feel that you didn't get the help you wanted/expected.

Where did I go back and add that information you say that I did? I looked at the edit history of my two altered responses and in no way I can see what your seeing.

By what I can tell I went back and corrected two spelling mistakes.

That document that you shared wouldn't be applicable to your setup as you are not having an SBC, so Cube functionality isn't applicable and then a document that covers how to setup a Cube wouldn't be applicable either IMHO.

That command you call "the troublesome "toll block"" has very much a merited place of use. It's there to stop anyone to unsolicited be able to send VoIP traffic via the router.

Putting in this is a quite risky thing, that I would recommend you to not do.

voice service voip
 no ip address trusted authenticate

 As you say this came in 15.1(2)T, that by my count came out in 2010, so a good 15 years since, in my view that's quite some time ago. To get more information on how this operates and what you can do to see that it's in effect please have a look at this post. Toll−Fraud Prevention Feature in IOS Release 15.1(2)T 

[TedM]

"That command you call "the troublesome "toll block"" has very much a merited place of use. It's there to stop anyone to unsolicited be able to send VoIP traffic via the router."

It's completely unnecessary and redundant since a standard access list on either the inside or outside interface can be setup that will do the same thing.  It's default is OFF so what's really going on is Cisco stuck it in there for dummies who don't know enough about building access lists and securing their network to put in a basic ACL

"Putting in this is a quite risky thing, that I would recommend you to not do.

voice service voip
 no ip address trusted authenticate

"

You don't know my environment so you can't advise me what's best for my environment.  Nor can Cisco.  The fact is in my particular environment the phone infrastructure and VoIP infrastructure is on a separate vlan that is blocked from the main network by acl's on different gear, so I don't have to worry about it.

But yes, as general advice, it's better to put in the IPs of the peers involved.  It's even better to put ACLs on the interfaces and dispense with this nonsense.  But, all of the security must get applied AFTER stuff is working.   The proper way is to build up then apply security, not start out by security applied then have to punch holes in it and things break.

And yes I'm aware of that particular religious argument in networking.  But the fundamental basis for releasing network devices with everything locked down is that the end users are idiots who don't understand networking and are just using cookie-cutter setups with 100% of the networking gear provided by a single vendor.  Well, you can take your homogenous networks and stick them where the sun don't shine.  I build best-of-breed networks as do a lot of other people.  I welcome Cisco to play in that sphere and in some of their products - they do.  Others, well let's just say other of their products are cheap crappy relabeled Chinese junk that would be an embarrassment to have in the network center.  Much of their lower end Meraki stuff is like this.

The UCM and the Cisco telco gear is a rather unique animal.  Some of their telco gear like a CP-8865 running 3PCC software is a work of art.  Or the ISR4321 which I'm working with.  Other of their telco gear...well the less said the better.  Their telco people seem to want to have a foot in both markets - one foot in the proprietary Cisco-only market sold for ridiculous amounts to dummies, the other foot in the best-of-breed market where people put together solutions from different vendors.  It's too bad they just can't make up their mind whether they want to go head-to-head with what's left of Polycom, and Sangoma, or whether they want to create golden-handcuff-only products.  Once upon a time they only wanted to go head to head with best-of-breed, but today....today I think they compromised their principles in many places.

[Roger Kallberg]

Let’s stop this nonsense flame war as it’s not leading anywhere.

[Nithin Eluvathingal]

As @Roger Kallberg mentioned in your case, there is no need to activate Mode Border.