12 Oct
2010
12 Oct
'10
6:58 p.m.
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(a)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