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

From: Baniel Uri-CUB001 <[email-masked]>
Date: Wed, 21 Mar 2001 11:25:46 -0600

Steve

The ability for a user to by pass the IMS sub system is a Pandora box on its
own.. wisely enough you have suggested that we move back to the original
thread..
So back there now..

Would it be correct to say that it all boils down to our wish to let the
user know about network initiated deregistration, but we just not sure if we
like to leave it as a service oriented thing, which by definition may be
implemented differently by different operators/ISPs. Or either we like to
impose it by the standard (and then we have to specify how and when...)?

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

> -----Original Message-----
> From: Stephen Terrill [mailto:[email-masked]]
> Sent: Wednesday, March 21, 2001 2:05 AM
> To: Baniel Uri-CUB001
> Cc: 'Dean Willis'; Sriram Parameswar; 'Igor Slepchin'; 'William
> Marshall'; [email-masked]; Bonnie Chen
> Subject: Re: [SIP] Informing UA after network initated deregistration?
> 
> 
> Hi Baniel,
> 
> I am not sure if I understand your interpretation.  As I 
> understand the 3GPP work will always allow a user to have 
> direct internet access (that is part of the GPRS earlier 
> standards) and this doesn't get removed just because a new 
> system termed (IP Multimedia core network subsystem) is 
> created.  As such, it will always be possible to created a 
> direct connection between two terminals - of course the user 
> will have to pay for the bearer usage accordingly.  Further, 
> this behaviour is to be encouraged.  With this model, the SIP 
> proxies will be used because of the value they add to the end user.
> 
> Back to the original thread - I still view that it would be 
> important for the Uac to understand that the registration is 
> no longer valid.
> 
> ..//Steve
> 
> Baniel Uri-CUB001 wrote:
> 
> > Dean
> >
> > 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],
> > Tel: (847) 632 4616; Fax: (847) 632 3963;
> > ===========================================
> >
> >
> >
> > -----Original Message-----
> > From: Dean Willis [mailto:[email-masked]]
> > Sent: Tuesday, March 20, 2001 9:39 AM
> > To: Sriram Parameswar; 'Baniel Uri-CUB001'; 'Igor 
> Slepchin'; 'William Marshall'; [email-masked]
> > 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 Uri-CUB001' <mailto:[email-masked]>  ; 
> '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?
>
> > -----Original Message-----
> > From: William Marshall [ mailto:[email-masked]
<mailto:[email-masked]> ]
> >
> > 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.
>
> 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
>
> _______________________________________________
> 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: Romeo <[email-masked]>
Date: Thu, 22 Mar 2001 10:46:56 +0100

Hi Uri,

>own.. wisely enough you have suggested that we move back to the original

I think with Jonathan's last message stating the outcome of the discussion 
in Minneapolis the thread seems to be closed.

>impose it by the standard (and then we have to specify how and when...)?

This might be considered a 'service oriented thing'. However, it does not 
seem to present an obvious case for service differentiation between 
operators. If you implement this feature, it does not make sense to have it 
work some of the time, i.e. when I am in my own operators 'domain', but to 
loose this functionality when I am using some other operators domain to 
obtain services. I'd opt for having a standardized mechanism for conveying 
this type of information to the terminal. If I understand things correctly, 
we seem to have one in the sip-for-presence work.

Romeo

>Uri

[... further history deleted ...]

---

From: "Sriram Parameswar" <[email-masked]>
Date: Thu, 29 Mar 2001 17:51:32 -0600

OK - I'll bite. I totally agree with you that implicit subscription is not
supported in the presence specifications. That leaves us with two approaches

1. Use the draft-roach-sip-subscribe-notify-03.txt where a registration is
an implicit subscription to the *event* of de-registration. You
automatically get a NOTIFY upon de-registration. This is the 3GPP approach.

2. You SUBSCRIBE to your own presence (say automatically with Registration).
Upon de-registration, the NOTIFY is automatically sent. This will give you
some interesting side effects: if you have set up Authorisation for
Watchers(via QAUTH), will it ask you for your credentials? The other effect
is: Visibility Rules - which controls how a Presence Service makes Watcher
Information available to other Watchers (these could be Presentities). I
could have a service where I send Instant Messages to all my Watchers -
would this mean I receive my own msg?  None of what I state here is a
problem - just interesting side effects.

Regards,

Sriram 

-----Original Message-----
From: Romeo Zwart [mailto:[email-masked]]
Sent: Thursday, March 29, 2001 9:25 AM
To: Bob Penfield; Baniel Uri-CUB001; 'Stephen Terrill'; 'Romeo'; 'Dean
Willis'; Parameswar, Sriram [NGB:B658:EXCH]; 'Igor Slepchin'; 'William
Marshall'
Cc: Chen Bonnie-BCHEN1; Xu Lang-LXU1; sip
Subject: Re: [SIP] Informing UA after network initiated deregistration?

At 03:32 PM 3/29/2001, Bob Penfield wrote:
>Baniel Uri-CUB001 wrote
> > I remember Jonathan's stating about having the outcome of the discussion
> > in Minneapolis closes the titled thread.
> > Can someone provide me please with an appropriate link to the
draft/paper,
>which summarizes the closure which has been achieved on this.
>
>I believe the final outcome of this issue is that the REGISTER message can
>imply subscription to an "unregister" event which would be sent to the UA
in
>a NOTIFY request if and when the event occured.
>
>SUBSCRIBE/NOTIFY is described in draft-roach-sip-subscribe-notify-03.txt

This may come down to wordsmithing, but I think Jonathan referred to
the SIP for presence work - being an existing package for the SUB/NOT
framework.

One of the reasons the difference may be of interest, is that the
concept of implicit subscription is not mentioned in the sip-for-presence
document.

With that particular issue and some other minor questions, I tried to
resuscitate this thread on the SIMPLE list, but so far without much
success. Any takers out here?

Romeo

>The implicit subscription notion also exists in the REFER method proposed
in
>draft-ietf-sip-cc-transfer-04.txt
>
>Bob
>d:-)
>
>Robert F. Penfield
>Chief Software Architect
>Acme Packet, Inc.
>130 New Boston Street
>Woburn, MA 01801
>[email-masked]