[edit]
Vendor Accounting Practices
| Vendor | Perspective | Notes |
| Bluesocket | Client | |
| ChilliSpot | AC | |
| Cisco | AC | |
| Colubris | Client | |
| CoovaChilli | Client | Reversible with option swapoctets |
| Gemtek | Client | Reversible with option Reverse Accounting set to enabled |
| Hostapd | AC ? | |
| HP ProCurve | Client ? | |
| LANCOM | Client ? | |
| Nomadix | Client |
Notes:
- RFC 2866
- The RADIUS Accounting RFC states that Acct-Input-Octets indicates how many octets have been received from the port over the course of this service being provided - Although not very clearly stated, port should be seen from the point of view of the AC/NAS, not the Client (* those with the Client perspective are not RFC compliant).
- RFC 4005
- The Diameter NAS Application RFC states that Accounting-Input-Octets contains the number of octets received from the user which also (and perhaps more clearly) takes the point of view of the AC/NAS. In some early drafts, there was a mistake where it said this attribute contains the number of octets in IP packets received by the user.
- GSM WLAN Roaming Guidelines
- This document defines Acct-Input-Octets as the volume of the downstream traffic of the user - not very clear in the meaning, but seems to suggest the Client point of view.
- 3GPP TS 29.234
- This document defines Acct-Input-Octets as "the number of octets sent by the WLAN UE over the course of the session. According to IETF RFC 2866"
- IETF Opinions
- In the RFC 2866 clarifications thread
![[Main Page]](/wiki/skins/common/images/coova.gif)