Subject: Re: How does a Registrar inform UA about deregistration?

From: "Anoop Tripathi" <[email-masked]>
Date: Thu, 12 Aug 1999 14:02:52 -0500

You are assuming a cluster of machines. What if I want to operate in a pure
primary Server and a pure Secondary Server ? I see a lot of value for that in
trunking GWs. e.g. A PSTN GW (UA) registers with a proxy server( assume no
redundancy). In case of proxy server going down for maintenance , the proxy
server sends an de-registration to the UA. The UA busies out its trunks becuase
it knows it cannot route the calls. The switch routes the calls over some other
available trunk. Meanwhile , the redundancy could be acheived by configuring on
the UA a secondary proxy server to contact ( or use multicast ). So the UA could
try contacting the alternate servers and on successful response from one of the
servers  come back online.

Also , does that mean since I don't have a de-registration message , I am forced
to implement using clustering. Now that I am clustering , it is almost
impossible for me to implement a stateful proxy.

Hence I think it would be nice to have this de-registration message.

Anoop

"Stephen Sprunk" <[email-masked]> on 08/12/99 12:02:22 PM

Sent by:  "Stephen Sprunk" <[email-masked]>

To:   Anoop Tripathi/MW/US/3Com, [email-masked]
cc:
Subject:  Re: How does a Registrar inform UA about deregistration?

UA registers with sip.example.com.  sip.example.com now wants to go down for
maintenance.  You propose that the UA needs to register with another server.
However, the point of registration is that [email-masked] will work..
Now we say that the new URL is [email-masked]?  That breaks the
whole purpose of registration.

I would envision a setup where you have a redundant cluster of machines all
answering for sip.example.com, either via a L4 switch or via multiple SRV
records.  When a registration comes in to one server, that server would be
responsible for notifying all other servers about it (since they're all
authoritative) or updating the central database they all use (like a
high-availability SQL server cluster), depending on the implementation.
Then if you needed to do maintenance on any server, you either remove it
from the L4 switch or from the SRV record list, and it simply stops
receiving queries/registrations.  When it comes back up, it is responsible
for resynchronizing with the rest of the server cluster.

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: [email-masked]
Sent: Thursday, August 12, 1999 11:25
Subject: How does a Registrar inform UA about deregistration?

Take an implementation where the Proxy/Registrar in implemented in one box.

A UA registers with Proxy/Registrar and expects the Proxy/Registrar to
forward
all calls to it that are intended for this UA.

Now the proxy/Registrar  wants to go under maintenance. How does the Proxy
inform the UA that it should register with some other server.

 To summarize , H323 has RRQ , SIP has REGISTER. What is the equivalent of
URQ
in SIP ?

Anoop

---

From: "Stephen Sprunk" <[email-masked]>
Date: Thu, 12 Aug 1999 18:34:37 -0500

A pure primary/secondary scenario is just an edge case of the SRV (ie
DNS-based) system I described.  When the primary is going to shut down, it
flushes its registrations/state to the secondary server, repoints the SRV
record, and redirects subsequent requests (due to cached DNS) to the
secondary.  After a safe period, you perform maintenance on the primary.

This prevents the UA from having to know anything about which server(s) are
up or down at any given time; just use DNS.

How else were you planning on dealing with active calls with your stateful
proxy?  Even if you could notify a UA that you were unregistering it, you
still have to stay up until all the active calls are completed, no?

S

----- Original Message -----
From: Anoop Tripathi
To: Stephen Sprunk
Cc: [email-masked]
Sent: Thursday, August 12, 1999 14:02
Subject: Re: How does a Registrar inform UA about deregistration?

 You are assuming a cluster of machines. What if I want to operate in a pure
primary Server and a pure Secondary Server ? I see a lot of value for that
in
trunking GWs. e.g. A PSTN GW (UA) registers with a proxy server( assume no
redundancy). In case of proxy server going down for maintenance , the proxy
server sends an de-registration to the UA. The UA busies out its trunks
becuase
it knows it cannot route the calls. The switch routes the calls over some
other
available trunk. Meanwhile , the redundancy could be acheived by configuring
on
the UA a secondary proxy server to contact ( or use multicast ). So the UA
could
try contacting the alternate servers and on successful response from one of
the
servers  come back online.

Also , does that mean since I don't have a de-registration message , I am
forced
to implement using clustering. Now that I am clustering , it is almost
impossible for me to implement a stateful proxy.

Anoop

S

----- Original Message -----
From: Anoop Tripathi
To: [email-masked]
Sent: Thursday, August 12, 1999 11:25
Subject: How does a Registrar inform UA about deregistration?

Anoop

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 12 Aug 1999 22:00:29 -0400

> still have to stay up until all the active calls are completed, no?

Yes, it would have to stay up. But, thats the least of your worries. You
MUST change the DNS SRV record to bring a server down and swap in a
backup. Here's why:

1. There will be hosts that aren't currently registered at all that will
come up later. These may still be configured to use the old server. You
need to change the DNS SRV record so that these folks pull in the new
address. If you are using multicast registrations, its not an issue.
2. The bigger problem is not UA's, but other proxies. They will
generally do a DNS SRV lookup to resolve URI's to the address of the
server. You can't inform these proxies of the change, since you don't
even know who they are. The only thing you can do is change the SRV
record. So, if you're changing it, no need to tell the UA's either
(presuming they are configured to register at a hostname and not an IP
address)

Also, in a SIP server with 10,000 registered users, sending 10,000
messages out to tell people to change servers seems a bit troublesome. 

Of course, with the SRV change, you'll need to wait a bit until
everyones caches expire. As Steven has pointed out, the primary can
redirect requests anyway (remember any request can be redirected, even
registers). Thats a nice side effect of a generic request-response
model.

An even easier solution is if the backup is on the same LAN, don't even
change IP addresses. Transfer over the state, switch one off and the
other back on right away. You might want to flush ARP caches first,
though..

-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: Henning Schulzrinne <[email-masked]>
Date: Fri, 13 Aug 1999 14:16:58 -0400

> MUST change the DNS SRV record to bring a server down and swap in a

I would modify this to SHOULD :-), since things will work, albeit with
delays, even if the SRV record wasn't changed. The client or proxy will
simply try the servers in order, until it finds one that works. If the
server stays up, but refuses connections on the server port, this will
roughly add one retransmission delay for UDP and one round-trip for TCP
for registrations and proxy operations. (It's slower for UDP since the
ECONNREFUSED will appear on the second transmission attempt for the
connected UDP socket.)

One additional feature that is helpful in server-change situtations is
third-party registration. The old server can simply do a third-party
registration for all of its current registrations before it passes the
baton to its vacation substitution. No new protocol or other mechanisms
are required.

H.