[OpenSIPS-Devel] [OpenSIPS-Users] [NEW] Media timeout detection and call termination
Razvan Crainea
razvancrainea at opensips.org
Fri Dec 17 19:11:50 CET 2010
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
> <razvancrainea at opensips.org <mailto:razvancrainea at 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
> Users at lists.opensips.org <mailto:Users at lists.opensips.org>
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
>
> _______________________________________________
> Devel mailing list
> Devel at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
--
Razvan Crainea
www.voice-system.ro
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/devel/attachments/20101217/0355891a/attachment.htm>
More information about the Devel
mailing list