On 07/07/2009 03:19 PM, IƱaki Baz Castillo wrote:
2009/7/7 Klaus Darilion klaus.mailinglists@pernau.at:
If would be really great a rtpproxy function working for transaction (instead of working for each message). For example:
if (is_method("INVITE")) { tran_use_rtpproxy(FLAGS); }
In this case you can use mediaproxy or someone have to change the rtpproxy module to rely on dialog module to get information about session updates (as mediaproxy module does)
No, I don't want it based on dialog module
I second this one, it will add pretty much overload.
However, it can be very simple, even without tm support. If calling like rtpproxy_session_init() adds a nat=yes in the Record-Route, all processing can be done in rtpproxy_session_update() by discovery of that parameter or not.
rtpproxy_sessipn_update() can be done automatically by registering pre-script callbacks for requests and replies, so the config file will become very simple. It is not something complex to implement, just some spare time, the code is there, needs some re-structuring in new functions.
There will be a dependency on rr module, but I guess that is fine.
Cheers, Daniel
(as Mediaproxy offers) since dialgo module has a great limitation: it doesn't handle the case in which various early-dialogs occur, and perhaps rtp/media-proxy is just required for natted branches. This is not possible with "engage_mediaproxy()" function.
What I mean is a *transaction* based function, so "tran_use_rtpproxy()" just should be invoked during initial INVITE request (not in responses, ACK or CANCEL), re-INVITE and BYE.