25 Feb
2012
25 Feb
'12
12:46 a.m.
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(a)gmail.com <mailto:miconda@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:
--
Daniel-Constantin Mierla -- http://www.asipto.com
http://linkedin.com/in/miconda -- http://twitter.com/miconda
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(a)signalogic.com <mailto:jbrower@signalogic.com>> wrote:
Reda-
--
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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users 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(a)gmail.com
<mailto:govoiper@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(a)gmail.com
<mailto:reda.aouad@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(a)gmail.com
<mailto:govoiper@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(a)gmail.com <mailto:reda.aouad@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(a)lists.sip-router.org
<mailto:sr-users@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(a)lists.sip-router.org
<mailto:sr-users@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(a)lists.sip-router.org
<mailto:sr-users@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(a)lists.sip-router.org
<mailto:sr-users@lists.sip-router.org>
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users
mailing list
sr-users(a)lists.sip-router.org
<mailto:sr-users@lists.sip-router.org>
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org <mailto:sr-users@lists.sip-router.org>
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users