[SR-Users] Mitigation of unavailable rtpproxy

[Alex Balashov]

On 11/06/2013 02:03 PM, Daniel-Constantin Mierla wrote:

> On 11/6/13 2:58 PM, Alex Balashov wrote:

>> 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.

And, in the rtpproxy control protocol, the sessions are keyed by SIP 
Call-ID, right, not by tuples of IP endpoints and RTP ports?  That is to 
say, there's no danger of stopping an existing conversation this way 
(assuming the Call-IDs are reasonable GUIDs and all that)?

-- Alex

-- 
Alex Balashov - Principal
Evariste Systems LLC
235 E Ponce de Leon Ave
Suite 106
Decatur, GA 30030
United States
Tel: +1-678-954-0670
Web: http://www.evaristesys.com/, http://www.alexbalashov.com/