[asterisk-dev] SIP call-limit and Realtime

[Atis Lezdins]

On 1/23/08, Johansson Olle E <oej at edvina.net> wrote:
>
> 23 jan 2008 kl. 10.30 skrev Benny Amorsen:
>
> > Johansson Olle E <oej at edvina.net> writes:
> >
> >> I need to think about this a bit more, but we do need a different
> >> kind of hint for realtime objects. It's a complicated system as it
> >> is. Devices can't subscribe to extensions without current hints
> >> which means that we need the hint regardless... Weird loop.
> >
> > Perhaps it would be possible move hints out of the dial plan? They
> >> really don't
> > fit into it.
> >
> > Imagine Voice Mail implemented the way hints are --
> > exten => 801,vm,VM(9999,Tech Voicemail,support at example.com,,delete=1)
> > I'm sure you'll agree that it wouldn't be a good idea. The same holds
> > for hints.
>
>
> Well, the hints are just a way to connect the two namespaces,
> extensions and devices. In the dialplan we do the same connection
> for a call, so it actually fits there in a way.
>
> I could see voicemail using a voicemailbox hint like
>
> exten => 801,vm,9999 at default
>
> to connect an extension to a voicemailbox - but not the way
> you had it. :-)
>
> Has anyone really investigated the number of database lookups
> involved in using call state notification with realtime? Without
> keeping devices in memory (now called caching) there will
> be a huge number of transactions for every state change.
> I don't think that's what anyone wants.
>
> So we gotta keep the devices as static objects in memory,
> not dynamic objects. The issue here is a chicken-and-egg
> problem.

I think this needs some testing and playing around that.

My opinion is that realtime is for large installations - so db can be
separated (and even clustered). Database engines do a lot of caching,
have indexes, and i think are much more optimized and flexible than
astobj2.

Let's say we have 10000 devices. Each device changes state once every
5 minutes - that would mean 10000 changes/ 5 minutes = 33 changes per
second. If we have two transactions for state-change, that would be 66
queries per second. In terms of database engines table with 10000
records is small, and having 66 queries per second is really ok.


> Subscriptions are only allowed on SIP uri's that match an
> extension with a hint. So the hint needs to be there, always.
> With 10.000 devices in a database, that will be a huge dialplan.
> Won't be manageable.
>
> We need a regexp based hint, much like enum entries.
> When we get a subscription, we need to create an in-memory
> entry for the hint to manage states for the hint, but only
> when we have a "watcher".

This sounds good, however if i have some non-regular mapping between
extensions and devices? so that extensions can change devices any
time? This would require database, and entry for each mapping, no
regular expression could do that. As stated above - database wouldn't
have problem with this.

> The subscription system in chan_sip doesn't scale very well. I started
> a rewrite this summer, but had to cancel the project due to my health
> issues and lost the customer. Have some ideas, need funding :-)

Good luck with that :)

Regards,
Atis

-- 
Atis Lezdins
VoIP Developer,
IQ Labs Inc.
atis at iq-labs.net
Skype: atis.lezdins
Cell Phone: +371 28806004
Work phone: +1 800 7502835