RADIUS
In 1997, the Internet Engineering Task Force (IETF) finalized the RADIUS protocol specification as RFC 2058. It was superseded by RFC 2138 and later RFC 2865. RFC 2059 was the first RADIUS accounting standard; it was made obsolete by RFC 2139 and later RFC 2866. Note the difference between the RADIUS protocol specification (RFC 2865) and the RADIUS accounting specification (RFC 2866). Although both are IETF standards, RFC 2866 is an informational standard only, and RFC 2865 is a formal IETF standard.
The RADIUS specification contains client and server roles, where the NAS performs the client role. Splitting the functionality provides the foundation for scalability, because a single RADIUS server can serve multiple clients (NASs), resulting in a single data store for user credentials. Two different RADIUS packet types exist: authentication and accounting packets. The NAS sends authentication requests to the RADIUS server to check the user's identity. This request consists of the user credentials and NAS IP address or identifier. The RADIUS server sends authentication replies that include the reply code and a set of additional attributes. An accounting request is sent to the server when the NAS reports an event, such as the session start and termination. For each successfully processed accounting request, the RADIUS server returns an accounting acknowledgment, which informs the NAS that the information was received. This handshake mechanism avoids packet loss over the UDP protocol. Authorization takes places after successful authentication. For example, your company may have policies for prohibiting access to sensitive information (such as finacial data or source code) over the Internet. In this case, even successful authentication would not grant access to sensitive data.
A typical user session occurs as follows: When a user connects to a NAS, first it verifies that the user is actually registered and that the supplied credentials are correct: this step is called authentication. The NAS forms an authentication request and sends it to the RADIUS server, which then verifies the user's credentials against the database. The acknowledgment packet is returned to the NAS. The server reply advises the NAS to assign an IP address to the user and to establish a connection between the user and the server that the user intends to connect to, assuming that the authentication was accepted.
As the second step, the NAS determines which services the user is permitted to use and optionally applies specific resource limitations for an individual or group. This step is called authorization. Authorization can be implemented in several ways, such as applying a preconfigured access control list (ACL) to restrict the user's access to resources and services based on one or more metrics (time of day, transport type, user group).
After a successful authentication and authorization, the NAS establishes a connection between the user and the application server. Now application data can be transmitted, while so far only access and authorization control traffic was exchanged. At this time, accounting starts as follows: the NAS stores the session's start time and generates an accounting-requests packet for the AAA server. The initiating packet is called "accounting-start," and the terminating packet is called "accounting-stop." During the session, optional accounting update packets can be sent. For each request, the AAA server replies with an accounting-response. A usage record typically consists of the session's start and stop times, duration, and number of input and output octets and packets transferred. Each AAA session consists of at least two report messages:
Accounting-start request message with the start time
Accounting-stop request message with the stop time and full accounting details
Figure 9-2 illustrates the interaction between the NAS and the RADIUS server.
Figure 9-2. RADIUS Interaction
RADIUS Attributes
RADIUS attributes carry the specific authentication, authorization, accounting, and configuration details for the request and response. Attributes are exchanged between the NAS and the server. Each attribute is associated with a set of properties that specifies how to interpret it. The most important property is the data type, which declares the type of data that the attribute identifies (character string, integer number, IP address, or raw binary data). The information to be transmitted with the request is packaged in a set of attribute/value pairs (AV pairs, or AVP), which consist of attribute numbers and the associated data. RFC 2865 describes the RADIUS protocol and defines the different AAA attributes. Note that RFC 2865 defines attributes 1 through 39 and 60 through 63, whereas 40 through 59 are reserved for accounting and are not defined in RFC 2865. The informational RFC 2866 extends this specification by defining the accounting-specific attributes (40 through 59). RFC 2869 is another informational RFC that extends RFC 2865 by specifying attributes 52 to 55. In summary, RFC 2865 (Standards Track) defines authentication and authorization, and the accounting part is defined in the informational RFCs 2866 and 2869.
Table 9-2 describes the significant RADIUS attributes from an accounting perspective. There are many more attributes. For a complete list, check RADIUS Attribute Types at http://www.iana.org/assignments/radius-types.
| Attribute Name | Type Number | Description | Type of Accounting Request Record | Value |
|---|---|---|---|---|
| User-Name | 1 | The name of the user to be authenticated. | Only Access-Requests | ASCII string |
| NAS-IP-Address | 4 | The identifying IP address of the NAS that is requesting user authentication. | Only Access-Requests | Four octets |
| NAS-Port | 5 | The physical port number of the NAS that is authenticating the user. | Only Access-Requests | Four octets |
| Framed-IP-Address | 8 | The address to be configured for the user. | — | Four octets |
| Vendor-Specific Attribute (VSA) | 26 | Allows vendors to support their own extended attributes that are not suitable for general usage. | — | >= 7 bytes (the vendor-string field must be at least 1 byte) |
| Called-Station-Id | 30 | Allows the NAS to send in the Access-Request packet the phone number that the user called, using Dialed Number Identification Service (DNIS) or a similar technology. This number may be different from the phone number the call came from. | — | ASCII string, DNIS phone number |
| Calling-Station-Id | 31 | Allows the NAS to send in the Access-Request packet the phone number that the call came from, using Automatic Number Identification (ANI) or a similar technology. | — | ASCII string, ANI phone number |
| Acct-Status-Type | 40 | Indicates whether this Accounting-Request marks the beginning (Start) or the end (Stop) of the user service. | — | 1 Start 2 Stop 3 Interim-Update 7 Accounting-On 8 Accounting-Off |
| Acct-Delay-Time | 41 | Indicates how many seconds the client has been trying to send this record for. Can be subtracted from the time of arrival on the server to find the approximate time of the event generating this Accounting-Request. | — | Four octets |
| Acct-Input-Octets | 42 | Indicates how many octets the reporting device has received from the port over the course of this service being provided. | Only Accounting-Request records with Acct-Status-Type = Stop | Four octets |
| Acct-Output-Octets | 43 | Indicates how many octets the reporting device has sent to the port in the course of delivering this service. | Only Accounting-Request records with Acct-Status-Type = Stop | Four octets |
| Acct-Session-Id (overload field) | 44 | A unique Accounting ID to make it easy to match start and stop records in a log file. This field is also used to transfer vendor-specific information elements (ASCII string; maximum 256 characters). | — | ASCII string; maximum 256 characters |
| Acct-Authentic | 45 | Indicates how the user was authenticated—by RADIUS, the NAS, or another remote authentication protocol. | — |
|
| Acct-Session-Time | 46 | Indicates how many seconds the user has received service for. | Only Accounting-Request records with Acct-Status-Type = Stop | Four octets |
| Acct-Input-Packets | 47 | Indicates how many packets have been received from the port over the course of this service being provided to a framed user. | Only Accounting-Request records with Acct-Status-Type = Stop | Four octets |
| Acct-Output-Packets | 48 | Indicates how many packets have been sent to the port in the course of delivering this service to a framed user. | Only Accounting-Request records with Acct-Status-Type = Stop | Four octets |
| Acct-Terminate-Cause | 49 | Indicates how the session was terminated. | Only Accounting-Request records with Acct-Status-Type = Stop |
|
| Acct-Multi-Session-Id | 50 | A unique Accounting ID to make it easy to link several related sessions in a log file. Each linked session would have a unique Acct-Session-Id but the same Acct-Multi-Session-Id. | — | ASCII string |
| Acct-Link-Count | 51 | Gives the count of links that are known to have been in a given multilink session at the time the accounting record was generated. | — | The Value field is four octets. It contains the number of links seen so far in this multilink session. |
| Acct-Input-Gigawords | 52 | Indicates how many times the Acct-Input-Octets counter has wrapped around 2^32 over the course of this service being provided. Defined by RFC 2869. | Only Accounting-Request records with Acct-Status-Type = Stop or Interim-Update | Four octets |
| Acct-Output-Gigawords | 53 | Indicates how many times the Acct-Output-Octets counter has wrapped around 2^32 in the course of delivering this service. Defined by RFC 2869. | Only Accounting-Request records with Acct-Status-Type = Stop | Four octets |
| Unused | 54 | — | — | — |
| Event-Timestamp | 55 | Included in an Accounting-Request packet to record the time that this event occurred on the NAS, in seconds since January 1, 1970 00:00 UTC. Defined by RFC 2869. | — | — |
Note
The AVP Acct-Delay-Time is especially useful in situations in which the NAS creates duplicate accounting records. This can happen during timeouts in the conversation between the NAS and the RADIUS server. A duplicated record is an exact copy of the previous one, except for the Acct-Delay-Time, which indicates how many seconds the client has been trying to send this record. When the accounting record is sent for the first time, this value is always 0, whereas a resend record has a different value. An accounting application can search for accounting records in which all fields are equal, except for Acct-Delay-Time, and eliminate all but one of the records.
RADIUS CLI Operations
This section, which mainly focuses on the accounting part of RADIUS, covers only the most important commands. For the complete list of RADIUS commands, consult the Command Reference document.
router(config)# aaa new-model enables the AAA access control model.
router(config)# aaa group server radius group-name defines the AAA server group with a group name. It groups different RADIUS server hosts into distinct lists and distinct methods.
router(config-sg-radius)# server ip-address [auth-port port-number] [acct-port port-number] configures the IP address of the RADIUS server for the group server.
router(config)# aaa accounting {auth-proxy | system | network | exec | connection | commands level} {default | list-name} [vrf vrf-name] {start-stop | stop-only | none} [broadcast] group groupname configures the accounting for different features:
- system performs accounting for all system-level events not associated with users, such as reloads.
- network runs accounting for all network-related service requests, including Serial Line Internet Protocol (SLIP), PPP, PPP Network Control Protocols (NCP), and AppleTalk Remote Access Protocol (ARAP).
- exec—Runs accounting for the EXEC shell session.
- connection—Provides information about all outbound connections made from the network access server, such as Telnet, local-area transport (LAT), TN3270, packet assembler and disassembler (PAD), and rlogin.
router(config)# aaa accounting update [periodic number] enables periodic interim accounting records to be sent to the accounting server, where the number interval is specified in minutes.
The following example configures the RADIUS authentication and accounting for a user initiating a shell connection to the router. Accounting requests are sent with the start, stop, and periodic (every 1 minute) options. Note the default RADIUS accounting port of 1646. The following examples include the port number for completeness; this information is optional when using the default port.
router(config)# aaa new-model router(config)# aaa group server radius MyAdmin router(config-sg-radius)# server 10.48.66.102 auth-port 1645 acct-port 1646 router(config)# aaa authentication login default group MyAdmin router(config)# aaa accounting update periodic 1 router(config)# aaa accounting exec OpsAcctg start-stop group MyAdmin router(config)# radius-server host 10.48.66.102 auth-port 1645 acct-port 1646 key 7 01100F175804 router(config)# line vty 0 4 router(config-line)# accounting exec OpsAcctg
The RADIUS server would report the following information: Date, Time, User-Name, Group-Name, Calling-Station-Id, Acct-Status-Type, Acct-Session-Id, Acct-Session-Time, Service-Type, Framed-Protocol, Acct-Input-Octets, Acct-Output-Octets, Acct-Input-Packets, Acct-Output-Packets, Framed-IP-Address, NAS-Port, and NAS-IP-Address. The following configuration example shows a leased-line PPP client that uses RADIUS for authentication and accounting:
router(config)# interface Serial2/0 router(config-if)# encapsulation ppp router(config-if)# ppp accounting SerialAccounting router(config-if)# ppp authentication pap router(config)# aaa accounting network SerialAccounting start-stop group MyAdmin
Voice Extensions for RADIUS
The preferred accounting solution for voice over IP is RADIUS. Most voice-specific MIBs are limited to legacy telephony environments. This section examines voice-specific extensions to the RADIUS protocol.
Concept of Call Legs
A call leg is a logical connection between the router and a classic telephony endpoint or another IP telephony endpoint using a session protocol, such as SIP or H.323. For an end-to-end connection, a separate call leg is generated for each segment that lies between two points of the connection. A call processed through a voice gateway, commonly referred to as just a gateway, consists of an outgoing (originate) and incoming (answer) call leg. A voice gateway is a device that allows telephone calls over a high-speed Internet connection. Its primary functions include voice and fax compression and decompression, packetization, call routing, and control signaling. Call leg directions (such as answer or originate) are named and described from the gateway's perspective. An end-to-end call going through an originating and terminating gateway consists of four call legs. Two are from the perspective of the source originating gateway (answer telephony, originate VoIP), and the other two are from the perspective of the destination terminating gateway (answer VoIP, originate telephony). Start-stop accounting has a separate start record and stop record for each call leg. Assuming that a call is established between two voice gateways, start-stop accounting generates four discrete start records and four discrete stop records, in which all eight records have the same ID. Depending on the device configuration, this unique ID is either specified in RADIUS attribute 26 as h323-conf-id or overloaded in RADIUS attribute 44:
h323-conf-id value in RADIUS attribute 26 VSA—h323-conf-id is a RADIUS attribute exported regardless of the voice protocol between the voice gateways. h323-conf-id is sent not only with H.323 configured between the voice gateways, but also when SIP is configured, which might be somewhat confusing. However, with SIP, this value is not identical for all the call legs. Instead, Call-id must be used.
Connection ID in RADIUS attribute 44 "Acct-Session-Id"—Acct-Session-Id works only when the H.323 protocol is used, as opposed to SIP.
Call-id values in RADIUS attribute 26 VSA—Call-id is the way to correlate call legs when SIP is used between voice gateways.
Figure 9-3 illustrates the four different call legs as they are generated through the voice call.
Figure 9-3. Call Leg Naming Convention
The four call legs are as follows:
Call leg 1 goes from the originating device (telephone, PC, fax machine) to the originating gateway. It is called answer telephony.
Call leg 2 is from the originating gateway over the IP cloud to the terminating gateway. It is called originate VoIP.
Call leg 3 is the mirror image of call leg 2. It is called answer VoIP from the perspective of the terminating gateway. The direction of the arrow in call leg 3 represents the call leg pointing to the originating gateway. This signifies that it is from the perspective of the terminating gateway and is the other half of a matching pair of VoIP dial peers for a single call.
Call leg 4 is from the terminating gateway to the terminating device. It is called originate VoIP.
An accounting system collects data for all calls, both legacy voice and VoIP. The most important elements of the data, other than the call's duration, are h323-conf-id and incoming-h323-conf-id, because they are required to correlate the different call legs. These two ID values are identical most of the time. This allows the correlation of the answer telephony call leg 1 (characterized by incoming-h323-conf-id) with the following originate VoIP call leg 2 (characterized by h323-conf-id). Because the h323-conf-id value is sent between the VoIP gateways as part of the H.323 protocol, the next VoIP gateway reports the same h323-config-id value for its call legs. Therefore, the RADIUS server correlates all the call legs of the same call. The billing system can combine the data from multiple call records with the same h323-conf-id value and store the call attributes (direction, duration, destination, source, volume) in its database to create a billing record.
In some cases the h323-conf-id and incoming-h323-conf-id are different. For example, the fact that there are two different ID variables has relevance in debit card calling when the user accesses the long pound facility for multisession calls. In this case, the RADIUS server needs to correlate the first two call legs with the incoming-h323-conf-id value.
When the VoIP signaling protocol between the two voice gateways is SIP, the Cisco AVP containing the Call-id value represents the unique conference ID, similar to h323-conf-id. The Call-id field is a mandatory header field in each call-related SIP message, which requires the next voice gateway to report its call legs with the same Call-id. Therefore, Call-id is the way to correlate call legs in a SIP scenario.
There is a major difference between configuring start-stop and stop-only records at the NAS. From a billing perspective, only the accounting-stop records are required, because they contain the call duration, transmitted volume, etc. Although the Interim-Update packets are not relevant for billing, they provide remarkable details for a performance management system. They contain performance metrics, such as early-packets, h323-voice-quality, lost-packets, round-trip-delay, and others. These are significant details for voice performance management, generated per call. This illustrates another intersection of accounting and performance management.
RADIUS VSAs The latest IETF RADIUS standards (RFC 2865 and RFC 2866) specify that you can use RADIUS attribute 26 to communicate vendor-specific information between a RADIUS client (NAS) and a RADIUS server. Attribute 26 is the VSA in RADIUS records.
The idea of VSAs is to offer vendors the opportunity to create new functions without going through the IETF standards process. This also implies that VSA records are not standardized, which means that different vendor implementations of VSAs might not be interoperable.
The concept of attributes is based on the X.500 definition, in which each attribute consists of a type identifier and one or more values. A VSA is an attribute that has been implemented by a particular vendor. It encapsulates the data as AVPs. The format is
vendor-specific = protocol:attribute = value
For example, cisco-avpair = timezone = UTC is an AVP in which timezone identifies the attribute and UTC is the value.
RADIUS Accounting with the Vendor-Specific Attribute
Cisco voice-specific VSAs are included in requests and responses between the voice gateway and the RADIUS server. The voice gateway, as a RADIUS client, sends and receives VSAs to and from a RADIUS server. Each Cisco voice-specific VSA conforms to the RADIUS specification for attribute 26. Figure 9-4 shows the format of RADIUS VSAs and Cisco voice-specific VSAs.
Figure 9-4. RADIUS VSA Format
Table 9-3 describes the fields in the VSA.
| VSA Field | Definition |
|---|---|
| Type | 26 (vendor-specific) |
| Length | >= 7 bytes (the vendor-string field must be at least 1 byte) |
| Vendor-ID | 9 (or, in binary, 0000 0000 0000 1001). The high-order octet is 0. The three low-order octets are the vendor's structure of management information (SMI) network-management private-enterprise code in network byte order, as defined in RFC 1700, Assigned Numbers. In this case, the value 9 stands for Cisco Systems. |
| String | Field of one or more octets, such as Vendor-type = VSA number Vendor-length <= 247 bytes Vendor-string = AVP sent as an ASCII string |
Table 9-4 lists selected Cisco VSAs for accounting and performance management purposes.
| AVP | VSA Number (Decimal) | Format for Value or Text | Sample Value or Text | Description |
|---|---|---|---|---|
| Charged-units | 1 | Unsigned integer | 0 | Number of charged units for this connection. For incoming calls or if the switch doesn't supply charging information, the value of this object is 0. |
| Early-packets | 1 | Unsigned integer | 1 | Number of received voice packets that arrived too early to be stored in the jitter buffer during the call. |
| gw-final-xlated-cdn | 1 | Integer Values: ton:d npi:aa #:e where: d = 0 to 7 aa = 0 to 15 e = number in E164 format | 8539663 | Called number to be sent out the gateway. |
| gw-rxd-cdn | 1 | Integer Values: ton:d npi:aa #:e where: d = 0 to 7 aa = 0 to 15 e = number in E164 format | 4085268222 | Called number as received by the gateway in the incoming signaling message before any translation rules are applied. |
| h323-billing-model=value | 109 | 0 = credit customer (postpaid) 1 = debit card (prepaid) 2 = limited service (prepaid) | 1 | Type of billing service for a specific call. |
| h323-call-type=value | 27 | Telephony VoIP VoFR | VoIP | Protocol type or family used on this leg of the call. |
| h323-conf-id=value | 24 | 16-byte number in hexadecimal notation with a space between each 4-byte integer | 3C5AEAB9 95C80008 0 587F34 | Unique call identifier generated by the gateway. Used to identify the separate billable events (calls) within a single calling session. |
| h323-connect-time=value | 28 | Hh:mm:ss:mmm ZON DDD MMM ## YYYY | 14:27:31:098 PST Fri Nov 17 2006 | Connect time in Network Time Protocol (NTP) format. |
| h323-credit-time=value | 102 | Integer in decimal notation | 300 | Number of seconds for which the call is authorized. |
| h323-disconnect-time=value | 29 | hh:mm:ss:mmm ZON DDD MMM ## YYYY | 14:28:03:030 PST Fri Nov 17 2006 | Disconnect time in NTP format: hours, minutes, seconds, microseconds, time_zone, day, month, day_of_month, year. |
| h323-gw-id=value | 33 | Character string | test.cisco.com | Domain name server (DNS) name or local name of the voice gateway that is sending the VSA. |
| h323-incoming-conf-id=value | 1 | 16-byte number in hexadecimal notation with a space between each 4-byte integer | 33C5AEAB9 95C80008 AF27092C 587F34 and 3C5AEAB9 95C80008 0 587F34 | Unique number for identifying a calling session on a gateway, where a session is closed when the calling party hangs up. It is used to do the following: Match the outbound and inbound call legs for a session on a particular gateway. Collect and match all records for multiple calls placed (within the bounds of a session) on the gateway. |
| h323-setup-time=value | 25 | hh:mm:ss:mmm ZON DDD MMM ## YYYY | 14:27:30:007 PST Fri Nov 17 2006 | Setup time in NTP format: hours, minutes, seconds, microseconds, time_zone, day, month, day_of_month, year. |
| h323-time-and-day=value | 105 | Decimal number: hh:mm:ss | 10:36:57 | Time of day at the dialed number or at the remote gateway in the format hours, minutes, seconds. |
| h323-voice-quality=value | 31 | Decimal numbers from Impairment/ Calculated Planning Impairment Factor (ICPIF) table of G.113 | 5 | Value representing ICPIF of the voice quality on the connection provided by lower-layer drivers (such as the digital-signal-processor). Low numbers represent better quality. |
| lost-packets | 1 | Unsigned integer | 0 | Number of lost voice packets during the call. |
| round-trip-delay | 1 | <#> ms | 2 ms | Voice-packet round-trip delay, in ms, between the local and remote system on the IP backbone during the call. |
| session-protocol=value | 1 | String | SIP | Session protocol being used, such as SIP or H.323. |
| subscriber=value | 1 | String from T1/CAS (Channel Associated Signaling) or E1/R2 line/signal | Coin | T1/CAS or E1/R2 signal information about subscribers. |
| Tx-duration | 1 | <#> ms | 300 ms | Duration, in ms, of the transmit path open from this peer to the call's voice gateway. |
| voice-tx-duration | 1 | <#> ms | 100 ms | Duration, in ms, for this call. The Voice Utilization Rate can be obtained by dividing this by tx-duration. |
RADIUS Accounting with the Overloaded Acct-Session-Id
To take advantage of standard RADIUS implementations that do not support VSAs, a different method is defined. It embeds the unsupported information elements in the RADIUS Acct-Session-Id (RADIUS value 44 from RFC 2865). The Acct-Session-Id field has a maximum length of 256 characters. It is defined to contain ten discrete fields, separated by a / as the delimited ASCII string. The overloaded Acct-Session-Id also contains connect and disconnect times, remote IP address, and disconnect cause. The following is the string format for the Acct-Session-Id field:
session id/call leg setup time/gateway id/connection id/call origin/call type/connect time/disconnect time/disconnect cause/remote ip address
One of these fields is the RADIUS connection id, which is a unique identifier that links accounting records associated with the same login session for a user. The internal representation of the connection-id field is 128 bits in hex format. This string can vary in appearance. An example is 3C5AEAB9 95C80008 0 587F34—denoted as a four-octet string, a space, a four-octet string, a space, a 0, a space, and a three-octet string.
Table 9-5 describes the overloaded Acct-Session-Id fields.
| Field | Description |
|---|---|
| session id | The standard (RFC 2139) RADIUS account-session-id. |
| call leg setup time | The setup time for this connection in NTP format. |
| gateway id | The name of the underlying gateway, as a string of the form gateway.domain_name |
| connection id | A unique global identifier used to correlate call legs that belong to the same end-to-end call. The field consists of four long words (128 bits). Each long word is displayed in hexadecimal value and is separated by a space. |
| call origin | The call's origin relative to the gateway. Possible values are originate and answer. |
| call type | The call leg type. Possible values are Telephony and VoIP. |
| connect time[*] | The connect time for this call leg in NTP format (stop only). |
| disconnect time[*] | The disconnect time for this call leg in NTP format (stop only). |
| disconnect cause[*] | Documented in the Q.850 specification. The value can be in the range of 1 to 127 (stop only). |
| remote IP address[*] | The IP address of the remote gateway used in this connection (stop only). |
[*] The last four attributes (connect and disconnect times, disconnect cause, and remote IP address) in the overloaded Acct-Session-Id are available only in the stop packets. In start packets and update packets, these fields are blank.
Comparing the Vendor-Specific Attribute and the Acct-Session-Id
As a summary, consider the following rules for choosing between RADIUS attributes 26 and 44 for VoIP accounting:
The use of attribute 26 (VSA) is recommended whenever available, because it provides a superset of accounting information. After you enable VSAs, the Acct-Session-Id is no longer overloaded, because the information sent in the session ID is captured in VSAs.
Attribute 44 (overload) should be used only if VSA is not supported, because it provides a limited set of information. Furthermore, this attribute works only when the H.323 protocol is used, as opposed to SIP.
CLI Operations for VoIP Accounting with RADIUS
This section covers only the most important commands related to VoIP accounting with RADIUS. For the complete list of commands, consult the Command Reference document.
router(config)# gw-accounting aaa
enables VoIP gateway accounting. Previous IOS versions used the gw-accounting {h323 [vsa] | syslog | voip} CLI command for the same purposes.
router(config)# radius-server vsa send [accounting] [authentication]
allows the network access server to recognize and use VSAs as defined by RADIUS IETF attribute 26.
router(config-gw-accounting-aaa)# acct-template callhistory-detail
sends all voice attributes for accounting. It is valid only for RADIUS IETF attribute 26 VSA, not overloaded RADIUS IETF attribute 44, Acct-Session-Id.
router(config)# aaa session-id [common | unique]
specifies whether the same session ID is used for each AAA accounting service type within a call or whether a different session ID is assigned to each accounting service type. The default value is common.
The following configuration examples highlight the minimal configuration options that are necessary to carry out accounting in a voice environment.
Example 1: Using RADIUS Attribute 44, Acct-Session-Id
router(config)# aaa new-model router(config)# aaa accounting connection MyMethod start-stop group radius router(config)# aaa session-id common router(config)# gw-accounting aaa router(config-gw-accounting-aaa)# method MyMethod router(config-gw-accounting-aaa)# acct-template callhistory-detail router(config)# radius-server host 172.18.192.154 auth-port 1645 acct-port 1646 router(config)# radius-server retransmit 1 router(config)# radius-server key lab
A typical example of the overloaded Acct-Session-Id is
session id/call leg setup time/gateway id/connection id/call origin/call type/connect time/disconnect time/disconnect cause/remote IP address
For examp&
