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.

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?