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

From: Baniel Uri-CUB001 <[email-masked]>
Date: Fri, 9 Mar 2001 14:09:07 -0600

Folks, just to step back/up one abstraction layer for a sec. I like to refer to the suggestions list you brought up, William.
The common denominator of choices 2-4 is that they make sure the user is notified of his/her new state before next redundant registration...
Choice #1 keeps the surprise for next reg.

So I just like to show why choices 2-4 are superior to choice #1, at least in my mind.

1. It is a much better behavior of the network/system to let the user know that he/she can no longer orig/term. SIP calls, whether temporarily or until he/she takes some payment action or whatever. (Just like cell phone/pagers are being notified of not having 1 or 2 way communication, so they can indicate it to the user right away)

2. We save some bandwidth, by avoiding redundant reg. requests and responses.

===========================================
[email-masked], 
Tel: (847) 632 4616; Fax: (847) 632 3963; 
===========================================

> -----Original Message-----
> From: Michael Thomas [mailto:[email-masked]]
> Sent: Friday, March 09, 2001 1:55 PM
> To: William Marshall
> Cc: [email-masked]
> Subject: RE: [SIP] Informing UA after network initated deregistration?
> 
> 
> 
> 
> If what you're after is essentially the equivalent
> of message waiting indicator, SUBSCRIBE/NOTIFY at
> a _service level_ seems like the right thing. That
> completely divorces this from the registrar,
> though if the service wanted to coordinate with
> the registrar to clear any registrations, that
> would be their own business.
> 
> 	       Mike
> 
> William Marshall writes:
>  > Henning, Mike, Bob, all,
>  > 
>  > I think rather than debating the various situations in which
>  > a network operator may delete a registration (and prevent further
>  > service to that subscriber), the more appropriate question for
>  > this group is how to inform the UA that it has happened.
>  > 
>  > The main issue is still:  If the UA is displaying some 
> status indication 
>  > that the registration/service is active, how to keep the 
> display correct?
>  > 
>  > 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???
>  > 
>  > Bill Marshall
>  > [email-masked]
>  > 
>  > _______________________________________________
>  > 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.
> 
> _______________________________________________
> 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.
> 

_______________________________________________
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: "Iliff, Tina" <[email-masked]>
Date: Fri, 09 Mar 2001 20:18:18 +0000

Exactly!  I agree.  This also relates to the Registration Time Interval
thread.

Tina Iliff

-----Original Message-----
From: Baniel Uri-CUB001 [mailto:[email-masked]]
Sent: Friday, March 09, 2001 2:09 PM
To: 'Michael Thomas'; William Marshall
Cc: [email-masked]
Subject: RE: [SIP] Informing UA after network initated deregistration?

Folks, just to step back/up one abstraction layer for a sec. I like to refer
to the suggestions list you brought up, William.
The common denominator of choices 2-4 is that they make sure the user is
notified of his/her new state before next redundant registration...
Choice #1 keeps the surprise for next reg.

So I just like to show why choices 2-4 are superior to choice #1, at least
in my mind.

1. It is a much better behavior of the network/system to let the user know
that he/she can no longer orig/term. SIP calls, whether temporarily or until
he/she takes some payment action or whatever. (Just like cell phone/pagers
are being notified of not having 1 or 2 way communication, so they can
indicate it to the user right away)

2. We save some bandwidth, by avoiding redundant reg. requests and
responses.

---

From: Igor Slepchin <[email-masked]>
Date: Fri, 9 Mar 2001 18:15:20 -0500

> From: William Marshall [mailto:[email-masked]]
>

I haven't yet seen a good argument about why it's necessary. If the problem
is taking the registrar down for maintenance, it's well beyond SIP realm -
there are lots of highly available database solution on the market that
allow this.

The example with GUI notification is rather far-fetched in my opinion. The
reachability of a SIP phone is by no means limited by its registrar. What
happens if the access proxy dies? or the router, the ether switch, Internet
backbone goes down etc?

Thank you,
Igor Slepchin

---

From: Baniel Uri-CUB001 <[email-masked]>
Date: Sat, 10 Mar 2001 07:42:12 -0600

Igor

Network initiated deregistration may happen for various reasons. Ironically I do not see 'registrar crashing' as one of them... (Hot backup etc is just as you say far beyond SIP and shall not concern us in this regard). It could be for instance: temporarily suspension of services for a specific subscriber, because his/her pre paid billing ticket is empty...

I think it is expected by a subscriber to be notified when the system can not serve him/her. 
He/she may be a bit cranky if he/she was expecting a very important call, and only after 20 minutes has realized the phone was out of service.. (These are exactly the things that distinguish between real systems and kids/hackers toys)
(again just like the cellular analogy). If your system crashed in such a way that your hot backup did not work, of course you can not do anything about it.
If I sink in the see, I would probably not have enough time to instruct my secretary how to pay my last phone bill..

