[SR-Users] CallControl and MediaProxy

Thu Feb 23 20:59:48 CET 2012

First, I am posting about the wrong behavior of CallControl (or most
probably Kamailio modules) which leaves no option. I should be the only one
deciding about how to handle timeouts. If I decide to take some risk, no
module should oblige me to do otherwise.

Mediaproxy detects ONLY RTP timeouts from BOTH parties, because linux
conntrack rules it uses are bi-directional. If a single party stops sending
RTP for whatever reason (connection lost, codec with silence detection
used, ....), mediaproxy doesn't care and doesn't act upon it. This is a
feature, and a wanted one, to mainly support voice-detecting codecs. Think
also about conferences for example, in which only a single person talks for
a long time while others are silent and don't send RTP.

Single-side RTP timeout because of a real problem (loosing network
connection for example) should be handled with other methods, such as SIP
session timers.

MY POINT IS : I don't see it practical to handle RTP flows for EVERY call
to handle the least probable scenario: an RTP timeout from both (or all)
parties.

If I understood well, mediaproxy updates the CDR when it detects an RTP
timeout from both parties. CallControl can look in the CDR to debit the
correct balance, instead of attaching itself to the dialog module to detect
dialog termination.

This is an extract from the call_control module :

Even when mediaproxy is unable to end the dialog because it was not started
with engage_media_proxy(), the callcantrol application is still able to
detect calls that did timeout sending media, by looking in the radius
accounting records for entries recorded by mediaproxy for calls that did
timeout. These calls will also be ended gracefully by the callcontrol
application itself.

Unless there is something I miss..

I also opened a bug about the issue because call_control doesn't have the
same behavior with OpenSips. It doesn't force mediaproxy.

Reda

On Thu, Feb 23, 2012 at 20:00, Jeff Brower <jbrower at signalogic.com> wrote:

> Reda-
>
> > It's clear but not necessary. It can look at radius records fixed by
> > mediaproxy on RTP timeout to debit the correct balance as well. And why
> > also force it on postpaid calls which it doesn't control at all ?
>
> I don't understand how you plan to tear down Kamailio calls that suffer
> RTP time-out?
>
> -Jeff
>
> > What happens is cost and performance issues for additional calls passing
> > through my mediaproxy server, which I didn't plan for at first. No audio
> > issue at all.
> >
> > Reda
> >
> >
> >
> > On Thu, Feb 23, 2012 at 11:58, Sammy Govind <govoiper at gmail.com> wrote:
> >
> >> Reading from the module docs its clear why it needs to engage media/rtp
> >> proxy to start,stop billing or timer of a call. so what happens when it
> >> engages mediaproxy on unwanted calls !? audio-issues?
> >>
> >>
> >> On Thu, Feb 23, 2012 at 1:21 PM, Reda Aouad <reda.aouad at gmail.com>
> wrote:
> >>
> >>> Thanks Sammy. I didn't get any reply yet.
> >>>
> >>> CallControl is an application used with CDRTool for prepaid calls. It
> >>> calculates the maximum call duration based on the user's balance. Once
> the
> >>> call's duration limit is reached, it sends BYE to both calling parties,
> >>> terminating the call. At the end of a prepaid call, terminated either
> by
> >>> the user or by CallControl, it debits the user's balance according to
> the
> >>> call's duration.
> >>>
> >>> The Call_Control module interfaces with this external application.
> >>>
> >>> call_control function is called in Kamailio's cfg to check if the user
> >>> has prepaid or postpaid account, and get the max call duration for
> prepaid
> >>> users. CallControl controls only prepaid calls, not postpaid ones.
> >>>
> >>> So call control and NAT traversal using mediaproxy are two differents
> >>> things which i can't link, since I don't want mediaproxy for every
> call.
> >>> And since the function call_control is called on every invite before
> >>> knowing if the user has a prepaid account or not, it engages
> mediaproxy for
> >>> every call.
> >>>
> >>> CallControl relies on mediaproxy to detect RTP timeouts and debit the
> >>> correct balance from a prepaid account based on the last instant the
> >>> mediaproxy saw an RTP packet.
> >>>
> >>> But why to force using mediaproxy with no choice? And why to force it
> for
> >>> every call, whether it falls under CallControl's control or not?
> >>>
> >>> I am using Kamailio 3.2.
> >>>
> >>>
> >>> Reda
> >>>
> >>> On 23 févr. 2012, at 07:21, Sammy Govind <govoiper at gmail.com> wrote:
> >>>
> >>> Hi,
> >>> I can see you posting multiple times on both proxies listings so I'm
> sure
> >>> you havent heard back from anyone.I am not at all familiar with your
> >>> functions in email but could it be possible for you to determine on
> which
> >>> calls you need to engage mediaproxy and on which not to, then on the
> base
> >>> of that flag use the call_control function !
> >>> your problem is complicated for me atleast. I hope somebody could
> answer
> >>> you accurately and precisely.
> >>>
> >>> btw, what are you using in real? opensips or kamailio, which version?
> and
> >>> in what context you need to use the call_control function?
> >>>
> >>> Thanks,
> >>> Sammy
> >>>
> >>> On Thu, Feb 23, 2012 at 12:45 AM, Reda Aouad <reda.aouad at gmail.com
> >wrote:
> >>>
> >>>> Hi,
> >>>>
> >>>> When I use the function call_control( ) of the call_control module, it
> >>>> automatically engages mediaproxy if it finds the mediaproxy module
> loaded.
> >>>> If the mediaproxy module is not loaded, call_control doesn't even try
> to
> >>>> engage it.
> >>>>
> >>>> I need mediaproxy for NAT traversal in some cases, but don't want it
> to
> >>>> be engaged on every call.
> >>>>
> >>>> How can I disable this behavior?
> >>>>
> >>>> Thanks
> >>>> Reda
> >>>>
> >>>> _______________________________________________
> >>>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing
> list
> >>>> sr-users at lists.sip-router.org
> >>>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
> >>>>
> >>>>
> >>> _______________________________________________
> >>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
> >>> sr-users at lists.sip-router.org
> >>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
> >>>
> >>>
> >>> _______________________________________________
> >>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
> >>> sr-users at lists.sip-router.org
> >>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
> >>>
> >>>
> >>
> >> _______________________________________________
> >> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
> >> sr-users at lists.sip-router.org
> >> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
> >>
> >>
> > _______________________________________________
> > SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
> > sr-users at lists.sip-router.org
> > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20120223/4d72ab14/attachment-0001.htm>