6 Nov
2013
6 Nov
'13
2:03 p.m.
On 11/6/13 2:58 PM, Alex Balashov wrote:
On 11/06/2013 08:45 AM, Daniel-Constantin Mierla
wrote:
iirc, yes, each command has a reply. You can put the control socket on
udp/network and use ngrep for a quick check.
there are some parameters to control the
timeout+retries for waiting a
reply from rtpproxy:
http://kamailio.org/docs/modules/stable/modules/rtpproxy.html#idp15243344
Looking it the code, it seems the value for timeout parameter is sec,
but could be easily made miliseconds, because the function used inside
is poll() which takes timeout as milisec.
Thank you, Daniel.
1. So, am I right to assume that the unforce_rtp_proxy() call waits
for timeout and blocks the worker while doing so?
2. Is there any harm in calling unforce_rtp_proxy() for Call-IDs
rtpproxy doesn't know about? is there a 'better' best practice for
handling CANCELs where it is unknown whether rtpproxy was engaged on
the initial call (because it is an option, nat_uac_detect, etc)?
No, it is no harm
to call rtpproxy for non-existing sessions. You can
even skip it, there is a session timeout in rtpproxy -- I don't know
default value, but probably can be set via command line parameter -- so
if you are not short in ports, you can just leave rtpproxy alone with
closed calls without calling unforce command.
Cheers,
Daniel
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Trainings - Berlin, Nov 25-28
- more details about Kamailio trainings at http://www.asipto.com -