On 2/23/2011 7:53 AM, Razvan Crainea wrote: > > Thank you for commiting that patch. > I would like to open another issue regarding rtpproxy timeout > notification mechanism. > On december we made a release of OpenSIPS with this new feature. Because > of some problems found in RTPProxy, I had to add a patch for it. You can > find it in public svn at > "modules/patches/rtpproxy_timeout_notification.fix_patch". It was made > against RTPProxy branch 600c80493793bafd2d69427bc22fcb43faad98c5 and > fixes the following problem: > I noticed that the timeout notification thread is started in the > main(parent) process. If used in foreground, RTPProxy runs perfectly. > But when submitted in background, as daemon, that thread stops running > properly, and doesn't send any notification. After I moved the thread > initialization in the child process (after forking), I noticed > evreything works fine, without any problems.
I've adjusted the code to do initialization of thread after rtpp_daemon(), please check and let me know if it still doesn't work. > There is also a new feature in that patch: I added a parameter > (called w), that adds a new timeout, for session establishment. In the > official code a single timeout parameter controls both session > establishment and rtp media timeout. The problem is that when setting a > small timeout (media timeout should be detected fast) timeout > notifications are sent before the session can even establish. So we > needed a longer period for session establishment, but a smaller period > for media timeout. > As I told you, that patch was done against an older version of > RTPProxy. If you are willing to commit this behaviour to the official > RTPProxy, I can create a patch against the latest GIT version and send > it to you. > Please let me know your decision. Do you need this in order to get accurate accounting? I am not sure if it's the best approach if so. Perhaps the correct one would be to send RTP session duration and/or timestamp of the last seen RTP packet along with the disconnect notification, so that the accounting can be adjusted accordingly. Please let me know what do you think. Regards, -- Maksym Sobolyev Sippy Software, Inc. Internet Telephony (VoIP) Experts Tel: +1-646-651-1110 Fax: +1-866-857-6942 Web: http://www.sippysoft.com MSN: [email protected] Skype: SippySoft _______________________________________________ Devel mailing list [email protected] http://lists.rtpproxy.org/mailman/listinfo/devel
