Article covers configuration impact on 'service aaa' behaviour in case RADIUS server stops responding to Accounting Requests. Tested against SmartNode 4112 running SmartWare 6.5 and Freeradius server version 2.1.10.

Our goal was to pursue a solution in which SmartNode would block new call attempts when it's impossible to store Accounting records. Since RADIUS protocol runs UDP for transport the only way to mark server as unavailable is due client's multiple request resend and timeout event in case no reply follows from server. Question which this article answers are: 

• what happens to the call in different states: Setup, Call Proceeding and Connected when RADIUS server is marked unavailable
• how does the state initial RADIUS request is sent impact the call drop
• if interim update messages support this process in any way

Initial SmartNode configuration:

radius-client RC-Lab-playground
  radius-server 2.3.4.5 1813
  shared-secret authentication <rad_secret>

profile aaa PROF-AAA-RADIUS-CDR
  method 1 radius RC-Lab-playground

context cs switch

  routing-table called-e164 RT-CLDe164-FROMFXS
    route .T dest-interface IF-SIP-00 

  routing-table called-e164 RT-CLDe164-FROMSIP
    route 123 dest-interface IF-FXS-00 

  interface sip IF-SIP-00
    bind context sip-gateway SIP-GW-1
    route call dest-service SRV-AAA-RADIUS-CDR.TO-FXS
    remote 1.2.3.4

  interface fxs IF-FXS-00
    route call dest-service SRV-AAA-RADIUS-CDR.TO-SIP
    subscriber-number 123

  service aaa SRV-AAA-RADIUS-CDR
    nas-identifier TestingSN4112
    accounting use profile aaa PROF-AAA-RADIUS-CDR
    call-transfer
    allows-push-back

    port TO-FXS
      route call dest-table RT-CLDe164-FROMSIP

    port TO-SIP
      route call dest-table RT-CLDe164-FROMFXS

context cs switch
  no shutdown

'service aaa' configuration modifications and outcome

1. accounting failure-action drop-call

This command main role is to discard newly created calls in case RADIUS server is marked as unavailable, by setting 'service aaa' into FAILED mode. What is important default 'service aaa' configuration sends Accounting Request on call "CONNECT" event, thanks to command: 'accounting start-trigger connect'.

We added following configuration:

context cs
  service aaa SRV-AAA-RADIUS-CDR
    accounting failure-action drop-call

Behaviour you should expect from such config:

RADIUS Server fails during connected call

1. RADIUS Server is: active
2. service aaa state is: no failure
3. Call Setup is triggered on the gateway 
4. Call moves succesfully to Call Progress
5. Call moves succesfully to Connect state 
6. Accounting Request message 'Start' is triggered
7. Server replies with Accounting Reply
8. Then RADIUS server crashes
9. Call follows without disturbances until it's placed in "Hangup" state by the User

 RADIUS Server failed and there was at least one call placed after the crash

1. RADIUS Server is: FAILED
2. service aaa state is: FAILED
3. Call Setup is triggered on the gateway 
4. SmartNode terminates the call with: "Dropping call because of previous accounting failure."

RADIUS Server failed but there was no call placed after this event

1. RADIUS Server is: FAILED
2. service aaa state is: no failure
3. Call Setup is triggered on the gateway 
4. Call moves succesfully to Call Progress
5. Call moves succesfully to Connect state 
6. Accounting Request message 'Start' is triggered
7. There is no answer from RADIUS Server
8. SmartNode generates a: Received AAA answer (Type:TRANSACTION TIMED OUT) event
9. SmartNode drops the call
10. SmartNode marks service aaa state as FAILED

RADIUS Server crashes during Call Progress state

1. RADIUS Server is: active
2. service aaa state is: no failure
3. Call Setup is triggered on the gateway 
4. Call moves succesfully to Call Progress
5. Then RADIUS server crashes
6. Call moves succesfully to Connect state 
7. Accounting Request message 'Start' is triggered
8. There is no answer from RADIUS Server
9. SmartNode generates a: Received AAA answer (Type:TRANSACTION TIMED OUT) event
10. SmartNode drops the call
11. SmartNode marks service aaa state as FAILED

Above scenario shows that SmartNode with current configuration, in the event of RADIUS server crash won't drop a Call that didn't leave the "Call Progress" state .

2. accounting start-trigger setup

Our next goal was to move the Accounting Request transmission sooner in the call flow. Above command causes the Accounting Request to be generated on Call Setup event instead on the Connect which is used as default. One thing worth mentioning about this configuration option is that although SmartNode triggers Accounting Start message on Call Setup event it will be sending an additional Accounting Interim Update message on Call Connect.

We introduced following configuration modifications:

context cs
  service aaa SRV-AAA-RADIUS-CDR
    accounting failure-action drop-call
    accounting start-trigger setup

Behaviour you should expect from such config. We are skipping the 'server fails during Connected Call' scenario as it would be the same as above.

RADIUS Server failed and there was at least one call placed after the crash

1. RADIUS Server is: FAILED
2. service aaa state is: FAILED
3. Call Setup is triggered on the gateway 
4. SmartNode terminates the call with: "Dropping call because of previous accounting failure."

RADIUS Server failed but there was no call placed after this event

