----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4379/#review14470 -----------------------------------------------------------
/branches/13/configs/examples/awesome/asterisk.conf <https://reviewboard.asterisk.org/r/4379/#comment25005> This isn't a template /branches/13/configs/examples/awesome/asterisk.conf <https://reviewboard.asterisk.org/r/4379/#comment25004> So, this is where things get fun. In extensions.conf, we've noted that under the hood, there is no semantic difference between '=' and '=>', even if previously, the nomenclature was to use '=>'. The same is true here, as well as in modules.conf and elsewhere. I'd prefer us to be consistent: either we should continue to use the existing nomenclature, where non-key/value pair settings use '=>' ("objects", as they used to be called) - or we should use '=' everywhere. /branches/13/configs/examples/awesome/asterisk.conf <https://reviewboard.asterisk.org/r/4379/#comment25006> I'd personally just remove this block, as it is rather getting into advanced settings to change the CTL group/owner. /branches/13/configs/examples/awesome/extensions.conf <https://reviewboard.asterisk.org/r/4379/#comment25007> I think the lining scheme in the extensions.conf is a little odd. In some places, you clearly are lining things up based on the priority. Here, however, we're not - and we're a little off of the '=' sign as well. Personally, I prefer lining things up based on the '=' or '=>', as that is consistent throughout the file, and the first line in any extension should almost always be an 'entry point'. That keeps things lined up: exten => my_long_extension,1,NoOp() same => n,foo() same => n,bar() exten => a_short_one,1,NoOp() same => n,invoke_something() same => n,do_something_else() That being said, I'm also fine if we line things up based on priority - but I'd go for a consistent scheme and stick with it. (I do think lining things up on priority leads to a lot of leading white space, but that's just my laziness kicking in.) /branches/13/configs/examples/awesome/extensions.conf <https://reviewboard.asterisk.org/r/4379/#comment25008> I'd put a NoOp() on the beginnings of these, as it is highly likely that someone will modify the NOANSWER/BUSY/CHANUNAVAIL subroutines /branches/13/configs/examples/awesome/logger.conf <https://reviewboard.asterisk.org/r/4379/#comment25009> Go with least to greatest: console => verbose,notice,warning,error - Matt Jordan On Feb. 12, 2015, 6:46 p.m., rnewton wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviewboard.asterisk.org/r/4379/ > ----------------------------------------------------------- > > (Updated Feb. 12, 2015, 6:46 p.m.) > > > Review request for Asterisk Developers. > > > Repository: Asterisk > > > Description > ------- > > One of things discussed at the last AstriDevCon was better documentation (for > everything!), but in particular, we mentioned needing some example > configurations that pertain to a real-world scenario. That is, as opposed to > the current "sample" files which are sort of all over the place at this point. > > This patch proposes a basic and minimal configuration of Asterisk to satisfy > the requirements for the first phase of Super Awesome Company's > implementation of Asterisk. > > I will submit four separate patches for the first phase, so that we don't > have to review the entire thing all at once. This review is for the first > patch. > > Who is Super Awesome Company? See > https://wiki.asterisk.org/wiki/display/AST/Super+Awesome+Company > > For the first patch, I am attempting to satisfy the below requirements. The > patch does not include a new make target, as I believe Matt Jordan offered to > handle that. > > SAC requires: > > * PJSIP connectivity for all employee desk phones. > * The ability for employees to call one another inside of the office. > * Voicemail boxes for each of the employees. > > "Basic" configuration > > We want SAC to have a clean system. That means: > > * No 'autoload' in modules.conf. Explicitly load a basic configuration. > If SAC doesn't need the module, don't load it. > * Every module loaded should have a configuration file that is > appropriate for it. This includes all the 'core' things that need > configuration. > > pjsip.conf > > * A PJSIP configuration for their desk phones. Assume every endpoint that > is a phone has: > * A voicemail mailbox that they can subscribe to > * A hint for their device > * Note that the PJSIP configuration should adhere to best practices. > That means MAC addresses for device names, etc. > > extensions.conf > > * A safe dialplan for intra-company communication. This should be > templated out so that it is trivial to add additional devices (use pattern > matching/pattern matching hints, etc.) > * Receiving a Busy/Unavailable should result in going to VoiceMail > * A user should be able to dial something and get to their VoiceMailMain > without having to enter in their extension number > * Note that mapping of MAC address endpoints to extension numbers should > be done in some fashion that is easily extensible. > > voicemail.conf > > * Set up mailboxes for every person in SAC. Assign 'default' pins. Create > reasonable basic settings. > * Do not set up e-mail or pager addresses. > > > REVIEW? > > Please, if possible look at this from a few angles: > > * Use the configuration, configure a couple phones and call between them. > Leave voicemails and retrieve them. > * Have I created any security issues? > * Is my dialplan easy to understand? > * Could anything be done more efficiently without making it over-complicated? > * Have I over-complicated anything? > * Are there any critical settings I'm missing from any of the files? > > A couple, more specific questions: > > * We have sample configs in /configs/samples; what directory do we want > these configurations in? (I used /configs/examples for now, but I don't > really like it) > * We have the make target "make samples" for the current samples; what do we > want for these new configs? > > > Diffs > ----- > > /branches/13/configs/examples/awesome/voicemail.conf PRE-CREATION > /branches/13/configs/examples/awesome/pjsip.conf PRE-CREATION > /branches/13/configs/examples/awesome/musiconhold.conf PRE-CREATION > /branches/13/configs/examples/awesome/modules.conf PRE-CREATION > /branches/13/configs/examples/awesome/logger.conf PRE-CREATION > /branches/13/configs/examples/awesome/indications.conf PRE-CREATION > /branches/13/configs/examples/awesome/extensions.conf PRE-CREATION > /branches/13/configs/examples/awesome/asterisk.conf PRE-CREATION > /branches/13/configs/examples/awesome/README PRE-CREATION > > Diff: https://reviewboard.asterisk.org/r/4379/diff/ > > > Testing > ------- > > Setup Asterisk with configuration, connected up three phones using the first > three users. Made calls between them all, left voicemails and retrieved them > with all users. Verified MWI working with all phones. > > > Thanks, > > rnewton > >
-- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
