<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body 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<br>
<br>
On 2/23/12 8:59 PM, Reda Aouad wrote:
<blockquote
cite="mid:CAA30pc5HMbXHw9kQyDde72-O-KDtm=davvYhe8t3UzcTkiaXTA@mail.gmail.com"
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="font-family:Helvetica,Arial;font-size:12px;text-align:justify;background-color:rgb(255,255,255)">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 moz-do-not-send="true"
href="mailto:jbrower@signalogic.com">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 class="im"><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 class="HOEnZb"><font color="#888888"><br>
-Jeff<br>
</font></span>
<div class="HOEnZb">
<div class="h5"><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
moz-do-not-send="true"
href="mailto:govoiper@gmail.com">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 moz-do-not-send="true"
href="mailto:reda.aouad@gmail.com">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 moz-do-not-send="true"
href="mailto:govoiper@gmail.com">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 moz-do-not-send="true"
href="mailto:reda.aouad@gmail.com">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 moz-do-not-send="true"
href="mailto:sr-users@lists.sip-router.org">sr-users@lists.sip-router.org</a><br>
>>>> <a moz-do-not-send="true"
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 moz-do-not-send="true"
href="mailto:sr-users@lists.sip-router.org">sr-users@lists.sip-router.org</a><br>
>>> <a moz-do-not-send="true"
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 moz-do-not-send="true"
href="mailto:sr-users@lists.sip-router.org">sr-users@lists.sip-router.org</a><br>
>>> <a moz-do-not-send="true"
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 moz-do-not-send="true"
href="mailto:sr-users@lists.sip-router.org">sr-users@lists.sip-router.org</a><br>
>> <a moz-do-not-send="true"
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 moz-do-not-send="true"
href="mailto:sr-users@lists.sip-router.org">sr-users@lists.sip-router.org</a><br>
> <a moz-do-not-send="true"
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 class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:sr-users@lists.sip-router.org">sr-users@lists.sip-router.org</a>
<a class="moz-txt-link-freetext" href="http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users">http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users</a>
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Daniel-Constantin Mierla -- <a class="moz-txt-link-freetext" href="http://www.asipto.com">http://www.asipto.com</a>
<a class="moz-txt-link-freetext" href="http://linkedin.com/in/miconda">http://linkedin.com/in/miconda</a> -- <a class="moz-txt-link-freetext" href="http://twitter.com/miconda">http://twitter.com/miconda</a></pre>
</body>
</html>