Subject: Re: A few questions on REGISTER

From: "Anoop Tripathi" <[email-masked]>
Date: Mon, 27 Sep 1999 11:43:40 -0500

If the protocol had an UNREGISTER message , this problem could be bypassed by
implementing

" UNREGISTER to all registered clients on a shutdown."

Now all the unregistered clients keep trying to register and when the server
comes up , the system is up and running.

However, the problem still remains for systems which do not use the UNREGISTER
message. ( Well what do you get when you implement
something partially ?).

Also, the problem still remains in case a Registrar/Proxy server crashes (
without sending  UNREGISTER messages ) and then comes up to
find the Registration DB corrupt?

Any suggestions to fix this ?

IP telephony is fun.

Anoop

Henning Schulzrinne <[email-masked]> on 09/27/99 11:24:08 AM

Sent by:  Henning Schulzrinne <[email-masked]>

To:   Anoop Tripathi/MW/US/3Com
cc:   David Oran <[email-masked]>, Jonathan Rosenberg <[email-masked]>,
      [email-masked], [email-masked]
Subject:  Re: A few questions on REGISTER

Anoop Tripathi wrote:
>
> I implement a PBX with one proxy/registrar server and 300 clients(DHCP ) .
> All clients send a registration once every 24 hours.
>
> I bring down my proxy server for maintenance.
> When I try to bring it back up , I find the registration data is corrupted.
> So I cannot resotre the registration information to a state before the proxy
was
> shutdown.
>
> what do I do to get the system in service.

Easy: just call up your friend at the local utility company and ask them
for a brief power interruption :-) Or call up your landscaping
department and ask them to install some new flagpoles where the power
line enters your premises. You can also ask our local construction
company for assistance. They seem to have the necessary background in
implementing backhoe fade.

>
> Go to all the 300 desks and reboot the individual machines.
>
> I think having a  UNREGISTER request is not bad. However, if we have it in the
> specification saying a REGISTRAR may silently discard a registration or
discard
> with a specific UNREGISTER depending upon the implementation .

In that case, an individual UNREGISTER wouldn't do much good since you
don't know who should be registering. I suppose a "hey, I'm a new
registrar (or I can't remember if I'm new or not)" message might be more
productive.

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

---

From: "Stephen Sprunk" <[email-masked]>
Date: Mon, 27 Sep 1999 12:45:29 -0500

My suggestion would be to not introduce single points of failure into the
system.

This was hashed out a few weeks ago; does anyone have archives available so
that we don't have to repeat the argument?

S

Stephen Sprunk, K5SSS, CCIE#3723
Network Consulting Engineer
Cisco NSA   Dallas, Texas, USA
e-mail:[email-masked]
Pager: +1 800 365-4578
Empowering the Internet Generation

----- Original Message -----
From: Anoop Tripathi
To: Henning Schulzrinne
Cc: David Oran ; Jonathan Rosenberg ; [email-masked] ; [email-masked]
Sent: Monday, September 27, 1999 11:43
Subject: Re: A few questions on REGISTER

If the protocol had an UNREGISTER message , this problem could be bypassed
by
implementing

However, the problem still remains for systems which do not use the
UNREGISTER
message. ( Well what do you get when you implement
something partially ?).

IP telephony is fun.

Anoop

To:   Anoop Tripathi/MW/US/3Com
cc:   David Oran <[email-masked]>, Jonathan Rosenberg
<[email-masked]>,
      [email-masked], [email-masked]
Subject:  Re: A few questions on REGISTER

was

discard

---

From: Anders Kristensen <[email-masked]>
Date: Mon, 27 Sep 1999 20:20:59 +0100

> that we don't have to repeat the argument?

yessiree.

  http://www-uk.hpl.hp.com/people/ak/confctrl/1999/

AK

-- 
Anders Kristensen <[email-masked]>,
http://www-uk.hpl.hp.com/people/ak/
Hewlett-Packard Labs, Bristol, UK

---

From: "Adam B. Roach" <[email-masked]>
Date: Mon, 27 Sep 1999 16:43:52 -0500 (CDT)

>Any suggestions to fix this ?

It sounds very much like what you want is a system with centralised
control. So do it. No one says you can't keep persistant information
about how to direct phone calls. Provision the fact that all calls
for "+1 512 555 0437" go to "sip:[email-masked]" instead of 
relying on a registration system.

If you need the flexibility to register other clients, allow
REGISTER messages, too -- with the caveat that they may become
unregistered upon a system shutdown/crash.

--
Adam Roach, Ericsson Inc. |  Ph: +1 972 583 7594 | 1010 E. Arapaho, MS L-04
[email-masked]   | Fax: +1 972 669 0154 | Richardson, TX 75081 USA

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 28 Sep 1999 11:25:42 -0400

> find the Registration DB corrupt?

This is the part I find confusing. Why is your old registration database
corrupt? If you have a flakey drive, you shouldn't depend on the
protocol to get around your hardware problems. 

In any case:

1. sending UNREGISTER to each registered user individually doesn't work.
You'll miss people who register during the transition period, or that
are temporarily disconnected. It also doesn't scale well, as you'll get
tons of responses.

2. sending a multicast type of UNREGISTER also doesn't work, since you
can't get responses (implosion problem), and then you won't know if it
worked or not.

The best way to handle this is to use SRV records to point to your
backup server, wait for DNS ttls to expire, and then take down the
primary. By then, everyone is using the backup. Also, multicast
registrations are a huge benefit here also. Don't try to handle backups
by telling ALL your clients about it, and hope they pick up the new
backup.

-Jonathan R.

-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX:   (732) 834-5379                       Rm. 4C-526
EMAIL: [email-masked]
URL: http://www.cs.columbia.edu/~jdrosen

---

From: Anders Kristensen <[email-masked]>
Date: Tue, 28 Sep 1999 19:25:42 +0100

trying to move the discussion to the new SIP list... hopefully it
doesn't delay messages for several hours before sending them like the
confctrl list does.

> by telling ALL your clients about it, and hope they pick up the new

This procedure doesn't really depend on the use of SRV. The same
sequence of steps for A RRs will allow you to (eventually) swap servers,
and I guess this is not an uncommon way of using A records (www.hp.com
has 4 A RRs). It *is* desirable to use SRV records, though, for other
reasons.  Related to this is the point that SIP implementations probably
ought to try *all* A addresses associated with a domain name, before
giving up.

Anyway, it seems to me that SIP registrations serve the same purpose as
service announcements in the varios service discovery protocols.
Comparing with the Service Location Protocol (SLP), a SIP UAS is like an
SLP service agent, a UAC is like an SLP user agent, and a
registrar/redirect server/proxy is like an SLP directory agent.

It is probably reasonable to assume that regarding service discovery
more thought has gone into designing SLP than SIP and so it's of
interest to consider what SLP does regarding UNREGISTERs, and I believe
it doesn't support this, although there might be a proposed extension
for it. I think this corresponds well with the common idea of what
operations are supported by a directory.

Maybe I'll try and do a SIP SLP schema...

Regards,
Anders