It is true though, that we may want to leave it as an implementation offer to a SIP operator. Still we need to offer him the way to do it, so as to keep it standardized.

Uri

-----Original Message-----
From: Igor Slepchin [mailto:[email-masked]]
Sent: Friday, March 09, 2001 5:15 PM
To: 'William Marshall'; [email-masked]
Subject: RE: [SIP] Informing UA after network initated deregistration?

Thank you,
Igor Slepchin

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 14 Mar 2001 07:59:01 -0500

> From: Stephen Terrill [mailto:[email-masked]]
> Sent: Monday, March 12, 2001 6:04 AM
> To: Jonathan Rosenberg
> Cc: 'Baniel Uri-CUB001'; Igor Slepchin; 'William Marshall';
> [email-masked]
> Subject: Re: [SIP] Informing UA after network initated deregistration?
> 
> 
> 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.

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

 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.

> 
> In such an environment, it is useful to be able to inform the 
> UAC that the registration is not valid so the appropriate 
> action can be taken by the user or the terminal.

No. Registration state has nothing to do with status of my account. My
registration can expire if I'm not on the phone, but my account balance
cannot expire, since only phone calls cause it to decrement.

-Jonathan R.

---
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
http://www.dynamicsoft.com

---

From: Baniel Uri-CUB001 <[email-masked]>
Date: Wed, 14 Mar 2001 15:32:43 -0600

FYI some examples from the cellular world...(not that we necessarily need to copy that.. but is always good to know though..)

pre-paid calling card or the like - Back in the good old days of our analog cellular system we had a service called "advice of charge", in which the MSC used to let the subscriber know about 'almost expiration' of his/her pre paid card (by sending him a SMS notification (IM in the IETF terminology)). It was considered to be a special feature and definitely not part of any standard. So Henning, I am with you on this one.

Registration events ( including expirations ) - Everything here always took place between core network elements and themselves(HLR <-> MSC/VLR), between core network elements and access network elements (MSC/VLR <-> BTS via BSC) and between access network elements and themselves (BTS <-> Mobile station).
The user never knew about these things... That includes reg. expiration.. i.e. it was the network responsibility to take care of it and to make sure the Subscriber's location is known to the relevant network elements (The HLR is the 'registrar'..) and that we actually never experience a bad situation such as reg. expiration.

It is true that comparison of the SIP network to the cellular one may be tricky sometimes, since for instance what is called 'SIP registration' would be compared not only to cellular registration but also to Cellular call forwarding services...

