Having a single function per transaction to deal with rtpproxy sessions has some issues. Let's imagine the following scenario: - sip-router is used in bridged mode; - rtpproxy is configured in bridged mode.
Let's assume that a call is made from the internal interface to the external one. Proper flags needs to be set in order to have a correct RTP bridging. Now, if the call fails and it needs to be redirected back into the internal network, the flags needs to be updated and this it defeats the purpose of having a new single function to be invoked per transaction.
Mediaproxy doesn't have this issue because it doesn't have support for bridging.
Regards, Ovidiu Sas
On Thu, Sep 23, 2010 at 12:04 PM, Juha Heinanen jh@tutpro.com wrote:
Ovidiu Sas writes:
Without using the dialog module, it will be difficult to keep track of the rtpproxy session for the duration of the call.
what do you mean? use_mediaproxy for invites and re-invites plus end_media_session have worked fine for me.
It can be tracked for the duration of the transaction and in this case we could have: - use_rtp_proxy: for the creation of the rtpproxy session; - update_rtp_proxy: for updating an rtpproxy session for an in-dialog request; - end_rtp_session is just like unforce_rtp_proxy.
those names sound ok to me.
-- juha