Subject: RE: [Sip] Event Based Heart Beat in SIP

From: "Samir Srivastava" <[email-masked]>
Date: Wed, 8 Oct 2003 13:41:10 -0700

-----Original Message-----
From: Dean Willis [mailto:[email-masked]]
Sent: Wednesday, October 08, 2003 12:12 PM
To: [email-masked]
Cc: Samir Srivastava; [email-masked]
Subject: RE: [Sip] Event Based Heart Beat in SIP

On Wed, 2003-10-08 at 03:41, [email-masked] wrote:
> Excuse my lack of knowledge about ICMP, but don't you get an ICMP
error when you send a UDP packet an server that is not listening on the
port you sent it to?
> 
> Also for TCP, you get an error when you try to connect the sockets.
> 
> Someone please correct me if I'm wrong.

In practical terms, "maybe". If the Internet were pure and
unadulterated, you'd get an ICMP Port Unreachable response.

Unfortunately, lots of systems no longer send such ICMP responses, and
many firewalls block them. It seems that these response codes are useful
for scanning for "open" ports that might later be victimized.

SS>> I have also seen them getting blocked. It's good for security.

In fact, some of my colleagues go so far as to automatically add packet
filter entries that block future traffic from any address they think
might be probing them. I really enjoy UDP port-scanning these guys using
a spoofed address that happens to correspond to their upstream DNS
server, NTP server, DHCP server, or the like. This holds the same sort
of fascination as popping packing bubbles or scaring oppossum,
millipedes, and other creatures that go fetal when one says "boo!" at
them. But that's another story.

Also, it is not uncommon for server applications to die in such a way
that they continue to "listen" to ports, but don't ever respond -- so
even if ICMP were "live", you'd still get no failure indication. This
seemed to happen a lot with early SIP servers running on early Java VMs,
which I believe was related to the threading model in use.

SS>> This is actually the case, where IP /PORT is reachable, but server 
doesn't respond because it has got stuck up somewhere else. There can
be other application level logic problems in some corner cases when
it can happen. That's why we need the SIP Application level heart beat. 
The probing client keeps sending the OPTIONS Req to find server's health
when it is dead w.r.t. issuing signaling responses. To avoid these
options 
requests in these "SIP Unreachable time", the client can stop probing
after
reaching some threshold, if there is a way to give the responsibilty to 
server to tell clients when it is ready to process the signaling
requests. 

Thx
Samir

--
Dean

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 09 Oct 2003 14:19:43 -0400

An application layer heartbeat is definitely the right thing to do. I 
don't think SUBSCRIBE/NOTIFY is the right thing here, since presumably 
the subscription state itself would frequently be lost in the case of 
a failure and restart. Thus, you need some kind of periodic keepalive.

Many implementations do this today with a variety of different 
technqiues. ANythign that solicits a response from any downstream 
element will more or less work. However, care must be taken in 
designing these mechanisms so as not to cause congestion problems. An 
excellent draft has been written on this topic pertaining to 
keepalives in AAA systems. See section 3.4 of RFC 3539. Having a 
documented recommendation for SIP, similar to this section, would be 
beneficial to the community, I think.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com