Andy, my take - it really depends on what you mean by 'active'. For example, the device could be active but due to some error, may not be functioning as a SIP entity any more (maybe the SIP stack crashed into an invalid state ;-) but the device is alive at the IP and phy level)
Many implementations use SIP OPTIONS for all sorts of 'keep alives' and 'check if alive' operations - however, if your concern is the timeout duration, then your concern is valid no matter what SIP transaction you use (OPTIONS/MESSAGE/any other request) which rolls back to the basic question 'is SIP the right choice for your need' ? regds arjun On 2/21/06, Sweeney, Andrew (Andrew) <[EMAIL PROTECTED]> 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 > -- Arjun Roychowdhury _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
