2009/7/7 Daniel-Constantin Mierla <miconda(a)gmail.com>om>:
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.
Hi Daniel, please clarify me is your suggestion would require running
(in the config script) the function rtpproxy_session_update() in
onreply_route.
If this info is not appended to the transaction info (so doesn't use
TM module) then it should be manually invoked in onreply_route, right?
What I suggested is that the rtpproxy function is just invoked for the
request, it adds some info to the transaction so rtpproxy is also
invoked in the response/ACK.
However, I think that nathelper should perform in a transparent way
the detection of SDP so it wouldn't be required to inspect the body
type in the config file (which makes it really ugly).
Regards.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>