Internet Engineering Task Force
Internet Draft                                       Schulzrinne/Kundaje/Narayanan
                                                               Columbia University
draft-schulzrinne-sipping-radius-accounting-00.txt
February 17, 2002
Expires: July 2002


                   RADIUS accounting for SIP servers

STATUS OF THIS MEMO

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress".

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   To view the list Internet-Draft Shadow Directories, see
   http://www.ietf.org/shadow.html.


Abstract

   This memo defines mappings of RADIUS accounting attributes for use
   with SIP servers. It also defines several new attributes to support
   the provision of RADIUS accounting for SIP servers.


1 Introduction

   The Session Initiation Protocol (SIP) [1] is an application-layer
   control protocol that can establish, modify and terminate multimedia
   sessions or calls. A SIP system is composed of a number of logical
   components such as user agents, proxy servers, redirect servers and
   registrars.

   RADIUS (Remote Authentication in Dial-In User Service) [2] can be



Schulzrinne/Kundaje/Narayanan                                 [Page 1]


Internet Draft             SIPPING-Accounting          February 17, 2002


   used for carrying accounting information between a SIP server and a
   RADIUS server. In this architecture, the SIP server operates as a
   client of the RADIUS server. The client passes user accounting
   information derived from specific events in a SIP session to a
   designated RADIUS server in an accounting request packet. The RADIUS
   server sends back an accounting response to the client indicating
   that it has successfully received and processed the request. RADIUS
   servers discard the request packet if it had an error.

   SIP servers can log calls, transactions or requests and responses. If
   it logs calls, it marks the beginning and end of calls with Acct-
   Status-Type start and stop, respectively. If it logs transactions, it
   includes both the request method and the final response for the
   transaction and logs them with Acct-Status-Type Interim-Update. If
   the server logs requests or responses, it generates two or more
   accounting requests, one for the request and one or more final
   responses. (TBD: Is there a point of logging all final responses in a
   forking proxy?)

   For forking proxies, the server can log either only the single
   successful branch or log responses from all branches.

   Some of the parameters to be logged can be mapped into the attributes
   defined in RFC 2865[2] and RFC 2866[3]. However, some new SIP
   specific attributes need to be defined for some SIP-specific
   accounting and logging information. This document defines a set of
   attributes and also provides a mapping for several existing RADIUS
   attributes.

2 Conventions of This Document

   In this document, the key words "MUST", "MUST NOT", "REQUIRED",
   "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
   and "OPTIONAL" are to be interpreted as described in RFC 2119 [4] and
   indicate requirement levels for compliant implementations.

3 Terminology

        RADIUS server: Defined in RFC 2865 [2]. In the context of this
             document, the term RADIUS server refers to a server that
             accepts RADIUS accounting packets, and responds to them.

        Accounting Request: Defined in RFC 2865 [2]; an accounting
             request is a specific RADIUS attribute, denoted
             Accounting-Request, used in a packet sent from a client to
             the RADIUS server. It requests the server to log the
             contents of the packet. The contents will be interpreted
             according to the definitions of attributes and types



Schulzrinne/Kundaje/Narayanan                                 [Page 2]


Internet Draft             SIPPING-Accounting          February 17, 2002


             provided in RFC 2866 [3].

        Accounting Response: Defined in RFC 2865 [2], an accounting
             response is a specific RADIUS attribute, denoted
             Accounting-Response, used in responses for accounting
             requests.

4 Table of Attributes

   The following table provides a guide to which attributes may be found
   in Accounting-Request packets for SIP. The first part namely,
   Standard RADIUS attributes, specifies the RADIUS attributes that can
   be used in SIP servers. The SIP specific attribute section defines
   new attributes that are specific to SIP. No SIP specific attributes
   should be found in Accounting-Response packets. A value of 1 in the
   first column indicates that exactly one instance of the corresponding
   attribute MUST be present in a Accounting-Request packet; a value of
   0-1 indicates that zero or one instance of the attribute MAY be
   present.

   Standard RADIUS attributes:


   Request  #   Attribute
   _________________________________
   1        1   User-Name
   1        4   NAS-IP-Address
   1        5   NAS-Port
   1        6   Service-Type
   1        30  Called-Station-ID
   1        31  Calling-Station-ID
   1        40  Acct-Status-Type
   1        44  Acct-Session-Id
   0-1      45  Acct-Authentic
   0-1      46  Acct-Session-Time
   0-1      49  Acct-Terminate-Cause
   1        55  Event-Timestamp


   SIP-specific attributes:


   Request  #    Attribute

