[Kamailio-Users] rtpproxy session is not automatically deleted if INVITE transaction fails?
Hi, I'm realizing that rtpproxy session is not automatically terminated when an outgoing INVITE transaction fails ([3456]XX response received from downstream), so the rtpproxy session dies after a while due to time expiration.
So I've added the following code to my on_reply_route:
------------ onreply_route[X] {
if is_method("INVITE") && status =~ "[3456][0-9][0-9]" unforce_rtp_proxy(); ------------
It seems to do the job. However I expected this to be done automatically by rtpproxy module when an INVITE transaction for which a rtpproxy session has been created fails.
Do I miss something? or is it the expected behavior?
Thanks a lot.
It is the expected behavior. You can do that on failure_route (if you arm one). And if you do redirection based on 3xx, there's no need to terminated the rtp session and start a new one.
Regards, Ovidiu Sas
On Wed, Jan 27, 2010 at 8:27 AM, Iñaki Baz Castillo ibc@aliax.net wrote:
El Miércoles, 27 de Enero de 2010, Ovidiu Sas escribió:
Good point. Terminating the rtpproxy session upon receipt of an error response would break the possibility of using serial forking (in failure_route) with the already opened rtpproxy session (anyhow I think it's better to invoke RtpProxy for each transaction serial/parallel fork).
However, IMHO it could be more user-friendly. In case the incoming transaction ends (when Kamailio replies [3456]XX to the UAC) then it makes no sense to leave the rtpproxy session open. Instead, rtpproxy module could terminate it (if it exists).
This is: I just mean the case in which Kamailio terminates the incoming transaction, but not the case in which a error response is got from downstream.
Opinnions? Thanks a lot.
On Wed, Jan 27, 2010 at 9:04 AM, Iñaki Baz Castillo ibc@aliax.net wrote:
In most of this cases (if not all) the rtp session should not be opened. I like the way it is because I know exactly what's going on (no under the hood decisions). If a session is not closed, I know who to blame ;)
Regards, Ovidiu Sas
El Miércoles, 27 de Enero de 2010, Ovidiu Sas escribió:
In most of this cases (if not all) the rtp session should not be opened.
Well, the case is that when invoking force_rtpproxy() for the INVITE, RtpProxy already allocates 2 file descriptors (UDP sockets for RTP and RTCP) so we can get into ulimits problems.
Hello All!
2010/1/27 Iñaki Baz Castillo ibc@aliax.net:
Yes, that's correct.
Unfortunately, yes. To be able to close rtp session automatically, you need exlplicitly watch call state (with dialog module, for example), and that can be considered as a performance loss.
This is the expected behaviour, but seems different from how the mediaproxy module handles the issue.
On 01/27/2010 08:27 AM, Iñaki Baz Castillo wrote:
On 1/27/10 9:19 PM, Alex Balashov wrote:
this the behavior from beginning of nathelper/rtpproxy. The default config for 1.5 and 3.0 has it in failure_route. You can use it pretty much standalone, without constraints to modules such as tm, in case you want to have a media relay (required sometimes for interconnection). nathelper dependency on usrloc is for natpinging and user's sip nat traversal.
Cheers, Daniel
-
Alex Balashov -
Daniel-Constantin Mierla -
Iñaki Baz Castillo -
jh＠tutpro.com -
Ovidiu Sas -
Peter Lemenkov