Quick question about this -- does the timeout happen in the case where two joined sessions are in "sendonly" (ie, listening to hold music)? If so, is there an easy way around this and can this feature be enabled on a per force/unforce rtpproxy function call?<br>
<br><div class="gmail_quote">On Thu, Dec 16, 2010 at 1:14 PM, Razvan Crainea <span dir="ltr"><<a href="mailto:razvancrainea@opensips.org">razvancrainea@opensips.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Hello all,<br>
<br>
<br>
<br>
Problem<br>
--------<br>
<br>
I just added to OpenSIPS a new feature that makes possible to deal with "ghost" calls in proper and complete way (detection, reporting and termination).<br>
<br>
"Ghost calls" are calls where (due network or hardware issue), one of the end-points simply died without hanging up the call - so for all the proxies in the middle and for the other end point, the call will still look like ongoing. This is a huge problem when dealing with accounting and charging of PSTN calls.<br>
<br>
As OpenSIPS is a proxy and at signaling level there is no continues traffic to help in detecting the ghost calls, such detection must be done at media level.<br>
<br>
A new feature has been added to the nathelper module, that allows OpenSIPS proxy to terminate calls when a media timeout occurs in an ongoing call.<br>
<br>
<br>
<br>
Solution<br>
--------<br>
<br>
The overall solution includes the usage of rtpproxy (as media relay) and opensips (signaling part).<br>
<br>
RTPProxy is used to detect the media timeouts and to report them back to opensips (via the nathelper module). The nathelper module binds to dialog module and it will terminate the call (by sending BYEs in both directions) when such notification is received. By closing the call at signaling level, you will have the opportunity (using the "local" route) to do certain script operations when the BYEs are fired (like doing accounting, logging, etc).<br>
<br>
This new functionality is very useful for various scenarios where having a precise call stats is required, like:<br>
- load balancing based on call load<br>
- precise accounting (for PSTN termination)<br>
- dialog profiling (parallel call limitation).....<br>
<br>
<br>
For more information about usage and configurations, visit <a href="http://www.opensips.org/html/docs/modules/devel/nathelper.html" target="_blank">http://www.opensips.org/html/docs/modules/devel/nathelper.html</a><br>
<br>
This new feature is available in trunk and in branch 1.6 (it will be part of the future 1.6.4 stable release).<br>
<br>
Regards,<br>
<br>
-- <br>
Razvan Crainea<br>
<a href="http://www.voice-system.ro" target="_blank">www.voice-system.ro</a><br>
<br>
<br>
_______________________________________________<br>
Users mailing list<br>
<a href="mailto:Users@lists.opensips.org" target="_blank">Users@lists.opensips.org</a><br>
<a href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users" target="_blank">http://lists.opensips.org/cgi-bin/mailman/listinfo/users</a><br>
</blockquote></div><br>