Subject: [Sipping] Re: [Sip] comments on draft-schulzrinne-accounting-sip-00.txt

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 17 Feb 2002 15:16:49 -0500

[Discussion moved to SIPPING.]

Thanks for your comments.

A new draft will appear shortly, renamed as
draft-schulzrinne-sipping-radius-accounting-00, that tries to address
these and other comments.

The draft is at
http://www.cs.columbia.edu/~hgs/sip/drafts/draft-schulzrinne-sipping-radius-accounting-00.txt
until it appears in the I-D archives.

"Rick W. Porter" wrote:
> 
> My major concern is the draft does not address branching scenarios. The SIP
> Call-Id will be the same for all branches, and there is nothing in the
> RADIUS message to distinguish each branch. The back-end RADIUS processing
> may break down if the fundamental assumption of one Start and one Stop per
> session is violated. I see two possible solutions: include the Branch-ID for
> all RADIUS messages, or make the SIP proxy stateful enough to generate
> RADIUS messages for only chosen branch (or the whole session if all branches
> fail).

I've added a branch identifier, and noted that logging can be done
either for one request/response or for each branch.

> 
> My detailed concerns are listed by section comments below:
> 
> Section 5.1 (User-name, p4) -
> If the intent of this attribute is to establish responsibility for the
> session, it does not work unless the SIP proxy is session stateful! The only
> way to record responsibility is when the SIP proxy receives the initial
> INVITE (or the first one that is Authenticated), because the SIP message
> From, To, and Authentication username, will change based on who initiates
> each SIP message, not who initiated the session. Therefore, I think the
> attribute fails to meet the its intent. Furthermore, without Authentication
> this attribute will be redundant--why include the information twice? Maybe
> make this should be an optional RADIUS attribute that is include if
> authentication is done?
> 

Modified to reflect authentication user. This is not necessarily the
party responsible for paying, say. It would be up to the consumer of the
accounting data to determine, e.g., whether the one to send the first
INVITE is responsible for the call. I don't see how we can say much more
in SIP. Maybe in the future there will be explicit indications of this,
but presumably outside core SIP.

> Section 5.5 (Acct-Status-Type, p6) -
> It appears that the draft suggests generating an Interim-Update to report
> receiving all SIP messages other than initial INVITEs, BYEs, and failures
> for initial INVITEs.  This creates potential problems for branching
> scenarios as discussed above.

Clarified how this should work with call stateful, transaction stateful
and stateless logging.

> 
> Section 5.6 (Acct-Delay-Time, p7) -
> By including this attribute, the RADUIS message must get a new ID and the
> authenticator must be recalculated each time the message is retransmitted.
> It would seem to me that it is more efficient to let messages age with the
> "time sensitive" information included as part of the original message (i.e.
> Event-timestamp). Or, do RADIUS servers do something useful with the
> Acct-Delay-Time attribute?

Agreed that this isn't all that helpful; dropped.

> 
> Section 5.9 (Acct-Session-Time, p8) -
> First, unless your SIP proxy is session stateful, where do you get the
> information to calculate this?  Second, since the amount of time from
> receiving the INVITE to receiving the 200-OK is not deterministic, it seems
> to me that this time should be 0 for all sessions that never received the
> 200-OK; again, the SIP proxy needs to be session stateful to get this
> information. You wouldn't want to get a phone bill for attempted calls where
> the line was busy, so the reported time should be the time from the 200-OK
> to the BYE.

Noted that this is for call stateful only. Clarified 200 (OK)
relationship.

> 
> Section 5.10 (Acct-Terminate-Cause, p9) -
> How do SIP events map to the RADIUS values? Some are intuitive (i.e. BYE =
> User Request), but others are not (404, 482, 500, ...).

This should only occur for call stateful logging. I've added some
explanation.

> 
> Section 5.14 (Sip-From, p12) and Section 5.15 (Sip-From, p12) -
> Why not use the Calling-Station-Id and Called-Station-Id instead of defining
> new attributes?

Interesting idea. I was a little leery of this given the restrictive
description of the field in RFC 2865, but this is probably close enough
to be useable.

> 
> Section 5.17 (Sip-Remote-IP-Address, p14) and Section 5.18 (Sip-Remote-Port,
> p14) -
> First, I would suggest a name change to Sip-Previous-IP-Address and
> Sip-Previous-Port, since there may be a inbound and outbound Remote IP
> Address/Port. Second, where does this info come from (Rec-Route header? Via
> header? or socket?)  There may be minor NAT issues that may be intertwined
> with your choice.
> 

I've changed this to Sip-Source*, reflecting the origin of the request.
That seems to be the most interesting piece of information. Should the
destination IP addresses also be logged?

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP