16 May
2011
16 May
'11
9:59 a.m.
Am 13.05.2011 18:10, schrieb Asgaroth:
If you do not use DB-storage on the outboundproxy I think the CRLF
pinging should be quite lightweight.
Hi Klaus,
On 13/05/2011, Klaus Darilion <klaus.mailinglists(a)pernau.at> wrote:
Actually I have not tried it. Thus, if it does not work, you should open
a bug report.
Sending OPTIONS/INFO keep-alives should be
possible from the registrar.
Sending just CRLF for keep-alive can only be done by the outboundproxy.
How would I achieve this from the registrar? This would be ideal for
me, if I could have the registrar that serviced the register request
to also maintain the nat keepalive messages? I'm not sure how the
nathelper module derives the route to send the OPTIONS/INFO message to
the outbound registrar. I would have thought that it would use the
path information stored in the usrloc table but it does not appear to
do that. You could save() the REGISTER before forwarding
to the REGISTRAR (or in
a reply route if response=200 OK) and set the natping flag before.
If I save the register at the proxy, then that would defeat the
purpose of the registrar server. I am trying to offload registration
processing onto seperare registrar servers. If I set the natping flag in the reply route, do I
still need to save
the registration informaiton on the proxy? Or do you mean that I can
forward the register requests over to the registrar servers, then look
for a 200 OK to the REGISTER and only set the natping flag then? If
Doing it in the response may cause problems if the response contains
multiple contact headers. Also you have to call fix_nated_register() in
request route to store the socket from where the REGISTER was received.
this is true, I would then also need to look for the
REGISTER with
expires=0 for an unregistration so that I can disable the natping flag
then as well.
True. Or just ping de-registered contact until the contact is expired.
regards
klaus