If this could be done this way it might be more desirable. My only concern would if somebody makes a conf bridge change and they reload do they then dump the ACD?
Mike On Wed, Nov 10, 2010 at 1:11 PM, Tony Graziano <tgrazi...@myitdepartment.net > wrote: > I dont know if this helps or not, but here is what was discussed. > > [13:05] <@cypromis> actualy we would have to just send a reloadxml > [13:05] <georgen> I think is about reloadxml > [13:05] <@cypromis> over event socket > [13:05] <georgen> > http://wiki.freeswitch.org/wiki/FreeSwitch_FAQ#Q:_Does_reloadxml_reload_all_XML_files.3F > [13:05] <georgen> and does not affect conferences, but what about dial > plans? > [13:05] <@cypromis> it reloads dial plans > [13:05] <@cypromis> and all other xml files > [13:06] <@cypromis> they just do not get activated in all modules > [13:06] <@cypromis> so to get sofia to reread its configs you would have > to restart sofia > > > So further discussion might be needed. It might have the desired affect to > edit and activate dial plans with openacd without breaking a transaction > though. > > On Wed, Nov 10, 2010 at 1:07 PM, Tony Graziano < > tgrazi...@myitdepartment.net> wrote: > >> There was a discussion between myself and anoth dev (Michal Bielicki) who >> acknoweldged there was a way to reload FS configs without interfering with >> an in progress transaction. >> >> We will try to re-hash that conversation and make it available here (in a >> nutshell), so this won't really be as much of a nuisance as it currently is >> (I hope). >> >> Tony >> >> >> On Wed, Nov 10, 2010 at 12:31 PM, Todd Hodgen <thod...@frontier.com>wrote: >> >>> +1 >>> >>> -----Original Message----- >>> From: sipx-users-boun...@list.sipfoundry.org >>> [mailto:sipx-users-boun...@list.sipfoundry.org] On Behalf Of Douglas >>> Hubler >>> Sent: Wednesday, November 10, 2010 9:24 AM >>> To: Discussion list for users of sipXecs software >>> Subject: Re: [sipx-users] when to reload Freeswitch dial plans >>> >>> On Wed, Nov 10, 2010 at 10:16 AM, George Niculae <geo...@ezuce.com> >>> wrote: >>> > Hi All, >>> > >>> > I am working on OpenACD integration (it use Freeswitch dial plans) and >>> > one requirement is to replicate Freeswitch dial plan on admin action >>> > only - say admin configures several extensions and wants this to take >>> > effect only when they all are configured. In order to do this I am >>> > going to mark Freeswitch service with a reload needed flag and send >>> > reloadxml command only on a specific action (same way as restarting >>> > marked services today from services page). >>> > The issue here is that at this moment conferences are using Freeswitch >>> > dial plans as well and any change on conferences automatically reloads >>> > dial plans - this will make also OpenACDs extensions to be taken into >>> > account. I discussed this with Douglas and agreed for changing >>> > conference to use same mechanism / workflow: conference changes will >>> > need a reload action on service page in order to be taken into >>> > account. >>> > >>> > Please let me know what do you think about introducing this new step >>> > for configuring conferences. >>> >>> FYI: This is a very fundamental topic, admins please vote because I >>> tried to speak on your behalf. >>> >>> Quick summary: As an admin, you want to be in control when changes go >>> live. Even when some portions of the system could make configuration >>> changes in the background and have a fairly good chance of not >>> disrupting service. Keywords: *fairly good chance*. If you change >>> conference settings to a conference already in progress, it may not >>> always be well defined what freeswitch does for example. NOTE: There >>> may be special cases however, simple settings like changing a pin or >>> turning on/off recording are known to be safe and would go live as you >>> change them. >>> >>> What we're proposing is adding to the "Some services need to be >>> restarted or reloaded" notice and page, a new "Status" that let's you >>> know the which services would be reloaded and should not experience an >>> interruption to the service. We would propose we follow this >>> paradigm when we support reloading of dial plans in proxy/registrar. >>> How it works today is way too slick IMHO. It waits for a window of 7 >>> seconds of no new configuration activity has been made, then goes and >>> deploys the changes. This may work for adding aliases and changes >>> user's permissions, but not for reloading Freeswitch's configuration. >>> _______________________________________________ >>> sipx-users mailing list >>> sipx-users@list.sipfoundry.org >>> List Archive: http://list.sipfoundry.org/archive/sipx-users/ >>> >>> _______________________________________________ >>> sipx-users mailing list >>> sipx-users@list.sipfoundry.org >>> List Archive: http://list.sipfoundry.org/archive/sipx-users/ >>> >> >> >> >> -- >> ====================== >> Tony Graziano, Manager >> Telephone: 434.984.8430 >> sip: tgrazi...@voice.myitdepartment.net >> Fax: 434.326.5325 >> >> Email: tgrazi...@myitdepartment.net >> >> LAN/Telephony/Security and Control Systems Helpdesk: >> Telephone: 434.984.8426 >> sip: helpd...@voice.myitdepartment.net >> >> Helpdesk Contract Customers: >> http://support.myitdepartment.net >> >> Linked-In Profile: http://www.linkedin.com/pub/tony-graziano/14/4a6/7a4 >> >> > > > -- > ====================== > Tony Graziano, Manager > Telephone: 434.984.8430 > sip: tgrazi...@voice.myitdepartment.net > Fax: 434.326.5325 > > Email: tgrazi...@myitdepartment.net > > LAN/Telephony/Security and Control Systems Helpdesk: > Telephone: 434.984.8426 > sip: helpd...@voice.myitdepartment.net > > Helpdesk Contract Customers: > http://support.myitdepartment.net > > Linked-In Profile: http://www.linkedin.com/pub/tony-graziano/14/4a6/7a4 > > > _______________________________________________ > sipx-users mailing list > sipx-users@list.sipfoundry.org > List Archive: http://list.sipfoundry.org/archive/sipx-users/ > -- There are 10 kinds of people in this world, those who understand binary and those who don't. mpic...@gmail.com blog: http://www.sipxecs.info call: sip:mpic...@sipxecs.info <sip%3ampic...@sipxecs.info>
_______________________________________________ sipx-users mailing list sipx-users@list.sipfoundry.org List Archive: http://list.sipfoundry.org/archive/sipx-users/
