7 Jul
2009
7 Jul
'09
4:55 p.m.
Hello Inaki,
On 07/07/2009 03:42 PM, 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.
Cheers,
Daniel
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.
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.
--
Daniel-Constantin Mierla
http://www.asipto.com/