7 Nov
2013
7 Nov
'13
10:48 a.m.
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/