[SR-Users] CallControl and MediaProxy
Daniel-Constantin Mierla
miconda at gmail.com
Mon Feb 27 17:46:21 CET 2012
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
> <mailto: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 <mailto: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 <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 <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/20120227/1b481fe6/attachment-0001.htm>
More information about the sr-users
mailing list