7 Jul
2009
7 Jul
'09
6:36 p.m.
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(a)gmail.com>om>:
ok, that sounds really nice :)
--
Alex Balashov
Evariste Systems
Web : http://www.evaristesys.com/
Tel : (+1) (678) 954-0670
Direct : (+1) (678) 954-0671
Mobile : (+1) (678) 237-1775
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.