voice class server-group preferences

[Richard Pidcock]

Can someone point me to a good reference for usage of "voice class server-group".  Specifically, I'm trying to understand the logic of preferences.  In my scenario, while all call manager nodes are up, all calling is successful.  I'm trying to simulate the failure of a call manager node, so I shut down one of my CUCM subscriber nodes (in this case, the node under preference 1) and then test calling again but calling then fails.  If I add "hunt-scheme round-robin" into my server-group, it will then follow round-robin logic and the call then only fails every third time (i.e. when it tries to use the down CUCM node). 

I was expecting that with preferences if one of the listed nodes was not available (i.e. the preference 1 node is down) that it would roll to the preference 2 node?  See a sample of my config below:

!
voice class e164-pattern-map 208
description Area code 208 TNs to CUCM
e164 208xxxyyyy
e164 208xxxyyyy
!
!
!
voice class server-group 141
ipv4 1.2.3.4 preference 1
ipv4 1.2.3.5 preference 2
ipv4 1.2.3.6 preference 3
description Servers_CUCM
!
!
dial-peer voice 82081 voip
description to CUCM 208 Area Code TN's
call-block translation-profile incoming call_block
huntstop
session protocol sipv2
session server-group 141
destination e164-pattern-map 208
voice-class codec 99
voice-class sip early-offer forced
dtmf-relay rtp-nte
no vad
!

[Roger Kallberg]

I believe that you'd need to add SIP option ping into this so that it can mark the target as down in the server group. Test what the outcome will be by adding this to your configuration.

voice class sip-options-keepalive 1
 description Used for Server Group SIP OPTIONS PING
!
dial-peer voice 82081 voip
 voice-class sip options-keepalive profile 1

If you do a "show voice class sip-options-keepalive" you should get an output like this with a state for each of the IPs in the server group..

Voice class sip-options-keepalive: 1             AdminStat: Up
 Description: Used for Server Group SIP OPTIONS PING
 Transport: system               Sip Profiles: 0
 Interval(seconds) Up: 60                Down: 30
 Retry: 5

  Peer Tag      Server Group    OOD SessID      OOD Stat        IfIndex     
  --------      ------------    ----------      --------        -------     
  202           1                               Active          20          

  Server Group: 1                OOD Stat: Active
   OOD SessID   OOD Stat    
   ----------   --------    
   1            Active      
   2            Active      
   3            Active      

 OOD SessID: 1                   OOD Stat: Active
  Target: ipv4:10.192.40.40
  Transport: system              Sip Profiles: 0

 OOD SessID: 2                   OOD Stat: Active
  Target: ipv4:10.64.160.40
  Transport: system              Sip Profiles: 0

 OOD SessID: 3                   OOD Stat: Active
  Target: ipv4:10.138.16.40
  Transport: system              Sip Profiles: 0

[Richard Pidcock]

Thanks @Roger Kallberg , I'll implement this as suggested.   I will test again and advise of the results.

[Roger Kallberg]

Another thing I would suggest that will simplify your tests of a CM being down is to add a NULL route for the specific IP instead actually shutting down the server. That would make the process a lot easier and you can do it without affecting so many other things.

[Richard Pidcock]

Excellent advice.  Hadn't thought of that but I love it, and yes, simplifies testing without affecting alot of other things, or a reboot of a CUCM node..

[Richard Pidcock]

So over the weekend I tried the configurations and testing as suggested but was still unsuccessful.  I added the "voice class sip-options-keepalive 1" and added it to the dial-peer, however when adding the null route for the respective subnet I never saw the session get marked as "down", it remained in an active state.  I went ahead and shutdown the CUCM node, just to know with 100% certainty that the node was unreachable, and yet I still didn't see the expected state change, it remained to be in an active state when issuing the "show voice class sip-options-keepalive" command.    Later in this thread you suggested using "huntstop 1 resp-code 404 to 404", do you think that had any effect on my testing?  Thoughts?

Thanks,

[Roger Kallberg]

No that should not have any impact on this. What that command does it to stop the call routing process to try all servers when you get a 404 not found from the first server as that would simply result in the same response from all the other servers.

[Roger Kallberg]

I just tested this on one of our test routers and it does set the server as busy when you have SIP option ping in the mix.

selurt-cube-03#show dial-peer voip keepalive status
 TAG        TENANT   DESTINATION                    OOD-SessID   PRI     WT      STATUS
 1010       -        sess-svr-grp:1        
                      ipv4:10.64.160.32             1            -       -       busyout
                      ipv4:10.64.160.33             2            -       -       active
                      ipv4:10.64.160.34             3            -       -       active



selurt-cube-03#show voice class sip-options-keepalive
Voice class sip-options-keepalive: 1             AdminStat: Up
 Description: Used for Server Group SIP OPTIONS PING
 Transport: system               Sip Profiles: 0
 Interval(seconds) Up: 60                Down: 30
 Retry: 5

  Peer Tag      Server Group    OOD SessID      OOD Stat        IfIndex     
  --------      ------------    ----------      --------        -------     
  1010          1                               Active          9           

  Server Group: 1                OOD Stat: Active
   OOD SessID   OOD Stat    
   ----------   --------    
   1            Busy        
   2            Active      
   3            Active      

 OOD SessID: 1                   OOD Stat: Busy
  Target: ipv4:10.64.160.32
  Transport: system              Sip Profiles: 0

 OOD SessID: 2                   OOD Stat: Active
  Target: ipv4:10.64.160.33
  Transport: system              Sip Profiles: 0

 OOD SessID: 3                   OOD Stat: Active
  Target: ipv4:10.64.160.34
  Transport: system              Sip Profiles: 0

With that it is not suppose to pass any calls on-wards to that server. If it does that would negate the whole thing with using SIP option ping.

[Roger Kallberg]

I would also recommend that you use a IOS version where you have the possibility to set this huntstop 1 resp-code 404 to 404 in the server group. I think it came in either 17.5 or 17.6, we're on 17.6.4 and it has it.

[Richard Pidcock]

Running 17.6.5 in our environment so that won't be a problem.  

[Elliot Dierksen · Accepted solution]

It could also be that the gateway is taking too long before failing over to the next preferred server. The default timing and retries are way too long! Try adding this to the gateway config. I use this in production at multiple customers and it works well.

sip-ua
 retry invite 1
 timers trying 250

[Richard Pidcock]

@Elliot Dierksen , thanks for your feedback and recommendations also.  I didn't initially try your suggestion, but after unsuccessful results over the weekend I revisited the issue to continue troubleshooting.  This morning I implemented your recommedations and this seem to have corrected my problem condition.

Thanks again to both you and @Roger Kallberg