[SR-Users] Mitigation of unavailable rtpproxy
miconda at gmail.com
Wed Nov 6 20:03:42 CET 2013
On 11/6/13 2:58 PM, Alex Balashov wrote:
> On 11/06/2013 08:45 AM, Daniel-Constantin Mierla wrote:
>> there are some parameters to control the timeout+retries for waiting a
>> reply from rtpproxy:
>> 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?
iirc, yes, each command has a reply. You can put the control socket on
udp/network and use ngrep for a quick check.
> 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.
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 -
More information about the sr-users