2009/7/7 Daniel-Constantin Mierla miconda@gmail.com:
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.