Blog Archives
Using DNS SRV Records with IOS Dial Peers
Ah… IOS. Refreshing after spending a week with ACME Packet’s ACLI. And at the same time it certainly has it’s own frustrations. It took me a while to get this working in my lab (partially because I was in Boston and my lab is most decidedly not), but I have a feeling DNS SRV records with SIP are going to prove very useful to me in the future.
The goal here: use DNS SRV records to minimize the number of dial-peers required in IOS. Typically CUCM is set up in some sort of redundant fashion so that there are multiple call processing servers. Going deeper, the configuration of CUCM is such that CM Groups are created with a max of three servers per group meaning everything needs to be pointed at two or three different servers in case one goes down. So we want to use one dial-peer to send a particular call to a CM Group made up of three servers rather than the usual three.
VoIP dial-peers use session targets to determine where to send a matching call. With no DNS SRV records each pattern would require three dial-peers using preference commands as shown below (Note: The use of an ipv4: target vs dns: target makes no difference here, I am using ipv4 in this example for contrast. DNS A records for each server would still require three dial-peers, it is only with DNS SRV records that we can collapse three dial-peers down into one).
dial-peer voice 1 voip destination-pattern 2000 preference 1 session protocol sipv2 session target ipv4:10.0.0.1 dial-peer voice 2 voip destination-pattern 2000 preference 2 session protocol sipv2 session target ipv4:10.0.0.2 dial-peer voice 3 voip destination-pattern 2000 preference 3 session protocol sipv2 session target ipv4:10.0.0.3
With DNS SRV records we can cut this down to one dial-peer:
dial-peer voice 1 voip destination-pattern 2000 session protocol sipv2 session target dns:cmgroup1.lab.local
along with a little extra config (to host the DNS SRV records in IOS to remove reliance on the corporate DNS server)
ip host cucm1.lab.local 10.0.0.1 ip host cucm2.lab.local 10.0.0.2 ip host cucm3.lab.local 10.0.0.3 ip host _sip._udp.cmgroup1.lab.local srv 1 50 5060 cucm1.lab.local ip host _sip._udp.cmgroup1.lab.local srv 1 50 5060 cucm2.lab.local ip host _sip._udp.cmgroup1.lab.local srv 1 50 5060 cucm3.lab.local ip name-server 127.0.0.1 ip domain name lab.local
Finally, in order for a CUCM subscriber server to accept a SIP URI with a destination of @cmgroup1.lab.local rather than @<servername>.lab.local each parent DNS SRV records (cmgroup1.lab.local) must be added to the Cluster FQDN list in Enterprise Parameters. If this step is not completed, expect to see SIP 404 Not Found errors. From the CUCM Help:
This parameter defines one or more Fully Qualified Domain Names (FQDN) for this cluster. Multiple FQDNs must be separated by a space. Wildcards can be specified within an FQDN using an asterisk (*). Examples are cluster-1.rtp.cisco.com and *.cisco.com. Requests containing URLs (for example, SIP calls) whose host portion matches any of the FQDNs in this parameter will be recognized as a request destined for this cluster and/or devices attached to it.
Many thanks to these helpful resources, the first in the list is an especially good resource:
Gateway Configuration for SIP Proxy Redundancy
Load Balance Between SIP Dial-Peers
Designing Unified CVP for High Availability
Cisco IOS SIP Configuration Guide, 15.0
ACME Packet Training
I spent the last week in Boston, MA at ACME Packet taking a configuration basics course for their Net-Net 4000 products. For those not familiar with ACME Packet, they make Session Border Controllers for VoIP applications. They claim to be the inventor of the SBC and historically have sold to carriers (and done very well). They recently bought Covergence, aiming to take a stab at the enterprise & commercial market with their rebranded Net-Net 2600.
A few thoughts from the last week:
- Anyone who is familiar with 1) configuring network devices via a CLI and can telnet/ssh/ftp via a command line and 2) VoIP & SIP should skip straight to their advanced configuration class. Out of the five days only two were all that useful (Wed/Thur when we talked about basic SIP config for the Net-Net in Access Backbone and Peering environments).
- These products are powerful in a big way. Very impressed by the product both in terms of features and scalability.
- I’m a little green (only been in the industry 3-4 years), but in my mind ACME has put together a horrendous CLI (they call it the ACLI, ACME CLI). I really like where they’re headed with the object-oriented nature, but the implementation is downright scary. Even the simplest configuration tasks quickly become painful. Be ready for huge, complex configs while you curse & swear at your keyboard finding yourself yet again lost in their poorly labeled contexts.
- Their Net-Net 2600 is an especially interesting product in that it fits very well in the enterprise & commercial space. On-box transcoding up to 400 sessions and (according to them) all the same features as their 3800-4500 products make for quite the SBC. If you figure 400 sessions is ~17 PRIs you can see this “low-end” model will scale very well for most organizations. And that’s only if you need transcoding. Take out the transcoding and the session limits go sky-high like their other products. I’m very interested in taking the config class for the 2600 product.
- Pricing. I’ve only heard rumors, but it sounds like their products are ridiculously expensive. I think the pricing might have worked well in the carrier space, but they may have a difficult time penetrating the enterprise market if the numbers I’ve heard are actually true. If I can buy 10 3900-series ISR G2’s from Cisco for the same price as one ACME Net-Net I’m going to have a tough time justifying the purchase to mgmt even if it is the better product.
benpolzin 
