Traditionally, VOIP dial peers follow a fairly limited creation process. You can match a single pattern and direct to a single destination. For instance, if we would like to send a call with the destination number 408-123-1234 to unified communications manager at 192.168.1.10 explicitly matching all but the last 4 digits our dial peer would look something like this:
dial-peer voice 100 voip destination-pattern ^408123….$ session protocol sipv2 session target ipv4:192.168.1.10 dtmf-relay rtp-nte no vad
This configuration is perfect for a single SIP trunk to single CUCM environment. Because most businesses demand high availability there is very likely to be a Publisher node and one or more Subscriber nodes. Obviously the loss of a single server node would end our call flows with the configuration above. The original method of addressing this is to simply add another dial-peer with the same pattern and different target address.
dial-peer voice 100 voip destination-pattern ^408123….$ session protocol sipv2 session target ipv4:192.168.1.10 dtmf-relay rtp-nte no vad dial-peer voice 101 voip destination-pattern ^408123….$ session protocol sipv2 session target ipv4:192.168.1.11 dtmf-relay rtp-nte no vad
The default matching of the dial-peers works as follows:
- The longest match.
- Preference
- Random Selection
In our case we have no “longest match” as the patterns are the same. Likewise, there is no preference set meaning the preference is “0” by default. Finally, random selection, which rules the day in this case. Personally, I don’t like leaving things to a pure random selection. Fortunately, there are a number of ways to influence this behavior.
R3(config)#dial-peer hunt ?
Dial-peer hunting choices, listed in hunting order within each choice:
0 - Longest match in phone number, explicit preference, random selection.
1 - Longest match in phone number, explicit preference, least recent use.
2 - Explicit preference, longest match in phone number, random selection.
3 - Explicit preference, longest match in phone number, least recent use.
4 - Least recent use, longest match in phone number, explicit preference.
5 - Least recent use, explicit preference, longest match in phone number.
6 - Random selection.
7 - Least recent use.Most of these options should be self-explanatory. The “least recent use” option would essentially load balance between the two destinations. You could use this when directing calls toward to a pair of subscribers within a single site. Explicit preference would be an option more aligned with a fail over scenario. Sending all calls to the subscriber and using the publisher only as a last resort, as an example. These two items could also be combined in usage. For instance, two dial peers with a default preference directed to Subscribers and a higher numeric preference dial peer pointed to the Publisher for backup. This scenario would work best with hunt option “1” selected. An example would look something like this:
dial-peer voice 100 voip description *** To Subscriber 1 *** destination-pattern ^408123….$ session protocol sipv2 session target ipv4:192.168.1.10 dtmf-relay rtp-nte no vad dial-peer voice 101 voip description *** To Subscriber 2 *** destination-pattern ^408123….$ session protocol sipv2 session target ipv4:192.168.1.11 dtmf-relay rtp-nte no vad dial-peer voice 102 voip description *** To Publisher *** preference 2 destination-pattern ^408123….$ session protocol sipv2 session target ipv4:192.168.1.12 dtmf-relay rtp-nte no vad
These options all included specific tweaking of dial-peers but still require a dial-peer per destination call processor. In IOS XE 3.11S and IOS 15.4(1)T a new concept of server groups was created. A server group is something created as a voice class similar to how a codec list or other parameters are defined. This class enumerates call processing servers rather than codec, however. Let’s have a look at the example:
voice class server-group 1 ipv4 192.168.1.10 preference 2 ipv4 192.168.1.11 preference 2 description *** Server Group to Sub1 and Sub2 ***
This configuration is then applied as a dial-peer attribute behind the session key word.
dial-peer voice 100 voip destination-pattern ^408123….$ session protocol sipv2 session server-group 1 dtmf-relay rtp-nte no vad
In this example the calls will be randomly distributed between the two servers. A round robin hunting option is available under the server group configuration as well as a preference that can also be assigned per server. To review the server group settings use the “show voice class server-group <group number>” command.
R3#show voice class server-group 1 Voice class server-group: 1 AdminStatus: Up OperStatus: Up Hunt-Scheme: preference Last returned server: Description: *** Server Group to Sub1 and Sub2 *** Total server entries: 2 Pref Type IP Address IP Port ---- ---- ---------- ------- 2 ipv4 192.168.1.10 2 ipv4 192.168.1.11 -------------------------------------
To conclude this discussion it’s also worth noting that these options can be combined. As an example, I might have a single dial-peer pointed toward a server group for my Subscribers and a second dial-peer with a higher priority directed to the publisher. The result would be call balancing between the two Subscribers and and the Publisher being available to take calls should those two fail.
I hope you have found this information useful. Feel free to comment or question below!
Our RSS Feed