I have one answer on the subscribe. The sip_cfg setting allowsubscribe is set to false <br>on a reload. When one of the peers has allowsubscribe on then de sip_cfg is changed<br>to true. When in between a reload and a subscribe no requests are done the subscribe <br>
will indeed fail with the reason Forbidden (policy). <br><br><div class="gmail_quote">2010/3/10 Leif Madsen <span dir="ltr"><<a href="mailto:leif.madsen@asteriskdocs.org">leif.madsen@asteriskdocs.org</a>></span><br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="im">Ron Arts wrote:<br>
> I am planning on writing a patch to refresh the realtime cache<br>
> after a sip reload, but maybe I'm doing the wrong thing here.<br>
><br>
</div><div class="im">> Now. What I'd like to do is:<br>
><br>
> 1. ensure that a SUBSCRIBE message from a phone fills the realtime<br>
> cache, so the subscribe succeeds<br>
> 2. somehow ensure that after a sip reload the entire cache is refreshed<br>
> so that qualifying keeps happening.<br>
><br>
> Is this stupid for some reason? Did I miss something?<br>
<br>
</div>I'm sure there is a reason this is they way it is, and that a developer will<br>
enlighten us as to why this is the case, but I agree that it'd be nice to not<br>
require the phones to re-register to get put back in the cache with realtime<br>
after a sip reload.<br>
<br>
I'm not sure I'd go the route of refreshing the cache after a sip reload (i.e.<br>
clearing the cache, then trying to load all the information back into memory<br>
from the database) -- I have a vague recollection of a reason why this was not<br>
possible.<br>
<br>
However, maybe it would be easier to implement a system that simply doesn't<br>
remove the entries from memory upon a reload? Without knowing anything about the<br>
core code, and only about the implementation of realtime, I'm not sure if this<br>
is an appropriate route either.<br>
<br>
Hopefully an experienced developer in chan_sip and database integration can<br>
enlighten us as to why things are implemented the way they are. It may be<br>
possible that no developer has scratched the itch, as it were.<br>
<font color="#888888"><br>
Leif Madsen.<br>
</font><div><div></div><div class="h5"><br>
--<br>
_____________________________________________________________________<br>
-- Bandwidth and Colocation Provided by <a href="http://www.api-digital.com" target="_blank">http://www.api-digital.com</a> --<br>
<br>
asterisk-dev mailing list<br>
To UNSUBSCRIBE or update options visit:<br>
<a href="http://lists.digium.com/mailman/listinfo/asterisk-dev" target="_blank">http://lists.digium.com/mailman/listinfo/asterisk-dev</a><br>
</div></div></blockquote></div><br>