...and you *still* have to handle the case where the destination fails between your [PING | OPTIONS | HEARTBEAT | KeepAlive | WHATEVER] message and your actual request that does the useful work. Better to fork your request, maybe?
-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Anshuman Rawat Sent: 22 February 2006 10:53 To: [EMAIL PROTECTED]; OmPrakashTripathi 70630; [EMAIL PROTECTED] Cc: [email protected] Subject: Re: [Sip-implementors] Determinine if a SIP device is alive. SIP-Pinging Will having a few less headers really have much affect in CPU time? Since it is a SIP message, UAS will have to do all the things necessary to process any SIP request. Another point, although a 200 OK response makes sense, but practically any response back to UAC would suggest that UAS is alive. Right? And in case the UAS is down, UAC will have to wait for a timeout to occur for it to know that UAS is down. This might take a while, coming back to original problem (which started this thread). Regards, Anshuman -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Darshan Bildikar Sent: Wednesday, February 22, 2006 2:18 PM To: 'OmPrakashTripathi 70630'; [EMAIL PROTECTED] Cc: [email protected] Subject: Re: [Sip-implementors] Determinine if a SIP device is alive. SIP-Pinging OM... As you know per RFC 3261 OPTIONS is meant for exchanging capabilities (i.e. an options would be processed and answered like an INVITE) and not for heartbeat. In that sense PING would be like a stripped down version which would take up lesser CPU time. There's a thread going on in the SIP working group about the same issue although that also talks about refresh of NAT bindings. Check it out at http://www1.ietf.org/mail-archive/web/sip/current/msg12806.html Darshan -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of OmPrakashTripathi 70630 Sent: Wednesday, February 22, 2006 12:38 PM To: [EMAIL PROTECTED] Cc: '[email protected]' Subject: Re: [Sip-implementors] Determinine if a SIP device is alive. SIP-Pinging Hi Frank, In this draft, you are suggesting to use a new PING method for the Heart Beat kinda considerations between the two UAs. Can you please tell us, in what sense is it different (or say advantageous) than the OPTIONS method, already suggested byt 3261. Thanks, Om.. ************************************************************************ **** ************** This email and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! ************************************************************************ **** ************* ----- Original Message ----- From: "Frank W. Miller" <[EMAIL PROTECTED]> Date: Wednesday, February 22, 2006 10:56 am Subject: Re: [Sip-implementors] Determinine if a SIP device is alive. SIP-Pinging > > There is a draft being discussed on the SIP list right now to > implementa PING method. See http://www.cornfed.com/ping.txt or > http://www.cornfed.com/ping.html for the most recent version. All > comments are welcome since this is a very new draft. > > FM > > > On Tue, 2006-02-21 at 11:07 -0500, Sweeney, Andrew (Andrew) wrote: > > Hi, > > > > I am looking for any draft of RFC that defines how to basically > heartbeat a sip device to know if it is active. Basically in a > fault tolerent enviroment > > I don't want to send a request to a non responsive device. > Presumably I would have knowlege of a backup. > > > > I have implemented a version of sending periodic OPTIONS > requests to my devices as a form of heartbeat but it could take up > to the invite timeout to know if they are alive. That can be a > long time. > > > > Is there any universal method for handling this? Is there any > RFCs or Drafts for SIP in a fault tolerent enviroment? > > > > Thanks > > Andy > > _______________________________________________ > > Sip-implementors mailing list > > [email protected] > > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > > _______________________________________________ > Sip-implementors mailing list > [email protected] > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors ********************** Legal Disclaimer **************************** "This email may contain confidential and privileged material for the sole use of the intended recipient. Any unauthorized review, use or distribution by others is strictly prohibited. If you have received the message in error, please advise the sender by reply email and delete the message. Thank you." ********************************************************************** _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
