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

From: Rohan Mahy <[email-masked]>
Date: Thu, 14 Feb 2002 13:37:21 -0800

Hi All,

Can we PLEASE move this discussion to SIPPING!

Henning, will you please resubmit your draft as:

   draft-schulzrinne-sipping-accounting-00.txt

So that folks (including the author ;-) don't get confused 
and use the wrong list.

thanks,
-rohan the enforcer
SIPPING co-chair

---- Original message ----
>Date: Wed, 13 Feb 2002 11:09:44 -0500
>From: "Rick W. Porter" <[email-masked]>  
>Subject: [Sip] comments on draft-schulzrinne-accounting-sip-
00.txt  
>To: <[email-masked]>
>
>Generally, I like the idea of standardizing the basic SIP-
RADIUS Accounting
>relationship, but there are a couple issues that should be 
addressed by
>something defining that relationship. I have one "major" 
concern, and a few
>smaller details.
>
>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).
>
>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?
>
>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.
>
>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?
>
>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.
>
>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, ...).
>
>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?
>
>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.
>
>
>_______________________________________________
>Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>This list is for NEW development of the core SIP Protocol
>Use [email-masked] for questions on 
current sip
>Use [email-masked] for new developments on the application 
of sip

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