[Sipping] Re: Comments on draft--calhoun-sip-aaa-reqs-03.txt

[Tony Johansson <[e-mail]>]

Hello Harri,

Thanks a lot for your comments. I found the comments very useful, so based on your
text below I have the following text proposals, which I would like to update the
draft with:

Add a new accounting section:

"2.3.3  Session accounting

   During the SIP session establishment, the SIP server MAY initiate an
   accounting session towards the Accounting server in the home or
   visited network. SIP servers MAY generate several accounting records
   during the SIP session. At the end of the SIP session, a final
   accounting record should be issued that includes a summary of the SIP
   session.

   The accounting records should include accounting information that is
   necessary for billing and inter-network settlement purpose.
   Accounting information such as user identities (called and calling
   party Ids), SIP call Id, used media types, request-URI, QoS
   parameters (requested/negotiated quality of service), accounting
   correlation Id, and SIP session duration should be recorded.

   Any change during the SIP session that MAY affect the charge of SIP
   session (e.g. change of media type, additional service requested,
   call redirection) should be reflected in an accounting record. For
   example during session forwarding, the initial calling party (A) MAY
   incur the charges from A to B while the forwarding party MAY incur
   charges due to the 'forwarded' session. Also, if the called party
   requests additional media components with regard to the initial
   request from calling party then the called party MAY be charged for
   these additional components.

   Parameters for accounting generation SHOULD be configurable in the
   SIP servers, or alternatively, the AAA server MAY indicate interim
   accounting information to the SIP server, which advises the SIP
   server when to generate the interim accounting records and if a
   cumulative or non-cumulative accounting model MUST be used.  It
   should be noted that the traditional telco world currently makes use
   of, and prefers, non-cumulative accounting information.

   If SIP extensions (e.g. instant messaging, presence service) are
   used, some of the request or response messages in these extensions
   MAY trigger generation of accounting information. For example, a SIP
   SUBSCRIBE MAY trigger generation of a one-time event accounting
   record, session based instant messaging MAY trigger generation of
   accounting session and SIP INFO methods MAY trigger generation of an
   interim accounting message.

   Accounting data related to bearer payload (e.g. number of transmitted
   packets, used bandwidth) is assumed to be handled by other mechanisms
   than SIP and is not included in these requirements. However a unique
   accounting correlation Id MAY exist, which correlates the SIP session
   with specific bearer(s)in the access network. If the unique
   correlation Id exist, it MUST be included in all accounting records
   to be able to correlate the accounting information from SIP session
   to used bearer in the access network."


Update of the requirements in section 3.0:

"3.0  Requirements

   From the previous section, we can extract the following requirements
   for SIP-AAA interworking:

       1. A basic requirement for Service Providers is to be able to
         integrate different networks for more efficient operations.
         IETF AAA efforts support this idea by striving for a single AAA
         architecture and protocol set. Whether access is supported by
         PPP, Mobile-IP, MEGACO or SIP, a common architecture and
         protocol set SHOULD be used.

       2. The AAAH MAY authenticate a user based on the corresponding
         SIP REGISTER method.

       3. The AAAH MAY authenticate a user session (the end result of a
         successful SIP INVITE method), implementing whatever policy it
         wishes, such as taking into account time of day, distance, etc.

       4. The AAA infrastructure MUST be able to distribute (push or
         pull) subscriber/service/security profiles to the relevant SIP
         servers, based on policies

       5. The AAAH MUST be able to update the entry for the assigned SIP
         server for the user performing SIP registration.

      6. The AAAH MUST be able to provide the assigned server of the
         user to the SIP entities requesting it.

       7. The AAAH MUST be able to initiate de-registration of the user.

       8. The AAA infrastructure or the Home entry SIP Proxy MUST be
         able to allocate a SIP server for a subscriber at registration
         time, based on policies, load distribution etc.

       9. The scheme supported for the authentication between the SIP
         servers and the AAA infrastructure MUST be flexible enough to
         accommodate current authentication mechanisms, e.g. using
         Subscriber Identity Module (SIM) card, and possible future
         authentication mechanisms.

       10. Ability for SIP Servers to provide the duration of a session,
         the parties involved, and other relevant information to the
         visited and home AAA servers as accounting information.

       11. The AAA protocol MUST provide support for both cumulative,
         and non-cumulative, accounting models.

       12. The AAA accounting messages MUST separate the "session
         duration time" information from those generated via additional
         services (e.g. 3-way calling, etc.)

       13. There MUST be support for accounting transfers where the
         information contained in the accounting data has a direct
         bearing on the establishment, progression and termination of a
         session.

       14. There MUST be support for accounting transfers where the
         information contained in the accounting data does NOT have a
         direct bearing on the establishment, progression and
         termination of a session.

       15. SIP servers MUST be able to provide relevant accounting
         information for billing and inter-network settlement purpose to
         home and visited AAA servers. Both one time event accounting
         records and session based (START, INTERIM, STOP records)
         accounting MUST be supported.

       16. Any change during the SIP session that affects the charge of
         SIP session MUST be reflected in accounting messages.

       17. The AAA accounting protocol MUST support accounting per media
         component (e.g. voice, video).  The AAA accounting Protocol
         MUST enable different parties to be charged per media component.

      18. Both cumulative and non-cumulative accounting model MUST be
         supported.

       19. Parameters for accounting generation must either be
         configurable in the SIP servers or communicated by the AAA
         servers.

       20. If possible the accounting for SIP session MUST be correlated
         to the bearer in the access network."


