I'm trying to figure out if there is some way to identify a call for which an rtpproxy session has been set up when the call is cancelled.
I can't check the flag I set for the call, nor can I check the route param I set (which is what I'm doing to figure out when to unforce the media stream for a BYE).
If this is not possible, is there any danger in calling unforce_rtp_proxy() for all calls, regardless of whether media proxying has been set up for the call or not?
On 23.11.2010 21:22, Joe Hart wrote:
I'm trying to figure out if there is some way to identify a call for which an rtpproxy session has been set up when the call is cancelled.
I can't check the flag I set for the call, nor can I check the route param I set (which is what I'm doing to figure out when to unforce the media stream for a BYE).
If this is not possible, is there any danger in calling unforce_rtp_proxy() for all calls, regardless of whether media proxying has been set up for the call or not?
No. Just call it for every CANCEL as in the default config.
klaus
On 11/24/2010 03:37 AM, Klaus Darilion wrote:
On 23.11.2010 21:22, Joe Hart wrote:
I'm trying to figure out if there is some way to identify a call for which an rtpproxy session has been set up when the call is cancelled.
I can't check the flag I set for the call, nor can I check the route param I set (which is what I'm doing to figure out when to unforce the media stream for a BYE).
If this is not possible, is there any danger in calling unforce_rtp_proxy() for all calls, regardless of whether media proxying has been set up for the call or not?
No. Just call it for every CANCEL as in the default config.
What about calling it for any other request for which rtpproxy has not first been engaged? Isn't there any possibility of port collisions, for large amounts of calls flowing between the same endpoints?
-
Alex Balashov -
Joe Hart -
Klaus Darilion