Subject: [Simple] Questions on draft-rosenberg-impp-presence-01 (was: RE: [SIP] Informing UA after network initated deregistration?)

From: Romeo Zwart <[email-masked]>
Date: Fri, 23 Mar 2001 15:58:10 +0100

A recent thread on the SIP list discussed the need to notify a UA of the 
(network initiated) revocation of its registration.  According to the 
attached message from Jonathan, the general view is that this could be 
handled by the mechanisms described in the sip-for-presence events package.

My understanding is that the Registrar maintains the registration state for 
the UA and thus could keep the Presence Agent (PA) role for the UA. The UA 
then SUBSCRIBEs to its own presence information at the PA (Registrar). In 
the case of a network initiated (or any other) change in the Registration 
state, the PA provides this information to the UA by sending a NOTIFY with 
the new state information. This allows the UA and Registrar to keep the 
same view of the Registration state of the user and possibly also allows 
for providing other service related information to the UA.

I'd be interested to hear your comments on this view.

Related I have a few questions on draft-rosenberg-impp-presence-01:

- In section 5.4, the presence data format is listed as TBD. Examples later 
in the document seem to focus on XML. Has there been any progress on this 
issue? Could someone point me to the relevant discussion  (could not find 
anything in the archives)?
- In the last paragraph of section 3, the statement is being made that a 
NOTIFY is being treated in the same way as a re-INVITE, whereas the 
SUBSCRIBE is handled similar to an INVITE. I am not sure  understand the 
reasoning behind that. In case this has been discussed on the list, could 
someone provide me with a pointer to the related thread? Otherwise, could 
someone explain the rationale behind it?
- The SIP event framework document mentions the possible use of implicit 
subscription, where a UA may receive NOTIFY's without having explicitly 
SUBSCRIBED to the related events. Implicit subscription is not mentioned in 
the ipmm draft. Is this because it was not considered appropriate or 
because it was considered an implementation detail?

Thanks,

Romeo
------------------------

>From: Jonathan Rosenberg <[email-masked]>
>To: "'Dean Willis'" <[email-masked]>,
>         Sriram Parameswar <[email-masked]>,
>         "'Baniel Uri-CUB001'" <[email-masked]>,
>         Igor Slepchin <[email-masked]>,
>         "'William Marshall'" <[email-masked]>, [email-masked]
>Subject: RE: [SIP] Informing UA after network initated deregistration?
>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 
>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: <mailto:[email-masked]>Sriram Parameswar
>To: <mailto:[email-masked]>'Baniel Uri-CUB001' ; 
><mailto:[email-masked]>'Igor Slepchin' ; 
><mailto:[email-masked]>'William Marshall' ; 
><mailto:[email-masked]>[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.
>