[SR-Users] Mitigation of unavailable rtpproxy

[Daniel-Constantin Mierla]

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:
>>
>> 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?

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.

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 -