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

From: "Rick W. Porter" <[email-masked]>
Date: Wed, 13 Feb 2002 11:09:44 -0500

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

---

From: Henry Sinnreich <[email-masked]>
Date: Wed, 13 Feb 2002 12:26:46 -0600

I am not quite confortable standardizing SIP-RADIUS, given the "legacy"
nature of RADIUS. Would not a web services approach using XML be
preferable?

Thanks, 

Henry Sinnreich
WorldCom

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Rick W. Porter
> Sent: Wednesday, February 13, 2002 10:10 AM
> To: [email-masked]
> Subject: [Sip] comments on draft-schulzrinne-accounting-sip-00.txt
> 
> 
> 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).
> 
> 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?
> 
> 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.
> 
> 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?
> 
> 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.
> 
> 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?
> 
> 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.
> 
> 
> Use [email-masked] for questions on current 
> sip Use [email-masked] for new developments on the 
> application of sip
>

---

From: Juha Heinanen <[email-masked]>
Date: Wed, 13 Feb 2002 20:53:08 +0200

> nature of RADIUS. Would not a web services approach using XML be

radius accounting and authorization are very widely used by all kinds of
service providers and i would consider it a MUST that i can authenticate
my sip users and collect their accounting data via radius.  it makes no
sense for a service provider who is currently using radius for those
functions to have something else for sip.

of course, the use of radius accounting and authentication is never
mandatory if a service provider doesn't need it.

-- juha

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 13 Feb 2002 14:16:54 -0500

Yes, we can re-invent RADIUS via XML. What exactly does this buy us? No,
RADIUS isn't sexy, but it certainly is used by a lot of ISPs (and some
organizations).

---

From: Jari Arkko <[email-masked]>
Date: Wed, 13 Feb 2002 22:06:43 +0200

> RADIUS isn't sexy, but it certainly is used by a lot of ISPs (and some

I agree.

I do have a few comments on the draft though:

- Section 7 talks about the need to do Record-Route and
   keep all signaling for the call in the same proxy.
   I wonder if that's really always necessary. You seem
   take the approach that the the SIP node calculates
   session times etc. Admittedly this is quite RADIUS-like
   and traditional accounting. However, you could have left
   this also to postprocessing, or the task of the accounting
   server. That would have allowed your SIP nodes to be
   stateless and just report "what's going on". On the other
   hand that might generate quite a bit of traffic to the
   accounting server, so it might also better to just have
   a "session" i.e. INVITE and report it's start and end,
   but this is then stateful.

- I'm not sure I like very much the freedom you give to
   the policy of choosing either From or username to be
   sent in User-Name. Preferrably, both should be sent.
   Also, if you did this then it would be clearer that
   it has to be in the same manner as in the potential SIP
   RADIUS/DIAMETER authentication protocol.

- Section 6 requirements on "some form of backoff" might
   be better if described in a bit more concrete form
   as there could potentially be a lot of traffic if
   all SIP events are sent to the accounting server.
   (DIAMETER would have helped you a little here.)

- Do we really need to inform the accounting server
   of all SIP events (methods)? Why do we need to
   report on e.g. OPTIONS?

- Diameter could have been considered as a base for this protocol
   as well, since it would be easier extensible when you add
   all the necessary SIP fields, and because the accounting
   retransmission etc. rules are much clearer [imho ;-) ]
   The downside is that the RFC isn't done yet. On the other
   hand you can run Radius attributes under Diameter anyway
   so...

Jari

---

From: Henry Sinnreich <[email-masked]>
Date: Wed, 13 Feb 2002 14:59:23 -0600

> Yes, we can re-invent RADIUS via XML. What exactly does this 
> buy us?

It may buy an OSS system based on web services, where various components
can be outsourced or offered as services, such as customer service,
billing, traffic reporting, etc. Quite similar in concept to the
component services architecture in SIP. 

Henry

> Behalf Of Henning Schulzrinne
> Sent: Wednesday, February 13, 2002 1:17 PM
> To: Henry Sinnreich
> Cc: 'Rick W. Porter'; [email-masked]
> Subject: Re: [Sip] comments on draft-schulzrinne-accounting-sip-00.txt
> 
> 
> Yes, we can re-invent RADIUS via XML. What exactly does this 
> buy us? No, RADIUS isn't sexy, but it certainly is used by a 
> lot of ISPs (and some organizations).
> 
> Henry Sinnreich wrote:
> > 
> > I am not quite confortable standardizing SIP-RADIUS, given the 
> > "legacy" nature of RADIUS. Would not a web services 
> approach using XML 
> > be preferable?
> > 
> >
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 13 Feb 2002 16:00:33 -0500

> I do have a few comments on the draft though:

Thanks for the comments.

>    but this is then stateful.

I agree that this is just one model, so I'll qualify that section. It
really depends on who generates the RADIUS: a proxy or a the gateway
acting as a SIP UA. The caveats are necessary only in the former case.
We locally run a dumb gateway, so that colored my thinking.

>    RADIUS/DIAMETER authentication protocol.

Agreed, that's probably a bit too much liberty. I'm guessing both are
needed and that the username is closer in spirit to the User-Name
account name. 

>    (DIAMETER would have helped you a little here.)

As far as I know, the RADIUS spec is similarly vague (I tried to find
anything on this, without much luck), which is not much of an excuse.
Would the SIP timeout progression be an acceptable choice?

I don't think that the traffic would necessarily be more than for a
dial-up server, except that maybe the call duration for voice calls is a
bit shorter on average.

Not being part of that crowd: Is DIAMETER making headway?

>    of all SIP events (methods)? Why do we need to

Probably not if your objective is just phone billing. I agree that this
should be optional and a matter of local policy.

>    hand you can run Radius attributes under Diameter anyway

I have no particular affinity for RADIUS, just that it was very easy to
extend existing implementations to do what's described in the draft.
(We've implemented this in our server and tested it with a few standard
open-source RADIUS implementations.)

In terms of DIAMETER: See my question above. DIAMETER always seems to be
just about done...

---

From: Jari Arkko <[email-masked]>
Date: Wed, 13 Feb 2002 23:39:15 +0200

> anything on this, without much luck), which is not much of an excuse.

Yes it is vague, and as a result it's often anyone's guess exactly
what RADIUS accounting does under congestion or extended periods
of server unavailability. Good products handle things well, but
you can't necessarily tell it from the RFCs...

> Would the SIP timeout progression be an acceptable choice?

Probably as far as congestion control goes. However, you also
need to specify e.g. that implementations SHOULD have a storage
for records they could not deliver and they SHOULD have a policy
on what to do if they conclusively can't deliver or store any
additional accounting records at this time.

More background data in RFC 2975, section 2. Could also
take a look at section 9.4 in draft-ietf-aaa-diameter-08.txt.

> dial-up server, except that maybe the call duration for voice calls is a

Perhaps.

> Not being part of that crowd: Is DIAMETER making headway?

If you're asking standards process status, DIAMETER
was going fast to RFC about half a year ago, but since
then we've discovered that big specs have lots of small
things to get right, even if there's less controversial
discussions as we have in SIP. And it isn't helping that
some key people have been busy at their "day jobs"... I think
the current plan is to make one more round and go for final last call.

> In terms of DIAMETER: See my question above. DIAMETER always seems to be

Tell me about it.

Jari