28 Jan
2010
28 Jan
'10
1:16 a.m.
On Wed, Jan 27, 2010 at 9:04 AM, Iñaki Baz Castillo <ibc(a)aliax.net> wrote:
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.
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
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.