On 07/07/2009 06:36 PM, Alex Balashov wrote:
I somewhat object to the idea that rtpproxy control
socket functions
should be exposed in the nathelper module.
maybe there was some misunderstanding. What we discussed here is not
when to use rtpproxy, but if you do it for initial invite, then all
subsequent requests in the dialog will be automatically handled.
When and why one does rtp relaying is still a decision of the script
writer. From this perspective, maybe suggested name for RR parameter is
not the best, should be something "rtpp=yes".
Cheers,
Daniel
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>:
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 :)
--
Daniel-Constantin Mierla
http://www.asipto.com/