Respuesta: Re: [asterisk-dev] Making some changes to chan_sip andwouldlikesomefeedback

[roberto caspa]

> Most of what you did was unneeded... it's already possible to do
> wildcard includes in sip.conf to include the contents of your
> 'extensions' directory.
> 
> Effectively, the only change that needs to be made is for chan_sip to
> build new peer/user objects from the config file, but only replace 
> themif they are actually different from the ones already in 
> memory. Doing
> that would then remove the burden of having to reload specific 
> peers or
> users from the CLI, since 'sip reload' would properly touch only the
> peers and users that were changed.

I would be dumb to try to argue with one of the maintainer of the code, but I am trying to understand  so I continue...

We use wild card includes now, but that defeats the purpose of what we are trying to achieve which is not to reload all sip information when we make a small change such as the context of a single peer.

Having chan_sip build a new object for peers would still mean scanning the entire file and comparing it with values loaded in memory looking for changes.  In additon, trying to update a single field for a specific peer in sip.conf would be a nightmare pushing us to recreate and reload the entire file.

Here is what we are trying to achieve:

We setup sip entries for our devices.  These devices are "dumb" in the sense that they are only allowed to dial emergency numbers and a specific extension where a user logs in.  

Upon login, we use the dialplan to retrieve the user's context from the db and overwrite the device's context in the db.  We run a perl script that creates a new .conf file for that device using the values in the db which now include the user's context rather than the original one(shamelessly taken from AMP/freePBX).  We then execute a system call from the dialplan reloading that .conf file.

Now we have mobile users able to log in to any device , and different call center agents using the same desk with a different permission set.

Log off reverses the process and we now have a dumb device again.

We think that trying to achieve this would be harder when dealing with a single, monolithic sip.conf file.  We looked into using realtime, but as we understood the documentation, changes like the one we are trying to achieve would still necesitate a sip reload to update the cached information.