Hi Bobby,
The default behavior of RTPProxy is to send timeout notifications only
when both parties stop sending media. This is useful in your situation,
when only one phones sends media. But for solving "ghost calls"
situations, RTPProxy must detect if the media session is disconnected in
only one direction. To enable this feature you must start RTPProxy with
"-i" parameter, but a timeout will be triggered when the party that has
been put on hold stops sending media.
I have just added an improvement to the nathelper module that allows you
to specify which calls require notifications, by calling rtpproxy_offer
function with 'n' flag.
Regards,
On 12/16/2010 09:09 PM, Bobby Smith wrote:
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?
On Thu, Dec 16, 2010 at 1:14 PM, Razvan Crainea
<razvancrai...@opensips.org <mailto:razvancrai...@opensips.org>> wrote:
Hello all,
Problem
--------
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).
"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.
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.
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.
Solution
--------
The overall solution includes the usage of rtpproxy (as media
relay) and opensips (signaling part).
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).
This new functionality is very useful for various scenarios where
having a precise call stats is required, like:
- load balancing based on call load
- precise accounting (for PSTN termination)
- dialog profiling (parallel call limitation).....
For more information about usage and configurations, visit
http://www.opensips.org/html/docs/modules/devel/nathelper.html
This new feature is available in trunk and in branch 1.6 (it will
be part of the future 1.6.4 stable release).
Regards,
--
Razvan Crainea
www.voice-system.ro <http://www.voice-system.ro>
_______________________________________________
Users mailing list
us...@lists.opensips.org <mailto:us...@lists.opensips.org>
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
--
Razvan Crainea
www.voice-system.ro
_______________________________________________
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
