[SR-Users] CallControl and MediaProxy

Fri Feb 24 19:56:22 CET 2012

It would be great Daniel if you could do it.
I will be more than happy to test it.
A function parameter would be more flexible than a module parameter.
I expect it shouldn't affect the behavior of the external application
CallControl.

Thanks in advance :)

Reda

On Fri, Feb 24, 2012 at 08:09, Daniel-Constantin Mierla
<miconda at gmail.com>wrote:

>  Hello,
>
> I am not using mediaproxy at all (but nathelper/rtpproxy), neither the
> call control module, but making an option (module parameter or function
> parameter) for call control to bind to another module like media proxy,
> should not be big deal if it is all you are looking for -- I can look over
> it and send a patch if you are going to help testing it. I cannot do it
> these days, though, being out of the office.
>
> Cheers,
> Daniel
>
>
> On 2/23/12 8:59 PM, Reda Aouad wrote:
>
>  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
>> >
>>
>>
>
>
> _______________________________________________
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing listsr-users at lists.sip-router.orghttp://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>
>
> --
> Daniel-Constantin Mierla -- http://www.asipto.comhttp://linkedin.com/in/miconda -- http://twitter.com/miconda
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20120224/19208501/attachment-0001.htm>