[SR-Users] CallControl and MediaProxy
Daniel-Constantin Mierla
miconda at gmail.com
Fri Feb 24 23:46:14 CET 2012
A quick grep over the callcontrol sources didn't reveal a point where
mediaproxy is engaged.
Can you load debugger module and enable cfgtrace, then run such a
scenario and send out the output from cfgtrace to see all the config
actions executed?
Cheers,
Daniel
On 2/24/12 7:56 PM, Reda Aouad wrote:
> 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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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
>> <mailto: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
>> <mailto: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
>> <mailto: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
>> <mailto: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
>> <mailto: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 <mailto:sr-users at lists.sip-router.org>
>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>
> --
> Daniel-Constantin Mierla --http://www.asipto.com
> http://linkedin.com/in/miconda -- http://twitter.com/miconda
>
>
>
>
> _______________________________________________
> 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
--
Daniel-Constantin Mierla -- http://www.asipto.com
http://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/46aa2f28/attachment-0001.htm>
More information about the sr-users
mailing list