Dear Lucas, Basic RADIUS accounting uses start and stop. RADIUS is not one protocol, but rather an umbrella with a collection of extensions. Many standard attributes are not used an most applications and many non-standard attributes (vendor-specific) are used in many applications... Most service providers prefer to use start and stop records and use a billing system to calculate the session time. This is because it allows pre-screening of faulty/problem sessions, standardization/consolidation of records across accounting sources and one can better calculate rates, i.e a phone conversation starting 7.35am and ending 8.10am may be rated with one rate from 7.35am to 8.00am and another the remaining time. Yes, some accounting sources send Acct-Session-Time, which for some applications is useful because you don't have to analyze and match start and stop records. However, if you don't have the attribute, it would not make sense to modify your RADIUS server (I don't know IC-Radius, but in general) because the RADIUS servers purpose is to acquire the records, while manipulating the records is a completely different problem domain that is better left to billing systems. Of course, some RADIUS servers may come with simple tools to match start and stop and produce raw CDRs (Call Data Records), but this is a tool that is/should be used batch-wise and not real-time, IMHO. When it comes to ser, here is my understanding (correct me somebody if I'm wrong): Even though the tm module implements stateful transactions, this does not mean it is keeping the states of on-going calls, but rather that each SIP message is treated statefully. A simple example is that a resend of a message can be recognized. An accepted INVITE will in accounting terms generate a start, but ser will not keep track of on-going calls in memory, so when a BYE arrives, a stop will be logged, but ser has no information about the matching start of the call. Of course, ser *could* lookup the matching start record in the database and calculate the session-time. However, this would seriously harm the scalability and is against the design of the system. I believe Asterisk keeps the call state and of course IP-PSTN gateways with open PRIs during a session will have to keep the state and will thus be able to calculate the session-time without performance penalties. I hope this helps. g-) Lucas Aimaretto wrote: