|
> I preffer option 1 but not sure about how operators
will feel about
>revenue leakage of several seconds. Option 1 fixes
the problem of the
>subscriber toping off his account. Yes you have some
potential for leakage
>but you may prevent a user from calling the call
center to complain. Not
>for me to decide which is
better.
>
I think you are right on the money on Option 1 since many simple
Session-Timeout non-VSA RADIUS prepaid systems (either VoIP or dial IP) have in
the past not addressed Top-offs; simply killing the session at
Session-Timeout. If the user is going to call-in to complain, "I just
filled-up with the credit card and you still knocked me off", minor revenue
leakage of a few secs to check the status of the user's
balance at disconnect to avoid a support burden and provide continuing
& seamless prepaid sessions is not really revenue leakage at all, but
rather a desireable and valuable reauth feature!
>c) I have to check what Diameter-CC does about this. I would
very much like
>to have Diameter-CC, 3GPP2 and RADIUS converge on
prepaid.
Hallelujah! A common prepaid framework would be
lovely.
-Blair
-----Original Message-----
From: Avi Lior
[mailto:avi@bridgewatersystems.com]
Sent: Tue 5/4/2004 12:08 PM
To: 'stefaan.de_cnodder@alcatel.be'; radiusext@ops.ietf.org
Cc:
Subject: RE:
redirection+prepaid
Hi Stefaan and all,
Your question is very timely and
right on. We are currently working on this
in 3GPP2.
Putting
an attribute to indicate when something applies may not work. It
is
possible that even under normal circumstances the session may have a
filter
applied. In the case where it's a prepaid session it could be
that I have a
filter/redirect attributes to be applied when quota runs out
and a filter id
to be applied immediately. Since we cannot guarantee
the order of different
attributes this will be hard to do with an
additional attribute. If we
could however group the
redirection/filter attributes with the prepaid stuff
then this would do the
trick. That is the essence of Option 2 below.
I have identified
two options (there could be others):
Option 1:
=========
When
the quota reaches zero, in 3GPP2 the session is terminated and
an
Access-Request Authorize-Only is sent back to report that the session
has
terminated etc...
My suggestion is to not terminate the session
but rather, wait for the reply
to the Access-Request (above). That
reply would be either:
an Access-Reject (no quota drop the user)
or;
an Access-Accept with new quota (after all the user may have topped
his
account) or;
an Access-Accept with redirection
attributes.
Problem with Option 1 is that during the time when we wait
for the response
to the Access-Request there could be revenue
leakage. Any use could be
applied to the new quota. So we would
only have revenue leakage if the user
doesn't top up. Also it could
be the case that the NAS will drop the
session anyway after some (locally
configured) timeout period.
Option 2:
=========
For prepaid
put the Redirection/Filter attributes in the PPAQ. Doesn't
change the
behavior of prepaid as specified by 3GPP2.
The NAS would apply any
filter/redirection attributes it finds outside the
PPAQ immediately.
Those in the PPAQ would be acted on when the quota runs
out.
This is
what I have on the table in 3GPP2.
Note the
following:
===================
a) 3GPP2 folks have not given me a
clear indication of what is the best
option. We are addressing this
now so I will know their opinions shortly.
b) I preffer option 1 but
not sure about how operators will feel about
revenue leakage of several
seconds. Option 1 fixes the problem of the
subscriber toping off his
account. Yes you have some potential for leakage
but you may prevent a user
from calling the call center to complain. Not
for me to decide which
is better.
c) I have to check what Diameter-CC does about this. I
would very much like
to have Diameter-CC, 3GPP2 and RADIUS converge on
prepaid.
Finally, I would very much like to hear what other folks
have to say about
this.
I really appreciate your
comments.
Avi
> -----Original Message-----
> From:
stefaan.de_cnodder@alcatel.be
> [mailto:stefaan.de_cnodder@alcatel.be]
>
Sent: May 4, 2004 12:43 PM
> To: radiusext@ops.ietf.org
> Subject:
redirection+prepaid
>
>
>
> Hi,
>
> I was
wondering how the redirection in
> draft-lior-radius-redirection-00 can
be used for prepaid: the
> filters/redirect is applied by the NAS as
soon the attributes
> are received by the NAS (either in access accept
or CoA). How
> can this then be used for prepaid when the filters have
to be
> applied when there is no quota anymore? Would it not be
>
better to add something to indicate when it has to be applied
> (e.g.,
immediately, when no quota anymore, ...)?
>
>
regards,
>
> Stefaan
>
> --
> to unsubscribe
send a message to
> radiusext-request@ops.ietf.org with the word
'unsubscribe' in
> a single line as the message text body.
>
archive: <http://psg.com/lists/radiusext/>
>
--
to
unsubscribe send a message to radiusext-request@ops.ietf.org with
the word
'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>
|