Last week I was knee deep in SIP. To be totally honest, I haven’t really had a customer who has wanted to use SIP this many ways ever. We’re doing SIP integration to Unity Connection, all of the phones will be registered as SIP devices, we have several SIP trunks spread throughout the organization in addition to the integration with Cisco Unified Presence Server. Every time I turned around there was some new SIP profile I was making .
Everything went uncharacteristically well. Everything that is, unless you count some trust issues that CUBE and I had. I guess that’s wrong, the CUBE trusted me just fine, it was just some of these other devices that I wanted it to talk to that it wouldn’t trust. I tried to speak to it rationally and tell it that I knew these devices and it could trust them, but no go.
You see, after release 15.1(2) of IOS, Cisco made some toll fraud prevention measures default. One of these measures is to have the router automatically add IP addresses that you point to with dial-peers to the ip address trust list. That’s a list that tells the router who it will accept incoming setups from. By entering this simple command, you can even see who the router has deemed trustworthy:
show ip address trusted list
At face value, this looks like a great feature. You get some toll fraud prevention and you don’t actually have to do anything to set it up. It works great, unless you have a situation like I did.
When something is set up by default for you, if it doesn’t work it’s not often the first place you look because it was set up for you automatically and it should work. When I set up my connection to a SIP trunk provider, they provided me with a name. A lot of providers that I have worked with will provide a DNS name instead of an IP address because then they can change the IP address on me and I don’t have to make any changes to my configuration. Once DNS refreshes, it all just works. For those of you that have been paying attention, you’ll notice when I refer to this feature I call it “ip address trust list” because that’s what Cisco calls it. They didn’t call it the “ip address or name trust list” or the “ip connection trust list” or the “network buddies list”, though I think they should have chosen the last one. What I’m getting at is that you can’t put a DNS name in the ip address trust list.
I thought I must have been mistaken. Surely there must have been some other command that allowed me to add a DNS name to be trusted. I looked. I searched. Then I called TAC. I laid out the situation to the engineer that I had on the phone and he said what you simultaneously like to hear and dread hearing from a TAC engineer, “I don’t know, let me see what I can find.” (It’s good because that means it’s not easy and you didn’t prematurely open a case, it’s bad because you don’t know how long this will take). After a good deal of time he finally came back to me and told me that if I wanted to trust that host I would have to resolve it’s name manually and put it in the ip address trust list manually. I asked if he was sure. I asked if there was any other way that I could do it with a DNS name and he shot me down at every turn.
So, dejected I did as I was told I needed to do. For those that haven’t worked with the ip address list trusted command, here is where it is configured in your router:
voice service voip ip address trusted list ipv4 x.x.x.x y.y.y.y
Where the x is the IP address and the y is the mask. Relatively simple to set up, but again, no names!