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

From: William Marshall <[email-masked]>
Date: Thu, 8 Mar 2001 18:41:09 -0500 (EST)

Since the last message on this thread (2/9), I've gone through the archives
but have not found any discussion related to the question being asked.
If it is there, could someone please tell me the Subject line.

The specific situation is that the UA registers, with an Expires header
giving a reasonable period.  But sometime before that time, something
happens causing the registration to be dropped.

At this point the UA thinks it is registered, but the registrar has nothing.
So, any incoming calls to the UA (as a UAS) will fail.

The UA can certainly re-do the DNS query, and get SRV records, and
try another registrar (like the one that took over for the possibly
failed one).  But, the question is, how does it know to do this?
Something needs to tell the UA that its registration prematurely
expired.  Any suggestions for how this might be done?  NOTIFY?

Bill Marshall
[email-masked]

-----original message-----
From: Jonathan Rosenberg <[email-masked]>
To: "'Bernie Hoeneisen'" <[email-masked]>, [email-masked]
Subject: RE: [SIP] Informing UA after network initated deregistration?
Date: Fri, 9 Feb 2001 07:56:54 -0500

> -----Original Message-----
> From: Bernie Hoeneisen [mailto:[email-masked]]
> Sent: Tuesday, February 06, 2001 11:40 AM
> To: [email-masked]
> Subject: [SIP] Informing UA after network initated deregistration?
> 
> 
> Hi,
> 
> I have some questions concerning informing the UA in case the network 
> de-registers the UA, and wants to inform the UA about this.
> 
> Let me describe a possible use case:  Supposed the UA 
> normally registers
> to only one registrar. Furthermore this registrar needs some 
> maintenance
> break. The policy in this registrar/network is, to inform all its
> registered UAs, that they have been de-registered (and maybe 
> provide an
> address, where it can send a new registration.)
> Remark: There can be more reasons, why a network element needs to
> de-register a user, maintenance break is just one.
> 
> 
> My questions:
> 
> - Has this problem area been addressed earlier in IETF?
>   If yes, please send me some pointers.

Yes. The issue has been raised on the list at least three separate times.
Please check the archives.

> 
> - What do key-people think about such a feature, where a registrar
>   informs about de-registration of users? Is it welcome to include it
>   into a SIP extension (e.g. defining a method for it e.g. UNREGISTER,
>   or re-using other methods such as NOTIFY), or whatever would be
>   appropriate?

My view is the same it was the other three times. Failover and redundancy
for devices contacted by clients is best handled by using things like SRV
records. The SRV record for some registrar would contain a list of ordered
devices to try. When you want to service the main one, you take it out of
service. Clients who re-register will get an ICMP error, and as per
draft-ietf-sip-srv, will then try the next address, which is its backup.

This works not only for registrations, but for outbound proxies, and any
other sip communications, even between servers and servers. SRV is not ideal
for all load balancing and failover needs, as is well known, but I think it
addresses this need perfectly well.

-Jonathan R.
---

_______________________________________________
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: Michael Thomas <[email-masked]>
Date: Thu, 8 Mar 2001 16:04:20 -0800 (PST)

Er, how can the registrar NOTIFY something if it
forgot?

Another means of doing this is to posit a
registrar that explicitly doesn't do what you are
positing by whatever replication mechanism
necessary. I've been under the impression that SIP
expects high availability of registrars. Saying
that registrars (unlike proxies) can roll over and
die with all of its registration state is taboo as
far as I've ever heard. 

I suspect I know where you'd like to go here,
Bill, but I dunna think it's got the same
properties :-)

	    Mike

---

From: "Henning G. Schulzrinne" <[email-masked]>
Date: Thu, 08 Mar 2001 19:24:03 -0500

> Er, how can the registrar NOTIFY something if it

I guess this is the "panic - I'm about to crash/power down" message. One
semi-reasonable case that was brought up last time was taking down the
registrar for maintenance. The solution, I believe, was to remove the
registrar from the SRV list and somehow bulk-copy the registrations to
the buddies.

> die with all of its registration state is taboo as

I think that's about the only realistic option and not that hard
(indeed, you can do this with almost-regular SIP registrars if each
registrar also proxies each new registration to its buddies). In the
"controlled crash" scenarios, it is unlikely that you will have the time
to notify 100,000 registrands. In any event, you cannot guarantee that
you reach all of them. Even if you do somehow, you now have 100,000
registrands pounding the poor substitute registrar with requests in very
short order.

I suspect that most industrial-strength registrars will use a reliable
backend database that handles replication and load sharing. There are
plenty of brand name companies, using either in-memory or classical disk
technology, that deal with this problem as a matter of course. (To name
a non-commercial alternative, even mysql has a primitive version of this
functionality.)

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