[asterisk-dev] SIP call-limit and Realtime

[Johansson Olle E]

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.

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".

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 :-)

/O