Samuel - take a look at the recently submitted:- http://www.ietf.org/internet-drafts/draft-gurbani-sipping-connection-gui delines-00.txt
This references a proposed keep-alive mechanism that will be appearing in the archives after IETF 60. Chris. -----Original Message----- From: Samuel Osorio Calvo [mailto:[EMAIL PROTECTED] Sent: 22 July 2004 09:27 To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RE: [Sip-implementors] keep-alive mechanism Thanks a lot!!! I'll take a look at ICE/STUN option. Just if you remeber, can you please point me out where Jonathan's comments regarding keep-alive comments are (date?)? Is there any method which is closer to SIP standard?? or just recommended mechanism??? I've been looking in RFC/drafts and see no comments. Regards, Samuel Unclassified >>> <[EMAIL PROTECTED]> 07/22/04 06:12AM >>> Hi Samuel, Comments inclined. HTH, Regards, Sreeram -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Samuel Osorio Calvo Sent: Tuesday, July 20, 2004 3:32 PM To: [EMAIL PROTECTED] Subject: [Sip-implementors] keep-alive mechanism Hi all! Since SIP does not provide keep-alive mechanism, what is the best approach to detect end-point failure within a reasonable time? A) Session timers negotiation is useful for stateful proxies but not for UA-UA since it would take a long time to detect that an end-point has crashed. It is recommended, as far as I know, to use lack of RTP or RTCP data to detect end-point failure. But this may not be appropriate for some scenarios, like for instance where end-points are muted by a third element, or in large conferences with high RTCP retransmission rate (not to mention some real applications without RTCP part). How to deal with ICMP errors (UDP) or TCP connection shutdown cases? Are they the best approach to detect end-point failure (it will , though, only allow detecting whenever sending a message)? Is it then appropriate to developn an out-band mechanism? Or using SIP INFO or OPTIONS methods? [Sreeram] 1.using OPTIONS is a good option. When you observe that signaling path is working fine and still media is down, to re-pair send re-invite or update. Using re-invite if you observe that there is no change in the media description, and still media path is not established you can try with different path. 3 (As jonathan pointed out some time back in the list). another option is using ICE, which is using STUN to do connectivity checks B) Imagine a centralised conference where focus and mixer are not in the same host. How does participants know that the focus has crashed? Moreover, how to deal with the case of end-points and mixer working but no focus running? Shall the ens-points detect it as fast as possible and close the RTP streams? [Sreeram] After media path establishment ,if the signaling path is crashed and the session timer did not expire on the either side than "how can the UA's know that the signaling path is gone..!!! So same explanation as in case 1 should be used to detect this. Once it knows that the signaling path is gone!! It should send a bye and try to close the session. (or) send a invite or update to repair the connection There is only a signalling relationship betweent the focus and participants. Thus: Using the RTP/RTCP approach, does end-points send a BYE to the focus when they detect that the mixer has crashed?? Thank you. Comments are higly appreciated, Samuel. Unclassified _______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors Confidentiality Notice The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain confidential or privileged information. If you are not the intended recipient, please notify the sender at Wipro or [EMAIL PROTECTED] immediately and destroy all copies of this message and any attachments. _______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors This message has been scanned for viruses by MailControl - www.mailcontrol.com _______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
