[asterisk-dev] realtime, rtcachefriends/rtupdate, qualify and hints interaction

[nico kooijman]

I have one answer on the subscribe. The sip_cfg setting allowsubscribe is
set to false
on a reload. When one of the peers has allowsubscribe on then de sip_cfg is
changed
to true. When in between a reload and a subscribe no requests are done the
subscribe
will indeed fail with the reason Forbidden (policy).

2010/3/10 Leif Madsen <leif.madsen at asteriskdocs.org>

> Ron Arts wrote:
> > I am planning on writing a patch to refresh the realtime cache
> > after a sip reload, but maybe I'm doing the wrong thing here.
> >
> > Now. What I'd like to do is:
> >
> > 1. ensure that a SUBSCRIBE message from a phone fills the realtime
> >     cache, so the subscribe succeeds
> > 2. somehow ensure that after a sip reload the entire cache is refreshed
> >     so that qualifying keeps happening.
> >
> > Is this stupid for some reason? Did I miss something?
>
> I'm sure there is a reason this is they way it is, and that a developer
> will
> enlighten us as to why this is the case, but I agree that it'd be nice to
> not
> require the phones to re-register to get put back in the cache with
> realtime
> after a sip reload.
>
> I'm not sure I'd go the route of refreshing the cache after a sip reload
> (i.e.
> clearing the cache, then trying to load all the information back into
> memory
> from the database) -- I have a vague recollection of a reason why this was
> not
> possible.
>
> However, maybe it would be easier to implement a system that simply doesn't
> remove the entries from memory upon a reload? Without knowing anything
> about the
> core code, and only about the implementation of realtime, I'm not sure if
> this
> is an appropriate route either.
>
> Hopefully an experienced developer in chan_sip and database integration can
> enlighten us as to why things are implemented the way they are. It may be
> possible that no developer has scratched the itch, as it were.
>
> Leif Madsen.
>
> --
> _____________________________________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>   http://lists.digium.com/mailman/listinfo/asterisk-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-dev/attachments/20100310/aed050df/attachment-0001.htm