On Wed, Aug 20, 2008 at 11:21 AM, Jo?o C?sar <jpcesar at gmail.com> wrote: > >For the detection part, you can either poll the media statistics to see if > RTP packets are still received, or periodically send re-INVITE > > or UPDATE to check if remote is still responding. > > That would be an option, but would not be more efficient to handle that > once i receive these: > > 16:21:17.739 strm0242A31C RTP recv() error: Connection reset by peer > (WSAECON > RESET) [err:130054] > 16:21:17.755 strm0242A31C RTP recv() error: Connection reset by peer > (WSAECON > RESET) [err:130054] > (...) > > Is this event easily traceable? Can I catch this event once it occur, or, > as you say, do I have to check for this polling the media statistics? > > That error is currently not visible to application, so it's not easy to catch. And different OS'es reports ICMP unreachable packet differently. While on Windows we get it with recv(), you may get it on send() on Linux or other OS'es, and you may not even get it at all since we don't do UDP connect() in the media transports. And also some routers may block these ICMP packets from going through. So I'd say polling is the most reliable way to do the detection. -benny -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/attachments/20080820/40a4e594/attachment.html
