<div dir="ltr"><font color="#3366ff"><font><font face="tahoma,sans-serif">I looked in detail in the source of the call control module and didn't find anything related to the mediaproxy module neither..</font></font></font><div>
<div dir="ltr"><font color="#3366ff" face="tahoma, sans-serif">I'll send you the output of cfgtrace soon.</font></div><div dir="ltr"><font color="#3366ff" face="tahoma, sans-serif"><br></font><div><font color="#3366ff" face="tahoma, sans-serif">Reda</font></div>
</div><br>
<br><br><div class="gmail_quote">On Fri, Feb 24, 2012 at 23:46, Daniel-Constantin Mierla <span dir="ltr"><<a href="mailto:miconda@gmail.com">miconda@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
A quick grep over the callcontrol sources didn't reveal a point
where mediaproxy is engaged.<br>
<br>
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?<br>
<br>
Cheers,<br>
Daniel<div><div class="h5"><br>
<br>
On 2/24/12 7:56 PM, Reda Aouad wrote:
<blockquote type="cite">
<div dir="ltr"><font color="#3366ff"><font><font face="tahoma,sans-serif">It would be great Daniel if you
could do it.</font></font></font>
<div><font color="#3366ff"><font><font face="tahoma,sans-serif">I
will be more than happy to test it.</font></font></font></div>
<div><font color="#3366ff"><font><font face="tahoma,sans-serif">A
function parameter would be more flexible than a module
parameter.</font></font></font></div>
<div><font color="#3366ff" face="tahoma, sans-serif">I expect it
shouldn't affect the behavior of the external application
CallControl.<br>
</font>
<div><font color="#3366ff"><font><font face="tahoma,sans-serif"><br>
</font></font></font></div>
<div><font color="#3366ff"><font><font face="tahoma,sans-serif">Thanks in advance :)</font></font></font></div>
<div>
<div dir="ltr">
<font color="#3366ff" face="tahoma, sans-serif"><br>
</font>
<div><font color="#3366ff" face="tahoma, sans-serif">Reda</font></div>
</div>
<br>
<br>
<br>
<div class="gmail_quote">On Fri, Feb 24, 2012 at 08:09,
Daniel-Constantin Mierla <span dir="ltr"><<a href="mailto:miconda@gmail.com" target="_blank">miconda@gmail.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF"> Hello,<br>
<br>
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.<br>
<br>
Cheers,<br>
Daniel
<div>
<div><br>
<br>
On 2/23/12 8:59 PM, Reda Aouad wrote:
<blockquote type="cite">
<div dir="ltr">
<div><font color="#3366ff"><font><font face="tahoma,sans-serif">First, I am
posting about the wrong behavior of
CallControl (or most probably Kamailio
modules) which leaves no option. </font></font></font><span style="color:rgb(51,102,255);font-family:tahoma,sans-serif">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.</span></div>
<div><font color="#3366ff"><font><font face="tahoma,sans-serif"><br>
</font></font></font></div>
<div><font color="#3366ff"><font><font face="tahoma,sans-serif">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.</font></font></font></div>
<div><font color="#3366ff"><font><font face="tahoma,sans-serif"><br>
</font></font></font></div>
<div><span style="color:rgb(51,102,255);font-family:tahoma,sans-serif">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.</span></div>
<div><span style="color:rgb(51,102,255);font-family:tahoma,sans-serif"><br>
</span></div>
<div><span style="color:rgb(51,102,255);font-family:tahoma,sans-serif">MY
POINT IS : </span><span style="color:rgb(51,102,255);font-family:tahoma,sans-serif">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.</span></div>
<div><font color="#3366ff"><font><font face="tahoma,sans-serif"><br>
</font></font></font></div>
<div><font color="#3366ff"><font><font face="tahoma,sans-serif">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.</font></font></font></div>
<div><font color="#3366ff"><font><font face="tahoma,sans-serif"><br>
</font></font></font></div>
<div><font color="#3366ff"><font><font face="tahoma,sans-serif">This is an
extract from the call_control module :</font></font></font></div>
<div><font color="#3366ff"><font><font face="tahoma,sans-serif"><br>
</font></font></font></div>
<blockquote style="margin:0 0 0 40px;border:none;padding:0px">
<div><span style="text-align:justify;font-size:12px;font-family:Helvetica,Arial">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.</span></div>
<div>
<div><font color="#3366ff" face="tahoma,
sans-serif"><br>
</font></div>
</div>
</blockquote>
<div>
<div dir="ltr">
<div><font color="#3366ff" face="tahoma,
sans-serif"><br>
</font></div>
<div><font color="#3366ff" face="tahoma,
sans-serif">Unless there is something
I miss..</font></div>
<div><font color="#3366ff" face="tahoma,
sans-serif"><br>
</font></div>
<div><font color="#3366ff" face="tahoma,
sans-serif">I also opened a bug about
the issue because call_control doesn't
have the same behavior with OpenSips.
It doesn't force mediaproxy.</font></div>
<div><font color="#3366ff" face="tahoma,
sans-serif"><br>
</font></div>
<div><font color="#3366ff" face="tahoma,
sans-serif">Reda</font></div>
</div>
<br>
<br>
<br>
<div class="gmail_quote">On Thu, Feb 23,
2012 at 20:00, Jeff Brower <span dir="ltr"><<a href="mailto:jbrower@signalogic.com" target="_blank">jbrower@signalogic.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Reda-<br>
<div><br>
> It's clear but not necessary. It
can look at radius records fixed by<br>
> mediaproxy on RTP timeout to
debit the correct balance as well. And
why<br>
> also force it on postpaid calls
which it doesn't control at all ?<br>
<br>
</div>
I don't understand how you plan to tear
down Kamailio calls that suffer RTP
time-out?<br>
<span><font color="#888888"><br>
-Jeff<br>
</font></span>
<div>
<div><br>
> What happens is cost and
performance issues for additional
calls passing<br>
> through my mediaproxy server,
which I didn't plan for at first. No
audio<br>
> issue at all.<br>
><br>
> Reda<br>
><br>
><br>
><br>
> On Thu, Feb 23, 2012 at 11:58,
Sammy Govind <<a href="mailto:govoiper@gmail.com" target="_blank">govoiper@gmail.com</a>>
wrote:<br>
><br>
>> Reading from the module
docs its clear why it needs to
engage media/rtp<br>
>> proxy to start,stop billing
or timer of a call. so what happens
when it<br>
>> engages mediaproxy on
unwanted calls !? audio-issues?<br>
>><br>
>><br>
>> On Thu, Feb 23, 2012 at
1:21 PM, Reda Aouad <<a href="mailto:reda.aouad@gmail.com" target="_blank">reda.aouad@gmail.com</a>>
wrote:<br>
>><br>
>>> Thanks Sammy. I didn't
get any reply yet.<br>
>>><br>
>>> CallControl is an
application used with CDRTool for
prepaid calls. It<br>
>>> calculates the maximum
call duration based on the user's
balance. Once the<br>
>>> call's duration limit
is reached, it sends BYE to both
calling parties,<br>
>>> terminating the call.
At the end of a prepaid call,
terminated either by<br>
>>> the user or by
CallControl, it debits the user's
balance according to the<br>
>>> call's duration.<br>
>>><br>
>>> The Call_Control module
interfaces with this external
application.<br>
>>><br>
>>> call_control function
is called in Kamailio's cfg to check
if the user<br>
>>> has prepaid or postpaid
account, and get the max call
duration for prepaid<br>
>>> users. CallControl
controls only prepaid calls, not
postpaid ones.<br>
>>><br>
>>> So call control and NAT
traversal using mediaproxy are two
differents<br>
>>> things which i can't
link, since I don't want mediaproxy
for every call.<br>
>>> And since the function
call_control is called on every
invite before<br>
>>> knowing if the user has
a prepaid account or not, it engages
mediaproxy for<br>
>>> every call.<br>
>>><br>
>>> CallControl relies on
mediaproxy to detect RTP timeouts
and debit the<br>
>>> correct balance from a
prepaid account based on the last
instant the<br>
>>> mediaproxy saw an RTP
packet.<br>
>>><br>
>>> But why to force using
mediaproxy with no choice? And why
to force it for<br>
>>> every call, whether it
falls under CallControl's control or
not?<br>
>>><br>
>>> I am using Kamailio
3.2.<br>
>>><br>
>>><br>
>>> Reda<br>
>>><br>
>>> On 23 févr. 2012, at
07:21, Sammy Govind <<a href="mailto:govoiper@gmail.com" target="_blank">govoiper@gmail.com</a>>
wrote:<br>
>>><br>
>>> Hi,<br>
>>> I can see you posting
multiple times on both proxies
listings so I'm sure<br>
>>> you havent heard back
from anyone.I am not at all familiar
with your<br>
>>> functions in email but
could it be possible for you to
determine on which<br>
>>> calls you need to
engage mediaproxy and on which not
to, then on the base<br>
>>> of that flag use the
call_control function !<br>
>>> your problem is
complicated for me atleast. I hope
somebody could answer<br>
>>> you accurately and
precisely.<br>
>>><br>
>>> btw, what are you using
in real? opensips or kamailio, which
version? and<br>
>>> in what context you
need to use the call_control
function?<br>
>>><br>
>>> Thanks,<br>
>>> Sammy<br>
>>><br>
>>> On Thu, Feb 23, 2012 at
12:45 AM, Reda Aouad <<a href="mailto:reda.aouad@gmail.com" target="_blank">reda.aouad@gmail.com</a>>wrote:<br>
>>><br>
>>>> Hi,<br>
>>>><br>
>>>> When I use the
function call_control( ) of the
call_control module, it<br>
>>>> automatically
engages mediaproxy if it finds the
mediaproxy module loaded.<br>
>>>> If the mediaproxy
module is not loaded, call_control
doesn't even try to<br>
>>>> engage it.<br>
>>>><br>
>>>> I need mediaproxy
for NAT traversal in some cases, but
don't want it to<br>
>>>> be engaged on every
call.<br>
>>>><br>
>>>> How can I disable
this behavior?<br>
>>>><br>
>>>> Thanks<br>
>>>> Reda<br>
>>>><br>
>>>>
_______________________________________________<br>
>>>> SIP Express Router
(SER) and Kamailio (OpenSER) -
sr-users mailing list<br>
>>>> <a href="mailto:sr-users@lists.sip-router.org" target="_blank">sr-users@lists.sip-router.org</a><br>
>>>> <a href="http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users" target="_blank">http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users</a><br>
>>>><br>
>>>><br>
>>>
_______________________________________________<br>
>>> SIP Express Router
(SER) and Kamailio (OpenSER) -
sr-users mailing list<br>
>>> <a href="mailto:sr-users@lists.sip-router.org" target="_blank">sr-users@lists.sip-router.org</a><br>
>>> <a href="http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users" target="_blank">http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users</a><br>
>>><br>
>>><br>
>>>
_______________________________________________<br>
>>> SIP Express Router
(SER) and Kamailio (OpenSER) -
sr-users mailing list<br>
>>> <a href="mailto:sr-users@lists.sip-router.org" target="_blank">sr-users@lists.sip-router.org</a><br>
>>> <a href="http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users" target="_blank">http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users</a><br>
>>><br>
>>><br>
>><br>
>>
_______________________________________________<br>
>> SIP Express Router (SER)
and Kamailio (OpenSER) - sr-users
mailing list<br>
>> <a href="mailto:sr-users@lists.sip-router.org" target="_blank">sr-users@lists.sip-router.org</a><br>
>> <a href="http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users" target="_blank">http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users</a><br>
>><br>
>><br>
>
_______________________________________________<br>
> SIP Express Router (SER) and
Kamailio (OpenSER) - sr-users
mailing list<br>
> <a href="mailto:sr-users@lists.sip-router.org" target="_blank">sr-users@lists.sip-router.org</a><br>
> <a href="http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users" target="_blank">http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users</a><br>
><br>
<br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
<br>
<fieldset></fieldset>
<br>
<pre>_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
<a href="mailto:sr-users@lists.sip-router.org" target="_blank">sr-users@lists.sip-router.org</a>
<a href="http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users" target="_blank">http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users</a>
</pre>
</blockquote>
<br>
</div>
</div>
<span><font color="#888888">
<pre cols="72">--
Daniel-Constantin Mierla -- <a href="http://www.asipto.com" target="_blank">http://www.asipto.com</a>
<a href="http://linkedin.com/in/miconda" target="_blank">http://linkedin.com/in/miconda</a> -- <a href="http://twitter.com/miconda" target="_blank">http://twitter.com/miconda</a></pre>
</font></span></div>
</blockquote>
</div>
<br>
</div>
</div>
</div>
<br>
<fieldset></fieldset>
<br>
<pre>_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
<a href="mailto:sr-users@lists.sip-router.org" target="_blank">sr-users@lists.sip-router.org</a>
<a href="http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users" target="_blank">http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users</a>
</pre>
</blockquote>
<br>
<pre cols="72">--
Daniel-Constantin Mierla -- <a href="http://www.asipto.com" target="_blank">http://www.asipto.com</a>
<a href="http://linkedin.com/in/miconda" target="_blank">http://linkedin.com/in/miconda</a> -- <a href="http://twitter.com/miconda" target="_blank">http://twitter.com/miconda</a></pre>
</div></div></div>
</blockquote></div><br></div></div>