Subject: RE: [SIP] Informing UA after network initated deregistration?

From: "Sean Olson (EUS)" <[email-masked]>
Date: Wed, 14 Mar 2001 08:22:36 -0600

> > Hi,
> > 
> > It is worth keeping in mind that in some environments, a very 
> > popular subscription method in some countries is "pre-paid".  
> > The subscriber will be informed when the service is to be 
> > removed to allow them to increase the avaiable credits. 
> 
> In every implementation and usage of pre-paid that I have seen, which
> includes some international ones, a voice prompt or something 
> equivalent
> (web interface) is used to inform the user that they are out 
> of money and
> must refresh the call.
> 

True, a mid-call indication is satisfactory for this purpose.

> The issue about running out of credits has nothing to do with 
> expiration of
> a registration.
> 

It is not technically an expiration of a registration that is at
issue here. It the revocation of a registration. This may or may
not be based on the lack of credits. That is, it may not occur during
the course of a session. In that case, how is the user informed?
A "service-level" notification that is not necessarily tied to an
ongoing session is being argued for here. Specifically, a NOTIFY
request indicating that the network has de-registered the subscriber.

>  It 
> > would be useful for the terminal to understand that the 
> > registration has been terminated in these circumstances.  In 
> > this environment, some operators do actually send a message 
> > (text) to indicate that service is not available due to lack 
> > of credits.
> 
> Fine:
> 
> 402 Service unavailable due to lack of credits
> is available for just this purpose.

Basically, you are arguing that the user is not informed of the
situation until that user attempts to make a call. This boils down 
to a question of timing. Are people happy with not getting an 
indication until they try to make a call?

/sean
--
Sean Olson <[email-masked]>

---

From: "Henning G. Schulzrinne" <[email-masked]>
Date: Wed, 14 Mar 2001 14:10:47 -0500

> request indicating that the network has de-registered the subscriber.

But so far, the only reason that has been identified is the "your
pre-paid calling card is depleted". However, this only happens during a
call (in which case, in-band notification is the right thing) or at
predictable intervals (e.g., cellular pre-paid cards automatically
expire 90 days after activation regardless of balance). The latter
instant is known in advance. The registrar would simply limit the
registration duration to no more than the validity period. Whether we
allow a registration response that includes a web page to extend the
calling card is a separate matter.

I've yet to see a real-life example where the registration expires at
some random, unpredictable instant (again, except fraud, but
notification in that case requires higher-layer intervention since the
device registering is likely to be compromised).

Nothing prevents a carrier from sending an IM to the subscriber telling
them "your card will expire in a week, go to http://www.ripoff.com to
renew" at any intervals they like and using whatever flashy content they
think will get the subscriber's attention. We don't need to standardize
that. 

> indication until they try to make a call?

Again, I can't see why this would be a problem in practice, for the
reasons noted above.

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementor's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to 
[email-masked] with "subscribe" in the body.

---

From: Stephen Terrill <[email-masked]>
Date: Fri, 16 Mar 2001 16:05:34 +0100

Hi All,

I feel that we are mixing up a number of issues here, and that is because this functionality has been tied to pre-paid - and being considered only in that light.  When a user has registered, the user is of the understanding that s/he is reachable.  If, for some reason, the registration has become invalid, it would be reasonable for the Ue to be informed that the registration is not longer valid, so that the user is aware that s/he is no longer reachable via that the "*insert fancy service name for SIP*" service, or can no longer iniate a session.

Have said this, we should not mix up things like "low credit warnings" with the registration becoming invalid.

Some of the reasons that the registration may become invalid include : -
- Charging related issues
This includes prepaid or removal of subscription.  Contrary to the statement below, there are scenarios when the pre-paid subscribtions will run out of credit while not in an ongoing call session.  This might be due to recieving or sending "text messages via e.g. SMS", or multiple services using the same credit.
The removal of subscription does rely on a high level of intervention - but still it can make the registration status invalid.
- Service Related
There are some service scenarios where it would be interesting to be able to make the registration invalid for that terminal.  This might be e.g. allowing only one registed terminal - and that being the last one, or maybe in a call centre scenario where we may wish to enforce breaks on certain terminals at certain times,  .... etc
- Network Managament
Could be proactive network management cases, where it would be desirable to be able to gracefully move subscribers from a poorly performing SIP registrar.

There are likely other reasons as well.  I do not necessarily view that when informing the Ue that the registration is invalid, the Ue has to understand why - it could simply try to re-register again (if approapriate) and then it will find out why - if the registration becoming invalid was for perminant reasons.

As such, I agree with Bill Marshal when he stated that it would be useful to move onto how this can be achieved - and he summarised some of the alternatives as:
---
Summary so far:

Choice #1:  don't.  UA will find out with next registration request.
Choice #2:  through a non-SIP mechanism, e.g. SMS or email notification,
                (if not real-time, then combines with #1)
Choice #3:  Subscribe/Notify (is it appropriate for this? no comments yet)
Choice #4:  anything else???
.....

Choice three could be a simple way forward???

..//Steve