_______________________________________
   0-1      101  Sip-Method [*]
   0-1      102  Sip-Response-Code [*]
   1        103  Sip-Cseq
   0-1      104  Sip-To-Tag
   0-1      105  Sip-From-Tag



Schulzrinne/Kundaje/Narayanan                                 [Page 3]


Internet Draft             SIPPING-Accounting          February 17, 2002


   0-1      106  Sip-Branch-ID
   0-1      107  Sip-Translated-Request-ID
   0-1      108  Sip-Source-IP-Address
   0-1      109  Sip-Source-Port


   *: Either the Sip-Method Attribute or the Sip-Response-Code attribute
   must be present in all Accounting-Request packets.

5 Description of Attributes

   Below, we describe the semantics of each RADIUS attribute when used
   for SIP servers. If no format is shown, it is the same as defined in
   RFC 2865 [2] or RFC 2866 [3].

5.1 User-Name

   The User-Name attribute refers to the SIP address of the user
   responsible for the session. If the request used Digest
   authentication, this is the "user" parameter in the Authorization
   header field. Other authentication schemes provide similar mappings.
   If there was no authentication, the From header field is used
   insteda.  This attribute MUST be present in all Accounting-Request
   packets.

5.2 NAS-IP-Address

   The NAS-IP-Address attribute indicates the IP Address of the SIP
   server which is requesting the accounting service provided by the
   RADIUS server. This attribute MUST be present in Accounting-Request
   packets.

5.3 NAS-Port

   The NAS-Port attribute indicates the port number of the SIP Server
   that provides service to the user. This is usually 5060. This
   attribute MUST be present in Accounting-Request packets.

5.4 Service-Type

   The Service-Type attribute indicates the type of service the user has
   requested, or the type of service to be provided. For SIP accounting
   the value MUST be 15 indicating Sip-Session.  It MUST be present in
   Accounting-Request packets.

5.5 Calling-Station-Id

   When used for SIP accounting, the RADIUS Calling-Station-Id attribute



Schulzrinne/Kundaje/Narayanan                                 [Page 4]


Internet Draft             SIPPING-Accounting          February 17, 2002


   is the URL in the SIP From header field and identifies a SIP caller
   of any request or response through a SIP server.  It MUST be present
   in Accounting-Request packets.

5.6 Called-Station-Id

   When used for SIP accounting, the RADIUS Called-Station-Id attribute
   is the URL from the SIP To header field and identifies a SIP callee
   of any request or response through a SIP server.  It MUST be present
   in Accounting-Request packets.

5.7 Acct-Status-Type

   The Acct-Status-Type attribute indicates whether this Accounting-
   Request marks the beginning of the user service (Start) or the end
   (Stop). This attribute is also used by the SIP server to mark the
   start of accounting (for example, upon booting) by specifying
   Accounting-On and to mark the end of accounting (for example, just
   before a scheduled reboot) by specifying Accounting-Off.

   For SIP accounting, the value field can contain one of the following
   RADIUS codes:

   1   Start
   2   Stop
   3   Interim-Update
   7   Accounting-On
   8   Accounting-Off
   15  Reserved for failures


5.8 Acct-Session-Id

   The Acct-Session-Id attribute is derived from the Call-ID of the SIP
   session. The Call-ID is a SIP header field uniquely identifies a
   particular invitation or all registrations of a particular client.
   This attribute also makes it easy to correlate start and stop records
   in the RADIUS server log. The start and stop records for a given
   accounting session MUST have the same Acct-Session-Id. This attribute
   MUST be present in Accounting-Request packets.

