7 Jul
2009
7 Jul
'09
4:34 p.m.
On 07/07/2009 03:19 PM, Iñaki Baz Castillo wrote:
2009/7/7 Klaus Darilion
<klaus.mailinglists(a)pernau.at>at>:
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
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)
(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.
--
Daniel-Constantin Mierla
http://www.asipto.com/