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

From: "Samir Srivastava" <[email-masked]>
Date: Tue, 14 Oct 2003 16:51:18 -0700

I am proposing an event similar to "cold-start" trap in SNMP. The way 
SNMP agents keep track of Trap Subscribers across restarts, SIP servers
can keep track of this proposed event's subscribers. Using the similar 
approach, I think subscription-state will not be lost in restart and 
failure.

I looked in 3539, it is like, sending OPTIONS, based on the traffic
monitoring. That's fine.  It also attempts to open the connection 
periodically, if it goes to closed state. Which is similar to sending
OPTIONS periodically if server is not responding.

We can document receommendation similar to it for SIP. I am willing to
volunteer for it.

Thx
Samir

-----Original Message-----
From: Jonathan Rosenberg [mailto:[email-masked]]
Sent: Thursday, October 09, 2003 11:20 AM
To: Samir Srivastava
Cc: Dean Willis; [email-masked]; [email-masked]
Subject: Re: [Sip] Event Based Heart Beat in SIP

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.

Samir Srivastava wrote:

> 
> -----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
> 

-- 
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

_______________________________________________
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