5.9 Acct-Authentic

   The Acct-Authentic attribute MAY be included in an Accounting-Request
   and indicates how the user was authenticated, whether by RADIUS, the
   SIP server itself (Local), or another remote authentication protocol
   (Remote). (TBD




Schulzrinne/Kundaje/Narayanan                                 [Page 5]


Internet Draft             SIPPING-Accounting          February 17, 2002


   1  RADIUS
   2  Local
   3  Remote


5.10 Acct-Session-Time

   The Acct-Session-Time attribute indicates how many seconds the user
   has received service for, and can only be present in Accounting-
   Request records where the Acct-Status-Type is set to Stop. It is used
   to represent the time between the arrival of the 200 (OK) response to
   an INVITE request from the caller and the arrival of the
   corresponding BYE request by either party.  This attribute can only
   be generated by call-stateful SIP entities.  These entities must
   receive both INVITE and BYE requests for each dialog, for example,
   proxies using record-routing or user agent servers.

   A summary of the Acct-Session-Time attribute format is shown below.
   The fields are transmitted from left to right.


        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |     Type (=46)|    Length (=6)|             Value
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                  Value (cont)         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



        Value: The Value field is four octets.

5.11 Acct-Terminate-Cause

   The Acct-Terminate-Cause attribute indicates how the session was
   terminated, and can only be present in Accounting-Request records
   where the Acct-Status-Type is set to Stop.  This attribute can only
   be generated by call-stateful SIP entities.

   A summary of the Acct-Terminate-Cause attribute format is shown
   below. The fields are transmitted from left to right.


        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |     Type (=49)|    Length (=6)|             Value



Schulzrinne/Kundaje/Narayanan                                 [Page 6]


Internet Draft             SIPPING-Accounting          February 17, 2002


       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                  Value (cont)         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



        Value: The Value field is four octets, containing an integer
             specifying the cause of session termination, as follows:


             1   User Request (BYE)
             3   Lost Service
             4   Idle Timeout (e.g., loss of RTP or RTCP)
             5   Session Timeout (e.g., SIP session timer)
             6   Admin Reset
             7   Admin Reboot
             8   Port Error
             9   NAS Error
             10  NAS Request
             11  NAS Reboot
             15  Service Unavailable


             RFC 2866 [3] provides further explanation.

5.12 Event-Timestamp

   The Event-Timestamp attribute is included in an Accounting-Request
   packet to record the time that this event occurred on the SIP server,
   in seconds since January 1, 1970 00:00 UTC.  This attribute MAY be
   present. It is useful for profiling and traffic measurement purposes.

   A summary of the Event-Timestamp attribute format is shown below. The
   fields are transmitted from left to right.


        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |     Type (=55)|    Length (=6)|             Value
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                  Value (cont)         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



        Value: The Value field is four octets encoding an unsigned
             integer with the number of seconds since January 1, 1970



Schulzrinne/Kundaje/Narayanan                                 [Page 7]


Internet Draft             SIPPING-Accounting          February 17, 2002


             00:00 UTC.

5.13 Sip-Method

   The Sip-Method attribute indicates the SIP method. It can take values
   corresponding to INVITE, ACK, OPTIONS, CANCEL, BYE, REGISTER,
   SUBSCRIBE and NOTIFY. Other methods will be added in the future by
   IANA registration. A SIP entity MAY log any subset of these requests.

   This attribute MUST be present in Accounting-Request packets if there
   is no SIP-Response-Code attribute in the packet. Both SIP-Reponse-
   Code and SIP-Method can appear in the same RADIUS packet.

   A summary of the Sip-Method attribute format is shown below.  The
   fields are transmitted from left to right.


        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |    Type (=101)|    Length (=6)|             Value
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                  Value (cont)         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



        Value: The Value field is four octets, containing an integer
             specifying the Method, as follows:


             0  INVITE
             1  BYE
             2  REGISTER
             3  CANCEL
             4  OPTIONS
             5  ACK
             6  SUBSCRIBE
             7  NOTIFY


5.14 Sip-Response-Code

   The Sip-Response-Code attribute indicates the SIP status code present
   in the SIP response to the SIP server. For example, a successful call
   setup may result in 200.

   This attribute MUST be present in Accounting-request packets if there



Schulzrinne/Kundaje/Narayanan                                 [Page 8]


Internet Draft             SIPPING-Accounting          February 17, 2002


   is no Sip-Method attribute in the packet. A packet MAY contain both
   headerSip-Method and Sip-Response-Code.

   A summary of the Sip-Response-Code attribute format is shown below.
   The fields are transmitted from left to right.


        0                   1                   2
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |     Type(=102)|   Length (6)|  value ...
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



        Value: The value field is 4 octets and contains the SIP response
             code.

5.15 Sip-CSeq

   The Sip-CSeq attribute is the numeric part of CSeq header field
   value. It MUST be present in Accounting-Request packets.

   A summary of the Sip-CSeq attribute format is shown below. The fields
   are transmitted from left to right.


        0                   1                   2
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Type(=103)  |  Length (>=3) |  Text ...
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



        Text: The text field is the numeric part of the CSeq header
             field. (TBD: should this be an integer?)

5.16 Sip-To-Tag

   The Sip-To-Tag attribute is the tag value from the SIP To header
   field and identifies a SIP callee of any request or response through
   a SIP server. It MUST be present in Accounting-Request packets if the
   request contained a tag.

   A summary of the Sip-To-Tag attribute format is shown below.  The
   fields are transmitted from left to right.




Schulzrinne/Kundaje/Narayanan                                 [Page 9]


Internet Draft             SIPPING-Accounting          February 17, 2002


        0                   1                   2
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |    Type (=104)|  Length (>=3) |  Text ...
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



        Text: The tag field.

5.17 Sip-From-Tag

   The Sip-From attribute is the tag value from the SIP From header
   field and identifies a SIP caller of any request or response through
   a SIP server. It MUST be present in Accounting-Request packets if the
   request contained such a tag.

   A summary of the Sip-From-Tag attribute format is shown below.  The
   fields are transmitted from left to right.


        0                   1                   2
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Type(=105)  |  Length (>=3) |  Text ...
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



        Text: The text field is a SIP URI.

5.18 Sip-Branch-ID

   The Sip-Branch-ID attribute indicates the branch ID for a particular
   request or response.


        0                   1                   2
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Type (=106) |   Length(>=3) |  Text ...
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



        Text: The value of the branch ID.

5.19 Sip-Translated-Request-URI



Schulzrinne/Kundaje/Narayanan                                [Page 10]


Internet Draft             SIPPING-Accounting          February 17, 2002


   The Sip-Translated-Request-URI attribute indicates the Request-URI of
   the SIP request, translated as per the SIP server's processing rules
   into a "canonical" URI. For an INVITE request, the "canonical" URI is
   the URI that the SIP server uses for proxying.  For example, if the
   Request-URI is "sip:alice@wonderland.com", a SIP server might
   translate this to "sip:alice@p42.wonderland.com". The latter is then
   recorded as the translated request URI.

   In other cases, such as a REGISTER request, the Sip-Translated-
   Request-URI MAY be same as the Request-URI. For example, if the
   Request-URI for the registrar serving wonderland.com is
   "sip:wonderland.com", the Sip-Translated-Request-URI will be just
   "sip:wonderland.com".  However, other Request-URIs such as
   "sip:registrar.wonderland.com" may be translated to
   "sip:wonderland.com".

   This attribute MUST be present in all Accounting-Request packets.

   A summary of the Sip-Translated-Request-URI attribute format is shown
   below. The fields are transmitted from left to right.


        0                   1                   2
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Type (=107) |   Length(>=3) |  Text ...
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



        String: The string is a URI.

5.20 Sip-Source-IP-Address

   The Sip-Source-IP-Address attribute indicates the IP source address
   of the request that triggered the accounting request. (TBD: do we
   need to log the source IP address of responses, too?)

   A summary of the Sip-Remote-IP-Address attribute format is shown
   below. The fields are transmitted from left to right.


        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |    Type (=108)|    Length (=6)|            Address
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                Address (cont)         |



Schulzrinne/Kundaje/Narayanan                                [Page 11]


Internet Draft             SIPPING-Accounting          February 17, 2002


       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



        Address:  The address field is four octets and contains an IPv4
             address.

5.21 Sip-Source-Port

   The Sip-Source-Port attribute indicates the port number of the
   request that triggered the accounting request.

   A summary of the Sip-Source-Port attribute format is shown below. The
   fields are transmitted from left to right.


        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |    Type (=109)|    Length (=6)|             Value
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                  Value (cont)         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



        Value: The Value field is four octets and represents a TCP or
             UDP port.

6 Reliability of Accounting Messages

   Radius servers discard packets in case of an error, such as malformed
   or tampered packets. If the packet is accepted as valid, they send
   back an accounting response. As noted in Section 3.1 of RFC 2975 [5],
   "RADIUS accounting implementations are vulnerable to packet loss as
   well as application layer failures, network failures and device
   reboots."

        o It is RECOMMENDED that the client continue attempting to send
          the Accounting-Request packet until it receives an
          acknowledgement, using the SIP backoff timers for congestion
          control.

        o The client MAY forward requests to an alternate server in the
          event that the primary server unreachable.

        o The client SHOULD store records that cannot be delivered after
          the backoff timer has run its course, so that they can be



Schulzrinne/Kundaje/Narayanan                                [Page 12]


Internet Draft             SIPPING-Accounting          February 17, 2002


          delivered when the network is available again.

        o It is a matter of client policy how to process requests where
          storage for undelivered accounting records has been exhausted.

   RFC 2975 [5] contains additional advice.

7 Security Considerations

   If a SIP proxy server is used for call accounting, the proxy uses the
   SIP Record-Route option during call setup to ensure that all
   subsequent signaling messages traverse through it. This is needed,
   for example, to know when the call ends. Security policies should
   make sure that the proxy server is not bypassed. For example, a
   gateway should be configured to reject all BYE requests that do not
   originate from the proxy server. Additional security issues
   considered in RFC 2865 [2] and RFC 2543 [1] are also applicable.

8 IANA Considerations

   The packet type codes, attribute types, and attribute values defined
   in this document are registered by the Internet Assigned Numbers
   Authority (IANA) from the RADIUS name spaces.

9 Acknowledgments

   Rick W. Porter provided useful input.

10 Authors' Addresses

   Henning Schulzrinne
   Dept. of Computer Science
   Columbia University
   1214 Amsterdam Avenue, MC 0401
   New York, NY 10027
   USA
   electronic mail: schulzrinne@cs.columbia.edu

   Anshul Kundaje
   Dept. of Electrical Engineering
   Columbia University
   1214 Amsterdam Avenue, MC 0401
   New York, NY 10027
   USA
   electronic mail: abk2001@cs.columbia.edu

   Sankaran Narayanan
   Dept. of Computer Science



Schulzrinne/Kundaje/Narayanan                                [Page 13]


Internet Draft             SIPPING-Accounting          February 17, 2002


   Columbia University
   1214 Amsterdam Avenue, MC 0401
   New York, NY 10027
   USA
   electronic mail: sankaran@cs.columbia.edu

11 Bibliography

   [1] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP:
   session initiation protocol," Request for Comments 2543, Internet
   Engineering Task Force, Mar. 1999.

   [2] C. Rigney, S. Willens, A. Rubens, and W. Simpson, "Remote
   authentication dial in user service (RADIUS)," Request for Comments
   2865, Internet Engineering Task Force, June 2000.

   [3] C. Rigney, "RADIUS accounting," Request for Comments 2866,
   Internet Engineering Task Force, June 2000.

   [4] S. Bradner, "Key words for use in RFCs to indicate requirement
   levels," Request for Comments 2119, Internet Engineering Task Force,
   Mar. 1997.

   [5] B. Aboba, J. Arkko, and D. Harrington, "Introduction to
   accounting management," Request for Comments 2975, Internet
   Engineering Task Force, Oct. 2000.


   Full Copyright Statement

   Copyright (c) The Internet Society (2002). All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works. However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.



Schulzrinne/Kundaje/Narayanan                                [Page 14]


Internet Draft             SIPPING-Accounting          February 17, 2002


   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.




                           Table of Contents



   1          Introduction ........................................    1
   2          Conventions of This Document ........................    2
   3          Terminology .........................................    2
   4          Table of Attributes .................................    3
   5          Description of Attributes ...........................    4
   5.1        User-Name ...........................................    4
   5.2        NAS-IP-Address ......................................    4
   5.3        NAS-Port ............................................    4
   5.4        Service-Type ........................................    4
   5.5        Calling-Station-Id ..................................    4
   5.6        Called-Station-Id ...................................    5
   5.7        Acct-Status-Type ....................................    5
   5.8        Acct-Session-Id .....................................    5
   5.9        Acct-Authentic ......................................    5
   5.10       Acct-Session-Time ...................................    6
   5.11       Acct-Terminate-Cause ................................    6
   5.12       Event-Timestamp .....................................    7
   5.13       Sip-Method ..........................................    8
   5.14       Sip-Response-Code ...................................    8
   5.15       Sip-CSeq ............................................    9
   5.16       Sip-To-Tag ..........................................    9
   5.17       Sip-From-Tag ........................................   10
   5.18       Sip-Branch-ID .......................................   10
   5.19       Sip-Translated-Request-URI ..........................   10
   5.20       Sip-Source-IP-Address ...............................   11
   5.21       Sip-Source-Port .....................................   12
   6          Reliability of Accounting Messages ..................   12
   7          Security Considerations .............................   13
   8          IANA Considerations .................................   13
   9          Acknowledgments .....................................   13
   10         Authors' Addresses ..................................   13
   11         Bibliography ........................................   14





Schulzrinne/Kundaje/Narayanan                                [Page 15]