[SR-Users] CallControl and MediaProxy

Reda Aouad reda.aouad at gmail.com
Mon Feb 27 21:32:35 CET 2012


I looked into mediaproxy.c and found the following :

-------------------------------------------------------
#define FL_USE_MEDIA_PROXY (1<<30)

...

# dialog callback

__dialog_created (...) {
        ....
        if ((request->msg_flags & FL_USE_MEDIA_PROXY) == 0)
                return;
         ....
        use_media_proxy (...);
}
-------------------------------------------------------


I also found this in call_control.c
-------------------------------------------------------
#define FL_USE_CALL_CONTROL       (1<<30)

# Public API
CallControl (...) {
        ...
        msg->msg_flags |= FL_USE_CALL_CONTROL;
        ...
}
-------------------------------------------------------

So I suspect that since the call_control module uses the same flag as the
mediaproxy module, call_control function is used, flag 30 is set, and the
following condition in the __dialog_created callback function above is
never met

        (request->msg_flags & FL_USE_MEDIA_PROXY) == 0

so the callback function continues until executing its last line :
use_media_proxy (...)
which is called on every call to call_control ( ) function..

Reda



On Mon, Feb 27, 2012 at 18:39, Reda Aouad <reda.aouad at gmail.com> wrote:

> Ok thanks Daniel.
>
> I'll do what you suggested and we'll see how to proceed.
>
> Thanks again
> Reda
>
> On 27 févr. 2012, at 17:46, Daniel-Constantin Mierla <miconda at gmail.com>
> wrote:
>
> Hello,
>
> On 2/26/12 11:01 AM, Reda Aouad wrote:
>
> Daniel, I sent you the log file by private email, for privacy concerns.
>
> ok, no time yet to look over them, but as you say it does not call
> mediaproxy explicitely from config and callcontrol, maybe you should look
> inside mediaproxy module, might be automatically executed on dialog or tm
> module callbacks -- then the patch has to be done for mediaproxy module.
>
>  I took a quick look at the log files, and didn't see any call to
> mediaproxy module.
>
>  Though, the mediaproxy log file indicates a media session engaged, and
> CDRTool shows media information for the established session.
>
>  The mediaproxy module is loaded, but no function from the module is
> called at all.
>
> It can be via some internal callbacks registered to some modules such as
> tm and dialog, or even script execution callbacks... so look over the code
> of mediaproxy module. You can run kamailio with debug=3 and from the logs
> you should get some hints about what is the way media proxy is executed.
>
> Cheers,
> Daniel
>
>
>  Thanks
>  Reda
>
>
>
> On Sat, Feb 25, 2012 at 18:58, Reda Aouad <reda.aouad at gmail.com> wrote:
>
>> I looked in detail in the source of the call control module and didn't
>> find anything related to the mediaproxy module neither..
>> I'll send you the output of cfgtrace soon.
>>
>>  Reda
>>
>>
>>
>> On Fri, Feb 24, 2012 at 23:46, Daniel-Constantin Mierla <
>> miconda at gmail.com> wrote:
>>
>>>  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> 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
>>>>
>>>>
>>>
>>>
>>> _______________________________________________
>>> 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
>>>
>>>
>>
>
>
> _______________________________________________
> 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/20120227/3343bf38/attachment-0001.htm>


More information about the sr-users mailing list