I somewhat object to the idea that rtpproxy control socket functions should be exposed in the nathelper module. Why does mediaproxy get its own module? What if I want to relay media for some purpose other than far-end NAT traversal (for example, passive in-line tap / monitor-port based call recording)?
Iñaki Baz Castillo wrote:
2009/7/7 Daniel-Constantin Mierla miconda@gmail.com:
Hi Daniel, please clarify me is your suggestion would require running (in the config script) the function rtpproxy_session_update() in onreply_route.
no. The script needs just rtpproxy_session_init(). All the rest is done automatically in the module.
Inside a module, you can register functions that are executed before executing the configuration file for each sip message.
So, here is what is needed:
- registers callback functions for pre-script event for reply and request
- if it is an initial invite, then skip processing in the callback
- if it is a reply or a in-dialog request, search for Record-Route/Route
headers matching "myself"
- if the R-R/R headers have "nat=xyz", then process
rtpproxy_session_update()
- export to config file the function rtpproxy_session_init() that has to be
called for initial invite and append to R-R the parameter "nat=xyz" (this should be configurable)
In the config file, just call rtpproxy_session_init() and that is. Probably this function needs some flags as parameter to control the behaviour, flags that could be added as value to nat parameter, if needed later.
ok, that sounds really nice :)