1. RADIUS Server is: FAILED
2. service aaa state is: no failure
3. Call Setup is triggered on the gateway 
4. Accounting Request message 'Start' is triggered
5. Call moves succesfully to Call Progress
6. Optional: Call moves succesfully to Connect state 
7. Optional: Accounting Request 'Interim Update' on event Connect is triggered
8. There is no answer from RADIUS Server for 'Start'
9. Optional: There is no answer from RADIUS Server for 'Interim Update'
10. SmartNode generates a: Received AAA answer (Type:TRANSACTION TIMED OUT) event
11. SmartNode drops the call
12. SmartNode marks service aaa state as FAILED

RADIUS Server crashes during Call Progress state

1. RADIUS Server is: active
2. service aaa state is: no failure
3. Call Setup is triggered on the gateway
4. Accounting Request message 'Start' is triggered 
5. Call moves succesfully to Call Progress
6. Server replies with Accounting Reply for 'Start'
7. Then RADIUS server crashes
8. Call moves succesfully to Connect state 
9. Accounting Request 'Interim Update' on event Connect is triggered
10. There is no answer from RADIUS Server for 'Interim Update'
11. SmartNode generates a: Received AAA answer (Type:TRANSACTION TIMED OUT) event
12. SmartNode drops the call
13. SmartNode marks service aaa state as FAILED

Above scenario shows that SmartNode with current configuration, in the event of RADIUS server crash won't drop a Call that didn't leave the "Call Progress" state .

3. accounting interim-updates 300

Although above configuration modifications gave us additional control over Call in Progress state, still we haven't been able to drop a call that succesfully passed the Call Setup or Connect state and their corresponding Accounting Record was succesfully stored on RADIUS Server. In his case the 'interim-updates' command come handy causing SmartNode to send an Accounting Request 'interim Update' every configured interval. Minimal value available in this context is 300 seconds.

Following configuration modifications were delivered:

context cs
  service aaa SRV-AAA-RADIUS-CDR
    accounting failure-action drop-call
    accounting start-trigger setup
    accounting interim-updates 300

Behaviour you should expect from such config. 

RADIUS Server fails during connected call

1. RADIUS Server is: active
2. service aaa state is: no failure
3. Call Setup is triggered on the gateway
4. Accounting Request message 'Start' is triggered 
5. Call moves succesfully to Call Progress
6. Server replies with Accounting Reply for 'Start'
7. Call moves succesfully to Connect state 
8. Accounting Request 'Interim Update' on event Connect is triggered
9. Server replies with Accounting Reply for 'Interim Update'
10. Call stays in Connected state for 5 minutes
11. In the meantime RADIUS server crashes
12. After 5 minutes from Request 'Start' the recurring Accounting Request 'Interim Update' is triggered
13. There is no answer from RADIUS Server for 'Interim Update'
14. SmartNode generates a: Received AAA answer (Type:TRANSACTION TIMED OUT) event
15. SmartNode drops the call
16. SmartNode marks service aaa state as FAILED

RADIUS Server crashes during Call Progress state

1. RADIUS Server is: active
2. service aaa state is: no failure
3. Call Setup is triggered on the gateway
4. Accounting Request message 'Start' is triggered 
5. Call moves succesfully to Call Progress
6. Server replies with Accounting Reply for 'Start'
7. Call stays in Call Progress state for 5 minutes
8. In the meantime RADIUS server crashes
9. After 5 minutes from Request 'Start' the recurring Accounting Request 'Interim Update' is triggered
10. There is no answer from RADIUS Server for 'Interim Update'
11. SmartNode generates a: Received AAA answer (Type:TRANSACTION TIMED OUT) event
12. SmartNode drops the call
13. SmartNode marks service aaa state as FAILED

4. reference: accounting start-trigger connect

For rerefence we switched the 'accounting start-trigger' option back to 'connect' state. Our purpose was to pinpoint the difference between 'setup' and 'connect' working together with 'accounting interim-updates 300'

We switched the configuration to:

context cs
  service aaa SRV-AAA-RADIUS-CDR
    accounting failure-action drop-call
    accounting start-trigger connect
    accounting interim-updates 300

Behaviour was as following:

RADIUS Server fails during connected call

1. RADIUS Server is: active
2. service aaa state is: no failure
3. Call Setup is triggered on the gateway
4. Call moves succesfully to Call Progress
5. Call moves succesfully to Connect state 
6. Accounting Request message 'Start' is triggered 
7. Server replies with Accounting Reply for 'Start'
8. Call stays in Connected state for 5 minutes
9. In the meantime RADIUS server crashes
10. After 5 minutes from Request 'Start' the recurring Accounting Request 'Interim Update' is triggered
11. There is no answer from RADIUS Server for 'Interim Update'
12. SmartNode generates a: Received AAA answer (Type:TRANSACTION TIMED OUT) event
13. SmartNode drops the call
14. SmartNode marks service aaa state as FAILED

RADIUS Server crashes during Call Progress state

1. RADIUS Server is: active
2. service aaa state is: no failure
3. Call Setup is triggered on the gateway
4. Call moves succesfully to Call Progress
5. Call stays in Call Progress state for 5 minutes
6. In the meantime RADIUS server crashes
7. Call follows without disturbances until it's placed in "Hangup" state by the User

Above scenario is possible only because there were no Accounting Request triggered in Call Control. Of course in case Call would enter "Connect" state it would be dropped by SmartNode.