Koozali.org: home of the SME Server

Obsolete Releases => SME VoIP (Asterisk, SAIL etc) => Topic started by: frifri on August 15, 2010, 11:51:30 PM

Title: ivr <> features.conf
Post by: frifri on August 15, 2010, 11:51:30 PM
Hi,

fresh sail-2.4.1-28

When i press 1  in a IVR, asterisk wants to record the call.

In features.conf i find : automon=>1 ?!?!

This must be automon=>*1, no ?

F.
Title: Re: ivr <> features.conf
Post by: frifri on September 07, 2010, 12:32:03 PM
I 've changed de automon-value in the header-section to *1

But, after every reconfiguration of the SME-server the automon-value is changed back to 1 ?!?

How is that possible ?

F.

Same problem on SME 8 + sail 2.6
Title: Re: ivr <> features.conf
Post by: Stefano on September 07, 2010, 04:47:44 PM
I 've changed de automon-value in the header-section to *1

But, after every reconfiguration of the SME-server the automon-value is changed back to 1 ?!?

How is that possible ?

F.

Same problem on SME 8 + sail 2.6

frifri.. you should read the documentation and learn how SME works..  :)

ise there something similar
Code: [Select]
#------------------------------------------------------------
#          !!DO NOT MODIFY THIS FILE!!
#
# Manual changes will be lost when this file is regenerated.
#
# Please read the developer's guide, which is available
# at http://www.contribs.org/development/
#
# Copyright (C) 1999-2006 Mitel Networks Corporation
#------------------------------------------------------------

at the beginning of the file?
Title: Re: ivr <> features.conf
Post by: frifri on September 07, 2010, 05:37:50 PM
Stefano,

I do know how SME works and i even know how sail/sark works.  Please, read the SARK-wiki and you will find about the headers-section :

SARK UCS/MVP _ Headers Panel exposes the generated file headers of those _.conf files which SARK manages for you. In addition to the regular Asterisk .conf files, there are also two virtual .conf files; seldir.conf and selspeed.conf. Neither of these files exist in the asterisk directory proper but only as SARK/SAIL database tuples. Below we show screen shots of the modification panels for voicemail.conf, features.conf and sip.conf. You can freely modify the entries to suit your installation requirements.

The problem is not SME, nor the SARK-templates, but the Selintra-database !

F.
Title: Re: ivr <> features.conf
Post by: Stefano on September 07, 2010, 05:49:11 PM
touchè :-)

thank you for the explanation, I'm sure sark dev's would help you
Title: Re: ivr <> features.conf
Post by: frifri on September 07, 2010, 05:55:05 PM
 :)

I think a reconfiguration of the SME-server changes the selintra-database.  That is something that shouldn't happen.

F.
Title: Re: ivr <> features.conf
Post by: frifri on September 07, 2010, 06:24:46 PM
'Solved' by changing manually the 'selintra-updates'-db.

F.
Title: Re: ivr <> features.conf
Post by: SARK devs on September 07, 2010, 08:11:44 PM
Quote
I think a reconfiguration of the SME-server changes the selintra-database.  That is something that shouldn't happen.

It's a little more complex.  Here is how it works...

An SME server reconfig (for example, post-upgrade) will usually run the fragments in the migrate tree (in /etc/e-smith/db).  Sail-2.x has a migrate routine in that tree.  When it runs it will first delete the keys in the file /home/e-smith/db/selintra-delete from the selintra database.  It will then attempt to add the rows in /home/e-smith/db/selintra-update.  Now, because the SME database only allows unique keys, it is safe to repeatedly apply /home/e-smith/db/selintra-update because it can't add the same row twice (the SME database won't allow it).  Also because we have a delete/add couple; then by deciding what we put in each, we can keep the selintra database up to date.

Unfortunately, frifri, by removing only the features update row, you may have caused yourself a small problem.  The next time the SME reconfigure runs on your system it will delete the features.conf entry (see  /home/e-smith/db/selintra-delete) but now, it will not add it back because you have removed the update row. 

Now, you have correctly identified this as a bug because we should not be repeatedly cleaning this record because, as you say, users should be allowed to change it for themselves. However, the correct way to remove the restraint is to remove the key from the selintra-delete file and leave the row in the selintra-update file.  In this way, it will be added to systems where it doesn't exist (i.e. new systems) but it will not change systems where it does exist.

Thankyou for reporting this error and I hope my explanation is clear.

Kind Regards

S

Title: Re: ivr <> features.conf
Post by: frifri on September 07, 2010, 08:21:37 PM
Hi S,

I didn't delete the update-row, i just changed it to :

Quote
features.conf=Header|desc||header|features.conf|headerlines|[general]\nparkext=>*5\nparkpos=>701-702\ncontext=>parkedcalls\nparkingtime=>300\ntransferdigittimeout=>8\ncourtesytone=beep\n;adsipark=yes\npickupexten=*8\n[featuremap]\nblindxfer=>#\n;disconnect=>*0\nautomon=>*1\natxfer=*2|zzeor|EOR

F.

And i will delete the features.conf-key in selintra-deletes.