Comments are very much encouraged.


/Tony





"Harri Hakala (LMF)" wrote:

> Hi,
>
> I have a few comments on the draft-calhoun-sip-aaa-reqs-03.
> http://search.ietf.org/internet-drafts/draft-calhoun-sip-aaa-reqs-03.txt
>
> Since this draft describes the AAA requirements for IP
> telephony/Multimedia, I would like to add a few accounting requirements
> to the draft.
> I think also that it would be good state what kind of events may
> trigger generation of accounting records and what kind of information
> needs to be reported.
>
> I made a proposal for introductory text for body of the draft describing
> the accounting mechanism and listed some accounting requirements
> in the requirement section.
>
> I have not been following the Sipping list discussions so far, so please
> excuse me if some of my points have been discussed already or if
> some of my points are out of scope of this list.
>
> Section 2.3 Invitation
> ----------------------
> Sections 2.3.1 Invitation terminating in the mobile node and
>          2.3.2 Invitation originating from the mobile node
> ------------------------------------------------------------
> I would like to change the description of accounting in these
> chapters in the following way:
>
> During the SIP session establishment, the SIP serves MAY initiate
> accounting session towards Accounting server in the home or visited
> network. SIP servers MAY generate several accounting records during
> the SIP session. At the end of the SIP session, a final accounting
> record should be issued that includes a summary of the SIP session.
>
> The accounting records should include accounting information that is
> necessary for billing and inter-network settlement purpose. Accounting
> information such as user identities (called and calling party Ids),
> SIP call Id, used media types, request-URI, QoS parameters (requested/
> negotiated quality of service), accounting correlation Id, SIP session
> duration should be recorded.
>
> Any change during the SIP session that MAY affect the charge of SIP
> session (e.g. change of media type, additional service requested,
> call redirection) should be recorded as an accounting
> record. For example during session forwarding, the initial calling party
> (A) MAY incur the charges from A to B while the forwarding party MAY incur
> charges due to the 'forwarded' session. Also, if the called party requests
> additional media components with regard to the initial request from calling
> party then called party MAY be charged for these additional components.
>
> AAA server MAY also return at the SIP session establishment the
> accounting-interim-information to the SIP server, which advices the SIP
> server when to generate the interim accounting records and if cumulative or
> non-cumulative accounting model MUST be used. The traditional telco world
> currently makes use of, and prefers, non-cumulative accounting information,
> therefore any interim accounting information MAY be non-cumulative.
>
> If the SIP extensions (for example Instant messaging, presence service) are
> used some of the request or response messages in these extension MAY trigger
> generation of accounting information. For example SUBSCRIBE MAY trigger
> generation of one time event accounting record, session based instant messaging
> MAY trigger generation of accounting session and INFO message MAY trigger
> generation of interim message. It MUST be configurable in the SIP servers or
> AAA server MAY inform the SIP servers when to generate accounting records or
> which SIP messages triggers generation of accounting information.
>
> Accounting data related to bearer payload (e.g. number of transmitted
> packets, used bandwidth) is assumed to be handled by other mechanisms
> than SIP and is not included in these requirements. However a unique
> accounting correlation Id MAY exist, which correlates the SIP session with
> specific bearer(s)in the access network. If the unique correlation Id exist,
> it MUST be included in all accounting records to be able to correlate the
> accounting information from SIP session to used bearer in the access network.
>
> 3.0 Requirements
> ----------------
> Here is my proposal for requirements.
>
> XX. SIP servers MUST be able to provide relevant accounting information
>     for billing and inter-network settlement purpose to home and visited
>     AAA servers. Both one time event accounting records and session base
>     (START, INTERIM, STOP records) accounting MUST be supported.
>
> XX. Any change during the SIP session that affects the charge of SIP session
>     MUST be recorded over AAA accounting protocol.
>
> XX. It MUST be possible to divide the accounting of the SIP session into
>     different parts, so that different parties can incur charges for different
>     parts of the SIP session.
>
> XX. The AAA accounting protocol MUST support accounting per media component
>     (e.g. voice, video). AAA accounting Protocol MUST enable different parties
>     to be charged per media component.
>
> XX. Both cumulative and non-cumulative accounting model MUST be supported.
>
> XX. It MUST be option to configure the SIP servers when to generate accounting
>     records. Alternatively the AAA server MAY inform SIP servers when to
>     generate accounting records.
>
> XX. If possible the accounting for SIP session MUST be correlated to the
>     bearer in the access network.
>
> XX. There MUST be support for real-time and non-real time accounting.
>
> Regards............Harri