Well, cellular is a huge Pandora box `-)

> From: Henning G. Schulzrinne [mailto:[email-masked]]
> Sent: Wednesday, March 14, 2001 1:11 PM
> To: Sean Olson (EUS)
> Cc: 'Jonathan Rosenberg'; Stephen Terrill (ERA); 'Baniel Uri-CUB001';
> 'Igor Slepchin'; 'William Marshall'; [email-masked]'
> > 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.
> 
> 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. 
> 
> > 
> > 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?
> 
> Again, I can't see why this would be a problem in practice, for the
> reasons noted above.
> 
> > 
> > /sean
> > --
> > Sean Olson <[email-masked]>
> 
> -- 
> Henning Schulzrinne   http://www.cs.columbia.edu/~hgs
>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 16 Mar 2001 23:13:26 -0500

-----Original Message-----
>From: Sriram Parameswar [mailto:[email-masked]]
>Sent: Friday, March 16, 2001 5:09 PM
>To: 'Baniel Uri-CUB001'; 'Igor Slepchin'; 'William Marshall';
[email-masked]
>Hi All, 
>One scenario which was not discussed for network initiated de-registration.
In the cellular 
>world - fraud/lost or stolen mobiles present a problem. 
>In the case that your subscriber loses his mobile and reports it, the
operator may choose 
>to de-register the mobile thus disallowing Mobile Originated and Mobile
Terminated calls. I 
>see this as a perfectly legitimate use of Network initiated
de-registration. 

Indeed, its fine. Nothing wrong with that. The issue wasn't whether or not
the provider is able to remove a registration, but rather whether there is a
need to inform the UA of this. 

>Just to add a little bit more to the discussion - there are contributions
in 3GPP that talk 
>of 'NOTIFY'ing the subscriber when such de-registrations happen.

Well, the suscriber here doesn't have the phone, so its been stolen, right?
Sounds like you should send them email.

-Jonathan R.
---

---

From: "Brian Stucker" <[email-masked]>
Date: Tue, 20 Mar 2001 13:29:52 -0600

I'm sure the packet network would be smart enough to not give a stolen phone
in which the network is aware that service should be denied, an IP address.
Additionally, I'm certain that you're never going to find a service provider
that would allow their client phones to directly access (or be accessed by)
the Internet. They'll put them behind a firewall/NAT of some sort in order
to control this sort of behavior.
 
But, you make a good point in the case of a private IP network.
 
Brian

-----Original Message-----
From: Dean Willis [mailto:[email-masked]]
Sent: Tuesday, March 20, 2001 9:39 AM
To: Parameswar, Sriram [NGB:B658:EXCH]; 'Baniel Uri-CUB001'; 'Igor
Slepchin'; 'William Marshall'; sip
Subject: Re: [SIP] Informing UA after network initated deregistration?

here's the problem -- cancelling the registration neither prevents the phone
from sending or receiving calls. It merely prevents any proxy associated
with the cancelling registrar from correctly proxying calls to the
deregistered identity. So, the thief just tells his buddies to call him by
IP address and not by phone number -- so the registration is never even
accessed. Or the "thief" loads a DNS A record for the phone into another
domain (maybe an A record for "myphone" into domain "phonethief.com"), again
bypassing registration.
 
--
Dean

----- Original Message ----- 
From: Sriram Parameswar <mailto:[email-masked]>  
To: 'Baniel  <mailto:[email-masked]> Uri-CUB001' ; 'Igor Slepchin'
<mailto:[email-masked]>  ; 'William
<mailto:[email-masked]> Marshall' ; [email-masked]
<mailto:[email-masked]>  
Sent: Friday, March 16, 2001 4:09 PM
Subject: RE: [SIP] Informing UA after network initated deregistration?

Hi All, 

One scenario which was not discussed for network initiated de-registration.
In the cellular world - fraud/lost or stolen mobiles present a problem. 

In the case that your subscriber loses his mobile and reports it, the
operator may choose to de-register the mobile thus disallowing Mobile
Originated and Mobile Terminated calls. I see this as a perfectly legitimate
use of Network initiated de-registration. 

Just to add a little bit more to the discussion - there are contributions in
3GPP that talk of 'NOTIFY'ing the subscriber when such de-registrations
happen.

Regards, 

Sriram 

__________________________________________ 
Sriram Parameswar              Phone: 972-685-8540 
Wireless IP MultiMedia (WIPMM)   Fax: 972-685-3563 
Nortel Networks, Richardson USA  Email: [email-masked] 

-----Original Message----- 
From: Baniel Uri-CUB001 [ mailto:[email-masked]
<mailto:[email-masked]> ] 
Sent: Saturday, March 10, 2001 7:42 AM 
To: 'Igor Slepchin'; 'William Marshall'; [email-masked] 
Subject: RE: [SIP] Informing UA after network initated deregistration? 

Igor 

Network initiated deregistration may happen for various reasons. Ironically
I do not see 'registrar crashing' as one of them... (Hot backup etc is just
as you say far beyond SIP and shall not concern us in this regard). It could
be for instance: temporarily suspension of services for a specific
subscriber, because his/her pre paid billing ticket is empty...

I think it is expected by a subscriber to be notified when the system can
not serve him/her. 
He/she may be a bit cranky if he/she was expecting a very important call,
and only after 20 minutes has realized the phone was out of service.. (These
are exactly the things that distinguish between real systems and
kids/hackers toys)

(again just like the cellular analogy). If your system crashed in such a way
that your hot backup did not work, of course you can not do anything about
it.

If I sink in the see, I would probably not have enough time to instruct my
secretary how to pay my last phone bill.. 

It is true though, that we may want to leave it as an implementation offer
to a SIP operator. Still we need to offer him the way to do it, so as to
keep it standardized.

Uri 

-----Original Message----- 
From: Igor Slepchin [ mailto:[email-masked]
<mailto:[email-masked]> ] 
Sent: Friday, March 09, 2001 5:15 PM 
To: 'William Marshall'; [email-masked] 
Subject: RE: [SIP] Informing UA after network initated deregistration? 

> From: William Marshall [ mailto:[email-masked]
<mailto:[email-masked]> ] 

Thank you, 
Igor Slepchin

---

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 20 Mar 2001 17:38:02 -0500

IETF etiquette is to NOT post large attachments to the list.
If you want to offer a large document:
	Usually we suggest you publish an Internet Draft
	Otherwise you should put the document on an available
		server, and post a URL

We have a website where we can post such documents for you
if you wish.  Contact Dean Willis.

Brian

> From: Anatoli Levine [mailto:[email-masked]]
> Sent: Tuesday, March 20, 2001 3:43 PM
> To: Baniel Uri-CUB001
> Cc: 'Dean Willis'; 'Sriram Parameswar'; 'Igor Slepchin'; 'William
> Marshall'; [email-masked]'
> Uri,
> did you ever heard of something called WinZip (if you truly 
> believe that it is
> necessary to post 3MB files to the list)?
> 
> Anatoli
> 
> Baniel Uri-CUB001 wrote:
> 
> > And here is the attachment...
> >
> >
> >
> >
> > From: Baniel Uri-CUB001
> > Sent: Tuesday, March 20, 2001 11:21 AM
> > To: 'Dean Willis'; Sriram Parameswar; Baniel Uri-CUB001; 
> 'Igor Slepchin';
> > 'William Marshall'; [email-masked]
> > This "thief" issue is really an interesting one, because it 
> potetinally
> > leads to other issues as well...
> > One of them is: "The ability to originate/terminate calls 
> directly, i.e.
> > without going through a SIP server."
> > One may want to take a look at the 3GPP TS 23.228 (last 
> version I know of is
> > attached to this email message), and realize that at least 
> in the cellular
> > network, such a direct call between two end points is not 
> going to be
> > enabled (but would always go through what they call P-CSCF 
> and S-CSCF). In
> > real life you have the operator/ISP who enables you to have the SIP
> > services, and thus is interested in being in control of any SIP
> > session/call. (For Billing reasons, QoS, Features etc).
> >
> > In the "thief" case the S-CSCF has the ability to decide 
> whether to enable
> > or disable the call. Any call would have to go through the 
> S-CSCF for both
> > originations/terminations and thus this issue is solvable.
> >
> > I understand that in the 'regular' IP world in which 
> typically the ISP which
> > grant you the Internet access, could not care less about 
> your application
> > layer, a direct SIP call is a viable thing.
> >
> > Well, definitely a food for a thought.
> >
> > Uri
> >
> > ==========================================
> > [email-masked],
> > To: Sriram Parameswar; 'Baniel Uri-CUB001'; 'Igor 
> Slepchin'; 'William
> > Marshall'; [email-masked]
> > To: 'Baniel Uri-CUB001' <mailto:[email-masked]>  ; 
> 'Igor Slepchin'
> > <mailto:[email-masked]>  ; 'William Marshall'
> > <mailto:[email-masked]>  ; [email-masked]
> --------------------------------------------------------------
> ----------
> >                                        Name: 23228-170 IMS 
> Stage 2 Marked.doc
> >    23228-170 IMS Stage 2 Marked.doc    Type: WINWORD File 
> (application/msword)
> >                                    Encoding: base64
>

---

From: Baniel Uri-CUB001 <[email-masked]>
Date: Tue, 20 Mar 2001 17:08:03 -0600

Brian

Thanks a lot for your comment. I must say that out of all the 'good' comments I have received
regarding sending out the attachment, yours is the most polite...

If all these people who were kind enough to comment about the attachment size, would be kind enough to comment regarding the content of the mail as well (including the attached file content...) then it was worth it...

Thanks again! Comments well taken.

Uri

> From: Rosen, Brian [mailto:[email-masked]]
> Sent: Tuesday, March 20, 2001 4:38 PM
> To: 'Anatoli Levine'; Baniel Uri-CUB001
> Cc: 'Dean Willis'; [email-masked]'

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 21 Mar 2001 02:15:02 -0500

For those not at IETF:
 
We discussed this open issue. The conclusion is that there already exists a
general purpose mechanism for learning about network de-registrations. In
fact, the mechanism allows you to learn about any changes in the
registration state of a user. That mechanism is the sip for presence
specifications, draft-rosenberg-impp-presence-01.txt, which are now work
items of the simple working group.
 
Whether this is useful for dealing with thieves stealing phones is an
application issue. THe mechanisms exists and is being standardized. They
require no changes to bis. Thus, the open issue is closed.
 
-Jonathan R.

Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen <http://www.cs.columbia.edu/~jdrosen>
PHONE: (973) 952-5000
http://www.dynamicsoft.com <http://www.dynamicsoft.com/> 

-----Original Message-----
From: Dean Willis [mailto:[email-masked]]
Sent: Tuesday, March 20, 2001 10:39 AM
To: Sriram Parameswar; 'Baniel Uri-CUB001'; 'Igor Slepchin'; 'William

 
--
Dean

----- Original Message ----- 
From: Sriram Parameswar <mailto:[email-masked]>  
To: 'Baniel Uri-CUB001' <mailto:[email-masked]>  ; 'Igor Slepchin'

Hi All, 

Regards, 

Sriram 

-----Original Message----- 

Igor 

Uri 

-----Original Message----- 

Thank you, 
Igor Slepchin