[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:
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.
-- Iñaki Baz Castillo ibc@aliax.net
Kamailio (OpenSER) - Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
El Miércoles, 27 de Enero de 2010, Ovidiu Sas escribió:
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.
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:
El Miércoles, 27 de Enero de 2010, Ovidiu Sas escribió:
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.
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.
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:
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();
Yes, that's correct.
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?
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:
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.
On 1/27/10 9:19 PM, Alex Balashov wrote:
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:
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?
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