On 11/06/2013 02:03 PM, Daniel-Constantin Mierla wrote:
On 11/6/13 2:58 PM, Alex Balashov wrote:
- 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