[Home]

Summary:ASTERISK-06965: [patch] Add support to search for first OR last name in the directory
Reporter:Corey Frang (gnarf)Labels:
Date Opened:2006-05-12 17:01:38Date Closed:2010-11-25 11:41:00.000-0600
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Applications/NewFeature
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) 20080319__bug7151.diff.txt
( 1) app_directory.c.svn.diff
( 2) dir-intro-fnln.gsm
Description:A customer of ours request that the voicemail directory be able to search on first OR last names.  I added this feature, and it would require recording a dir-intro-fnln.gsm from allison, but we had our voice actor record one.  I would very much like to see this in new versions of asterisk, as it is a simple change.
Comments:By: Corey Frang (gnarf) 2006-05-12 17:11:41

Uploaded the dir-intro-fnln.gsm for you guys to test with until allison can record the official one.

By: Serge Vecher (serge-v) 2006-05-22 14:53:17

gnarf: can you please update your patch against latet trunk, please? (All features go there ... thanks)

By: Serge Vecher (serge-v) 2006-06-05 20:00:21

need trunk patch, please, for this to make it into 1.4 beta ...

By: Ronald Chan (loloski) 2006-06-06 05:30:48

vechers: i'll upload a patch name "patch.diff" this should cleanly applies to trunk, disclaimer *NOT* sent. i'll try to do it asap.



Best regards

Ronald

By: Clod Patry (junky) 2006-08-08 22:01:15

Any news on the disclaimer status here?

By: Ronald Chan (loloski) 2006-08-08 22:14:44

Junky,

  Sorry, i forgot to send the disclaimer, will do it asap. it's been very busy here a couple of months ago, could somebody confirm the code still applies to latest SVN trunk?


Best regards,

Ronald

By: Clod Patry (junky) 2006-08-09 07:15:53

we're not suppose to take a look at your patch, until you send the disclaimer.
When that will be done, just inform us so we can go forward in the process.

By: jmls (jmls) 2006-11-01 05:28:12.000-0600

gnarf: did you send the disclaimer in ? And are you able to provide an uptodate patch for trunk ? Many thanks

By: Corey Frang (gnarf) 2006-11-01 14:53:41.000-0600

I have sent in my disclaimer a while ago (Corey Frang), however, I don't have a machine with SVN, I'll look into getting that today.

By: Corey Frang (gnarf) 2006-11-01 16:16:10.000-0600

Can someone please delete app_directory.c.diff and patch.diff... The uploaded app_directory.c.svn.diff is against current SVN.  My disclaimer is on file.

By: Corey Frang (gnarf) 2007-01-20 19:26:10.000-0600

ping: just wondering what the status is on this, its post 1.4 now ;)

By: Serge Vecher (serge-v) 2007-01-29 08:21:10.000-0600

how about making this new option search by last name instead? Then you just use b and f if you want to first/last name matching ...

By: Corey Frang (gnarf) 2007-01-29 12:48:53.000-0600

Well, I suppose that makes a little sense, if thats the way you think it should run, I'll change the patch around.  However, since the default is to look at last name, it wouldn't make a whole lot of sense to me to add an option that doesn't do anything unless used with another option.

Either way, lemme know :)

By: Serge Vecher (serge-v) 2007-02-01 13:57:07.000-0600

gnarf: I think my brain had a "logical breakdown". Please disregard, your patch is fine as is ;)

By: Corey Frang (gnarf) 2007-02-01 14:32:06.000-0600

I get those all the time... ;)

By: Eric Caron (ecaron) 2007-04-19 12:37:34

Tested patch against Asterisk SVN-branch-1.4-r59042 and it works great.
dir-intro-fnln.gsm could use a bit of work.

By: Eric Caron (ecaron) 2007-04-28 14:29:33

Can we get people to test this to be included in 1.4.5?

By: Clod Patry (junky) 2007-06-14 20:37:29

that feature wont be added in 1.4.5, since it's a new feature.
That will be only in 1.6

By: Eric Caron (ecaron) 2007-06-14 22:36:41

The patch, in its stable form, was ready for the trunk before 1.4 went final (2006-11-01 vs 2006-12-23). How exactly do you justify this being put off until 1.6 when serge-v said over a year ago this could/should be in 1.4 beta?

I would argue that this isn't so much as a feature as it is making an existing feature complete.

By: Brett Bryant (bbryant) 2007-07-27 11:01:49

I emailed kevin about getting a sound file for this. Since this is the last day i'm here i'm unassigning the issue.

By: Eric Caron (ecaron) 2007-09-26 15:43:17

Has this been merged into the trunk yet?

By: Eric Caron (ecaron) 2007-12-01 16:24:37.000-0600

I can confirm that this patch works with 1.4.15, can it be updated as such?

By: Tilghman Lesher (tilghman) 2007-12-01 18:47:10.000-0600

As a new feature, it can only go into trunk, not 1.4

By: Eric Caron (ecaron) 2007-12-03 16:04:10.000-0600

Great! What would it take to have this merged into the branch?
Also, so I waste less of your time, how do I know if something is considered a "new feature" vs "completing an existing feature"?

By: Tilghman Lesher (tilghman) 2007-12-03 16:10:42.000-0600

Doesn't matter.  Patches that solve bugs are the only type that are welcomed in 1.4.  Any feature add whatsoever goes only into trunk.

In terms of adding it, we're waiting on the prompts in multiple languages to be recorded.

By: jmls (jmls) 2008-02-06 04:16:48.000-0600

Corydon76, have the prompts been recorded yet ?

By: Tilghman Lesher (tilghman) 2008-02-06 12:19:33.000-0600

Next batch, I swear.  ;-)

By: Tilghman Lesher (tilghman) 2008-03-11 12:35:47

Okay, patch uploaded, and the new sounds needed are in asterisk-sounds-1.4.9, so test away.  Let me know if you find any problems that I have not detected.

By: Tilghman Lesher (tilghman) 2008-03-20 20:26:55

Committed, revision 110237

By: Digium Subversion (svnbot) 2008-03-20 20:40:18

Repository: asterisk
Revision: 110444

U   trunk/CHANGES

------------------------------------------------------------------------
r110444 | tilghman | 2008-03-20 20:40:17 -0500 (Thu, 20 Mar 2008) | 2 lines

Add note of the added Directory options, from commit 110237 (closes issue ASTERISK-6965)

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=110444

By: Digium Subversion (svnbot) 2008-03-25 10:22:13

Repository: asterisk
Revision: 110633

_U  branches/1.6.0/

------------------------------------------------------------------------
r110633 | file | 2008-03-25 10:22:12 -0500 (Tue, 25 Mar 2008) | 9 lines

Blocked revisions 110444 via svnmerge

........
r110444 | tilghman | 2008-03-20 22:44:38 -0300 (Thu, 20 Mar 2008) | 2 lines

Add note of the added Directory options, from commit 110237 (closes issue ASTERISK-6965)

........

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=110633

By: Digium Subversion (svnbot) 2008-04-09 15:15:44

Repository: asterisk
Revision: 113924

U   team/group/NoLossCDR-Redux2/build_tools/cflags.xml
U   team/group/NoLossCDR-Redux2/pbx/pbx_ael.c
U   team/group/NoLossCDR-Redux2/phoneprov/000000000000-directory.xml
U   team/group/NoLossCDR-Redux2/phoneprov/polycom.xml
A   team/group/NoLossCDR-Redux2/phoneprov/polycom_line.xml

------------------------------------------------------------------------
r113924 | juggie | 2008-04-09 15:15:41 -0500 (Wed, 09 Apr 2008) | 211 lines

Merged revisions 110020,110023,110036,110084,110087,110132,110161,110164,110211,110237,110268,110270,110272,110303,110337,110339,110396,110444 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk

................
r110020 | file | 2008-03-19 14:25:33 -0400 (Wed, 19 Mar 2008) | 14 lines

Merged revisions 110019 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
r110019 | file | 2008-03-19 15:20:28 -0300 (Wed, 19 Mar 2008) | 6 lines

Make sure that the mark bit does not incorrectly cause video frame timestamps to be calculated as if they are audio frames.
(closes issue ASTERISK-10940)
Reported by: sperreault
Patches:
     11429-frametype.diff uploaded by qwell (license 4)

........

................
r110023 | russell | 2008-03-19 14:57:16 -0400 (Wed, 19 Mar 2008) | 2 lines

remove svnmerge-blocked property that is not supposed to be here

................
r110036 | file | 2008-03-19 15:13:39 -0400 (Wed, 19 Mar 2008) | 12 lines

Merged revisions 110035 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
r110035 | file | 2008-03-19 16:11:33 -0300 (Wed, 19 Mar 2008) | 4 lines

Add sanity checking for position resuming. We *have* to make sure that the position does not exceed the total number of files present, and we have to make sure that the position's filename is the same as previous. These values can change if a music class is reloaded and give unpredictable behavior.
(closes issue ASTERISK-11136)
Reported by: junky

........

................
r110084 | mmichelson | 2008-03-19 16:34:13 -0400 (Wed, 19 Mar 2008) | 12 lines

Merged revisions 110083 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
r110083 | mmichelson | 2008-03-19 15:33:03 -0500 (Wed, 19 Mar 2008) | 4 lines

Add a missing unlock in the case that memory allocation fails in app_chanspy.
Thanks to Russell for confirming that this was an issue.


........

................
r110087 | jpeeler | 2008-03-19 17:05:24 -0400 (Wed, 19 Mar 2008) | 2 lines

This change adds DNS manager support for registrations not referencing a peer entry. It looks like there is support for DNS manager for realtime peers as well, however it is not implemented correctly. The improper usage occurs when ast_dnsmgr_lookup is called with one of the arguments being an address from the stack to be continually updated. The variable from the stack will go out of scope and dnsmgr will continue to try and update the memory there, causing possible stack corruption. This problem will be worked on next as well as adding DNS manager support for peer entries.

................
r110132 | qwell | 2008-03-19 17:56:15 -0400 (Wed, 19 Mar 2008) | 1 line

Rename very poorly named function to reflect what it actually does.  This was causing quite a bit of confusion for me...
................
r110161 | qwell | 2008-03-19 18:25:34 -0400 (Wed, 19 Mar 2008) | 5 lines

Rename DSP_FEATURE_DTMF_DETECT, because we are *NOT* only detecting DTMF digits.
This was very misleading.

Early cleanup for issue ASTERISK-11413

................
r110164 | russell | 2008-03-19 18:58:33 -0400 (Wed, 19 Mar 2008) | 13 lines

Merged revisions 110163 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
r110163 | russell | 2008-03-19 17:57:59 -0500 (Wed, 19 Mar 2008) | 5 lines

Fix a bug where when calls on the trunk side hang up while on hold, the state
is not properly reflected.

(closes issue ASTERISK-11434, reported by anakaoka, patched by me)

........

................
r110211 | tilghman | 2008-03-19 23:14:59 -0400 (Wed, 19 Mar 2008) | 2 lines

Fix recent trunk breakage

................
r110237 | tilghman | 2008-03-20 01:06:12 -0400 (Thu, 20 Mar 2008) | 5 lines

Upgrade the sounds version; add several directory enhancements:
1) Number of digits to enter can now be configured
2) The digits can now match on both first AND last name, instead of only one or the other
(Closes issue ASTERISK-6965)

................
r110268 | russell | 2008-03-20 13:41:22 -0400 (Thu, 20 Mar 2008) | 27 lines

Add some fixes that I made in regards to wideband codec handling to get
G.722 music on hold working for me.

(issue ASTERISK-11594, reported by milazzo and jsmith, patches by me)

res/res_musiconhold.c:
- I moved a single line so that the sample queue update happened before
  ast_write().  The reason that this was a bug is that the G.722 frame
  originally says it has 320 samples in it (which is correct).  However,
  when the frame is written to a channel that uses RTP, main/rtp.c modifies
  the frame to cut the number of samples in half before it sends it on
  the wire.  This is to account for the stupid incorrect G.722 spec that
  makes it so we have to lie about the number of samples with RTP.  I should
  probably go and re-work the RTP code so it doesn't modify the frame so
  that a bug like this won't happen in the future.  However, this change to
  MOH is harmless.

main/channel.c:
- I made two fixes in regards to generator timing.  Generators use samples
  for timing.  However, this code assumed 8 kHz samples.  In one case, it was
  a hard coded 160 samples, that is now written as the sample rate / 50.  The
  other place was dealing with timing a generator based on frames coming from
  the other direction.  However, that would have only worked if the sample
  rates for the formats in both directions were the same.  The code now takes
  into account that the sample rates may differ, and scales the generator
  samples accordingly.

................
r110270 | russell | 2008-03-20 13:45:29 -0400 (Thu, 20 Mar 2008) | 2 lines

Remove astobj.h from some places where it wasn't needed

................
r110272 | mmichelson | 2008-03-20 14:01:36 -0400 (Thu, 20 Mar 2008) | 3 lines

Add missing unlock


................
r110303 | russell | 2008-03-20 16:08:26 -0400 (Thu, 20 Mar 2008) | 8 lines

Fix a bug when using zaptel timing for playing back files that have a sample rate
other than 8 kHz.  The issue here is that format modules give a "whennext" sample
value, which is used to calculate when to set a timer for to retrieve the next
frame.  However, the zaptel timer operates on 8 kHz samples, so this must be taken
into account.

(another part of issue ASTERISK-11594, reported by milazzo and jsmith, patch by me)

................
r110337 | russell | 2008-03-20 17:55:50 -0400 (Thu, 20 Mar 2008) | 22 lines

Merged revisions 110336 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

................
r110336 | russell | 2008-03-20 16:54:58 -0500 (Thu, 20 Mar 2008) | 14 lines

Merged revisions 110335 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.2

........
r110335 | russell | 2008-03-20 16:53:27 -0500 (Thu, 20 Mar 2008) | 6 lines

Fix some very broken code that was introduced in 1.2.26 as a part of the security
fix.  The dnsmgr is not appropriate here.  The dnsmgr takes a pointer to an address
structure that a background thread continuously updates.  However, in these cases,
a stack variable was passed.  That means that the dnsmgr thread would be continuously
writing to bogus memory.

........

................

................
r110339 | russell | 2008-03-20 18:02:20 -0400 (Thu, 20 Mar 2008) | 3 lines

Use the correct buffer for g722tolin16_sample.  This shouldn't have caused any
problems, but Qwell noticed the typo here.

................
r110396 | russell | 2008-03-20 19:14:13 -0400 (Thu, 20 Mar 2008) | 17 lines

Merged revisions 110395 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
r110395 | russell | 2008-03-20 18:13:56 -0500 (Thu, 20 Mar 2008) | 9 lines

Shorten the ast_waitfor() timeout from 500 ms to 50 ms in the autoservice thread.
This really should not make a difference except in very rare cases.  That case would
be that all of the channels in autoservice are not generating any frames.  In that
case, this change reduces the potential amount of time that a thread waits in
ast_autoservice_stop() for the autoservice thread to wrap back around to the beginning
of its loop.

(closes issue ASTERISK-11689, reported by dimas)

........

................
r110444 | tilghman | 2008-03-20 21:44:38 -0400 (Thu, 20 Mar 2008) | 2 lines

Add note of the added Directory options, from commit 110237 (closes issue ASTERISK-6965)

................

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=113924

By: Digium Subversion (svnbot) 2008-04-09 15:18:58

Repository: asterisk
Revision: 113925

U   team/group/NoLossCDR-Redux2/channels/chan_h323.c
U   team/group/NoLossCDR-Redux2/channels/chan_usbradio.c
U   team/group/NoLossCDR-Redux2/channels/misdn_config.c

------------------------------------------------------------------------
r113925 | juggie | 2008-04-09 15:18:55 -0500 (Wed, 09 Apr 2008) | 211 lines

Merged revisions 110020,110023,110036,110084,110087,110132,110161,110164,110211,110237,110268,110270,110272,110303,110337,110339,110396,110444 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk

................
r110020 | file | 2008-03-19 14:25:33 -0400 (Wed, 19 Mar 2008) | 14 lines

Merged revisions 110019 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
r110019 | file | 2008-03-19 15:20:28 -0300 (Wed, 19 Mar 2008) | 6 lines

Make sure that the mark bit does not incorrectly cause video frame timestamps to be calculated as if they are audio frames.
(closes issue ASTERISK-10940)
Reported by: sperreault
Patches:
     11429-frametype.diff uploaded by qwell (license 4)

........

................
r110023 | russell | 2008-03-19 14:57:16 -0400 (Wed, 19 Mar 2008) | 2 lines

remove svnmerge-blocked property that is not supposed to be here

................
r110036 | file | 2008-03-19 15:13:39 -0400 (Wed, 19 Mar 2008) | 12 lines

Merged revisions 110035 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
r110035 | file | 2008-03-19 16:11:33 -0300 (Wed, 19 Mar 2008) | 4 lines

Add sanity checking for position resuming. We *have* to make sure that the position does not exceed the total number of files present, and we have to make sure that the position's filename is the same as previous. These values can change if a music class is reloaded and give unpredictable behavior.
(closes issue ASTERISK-11136)
Reported by: junky

........

................
r110084 | mmichelson | 2008-03-19 16:34:13 -0400 (Wed, 19 Mar 2008) | 12 lines

Merged revisions 110083 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
r110083 | mmichelson | 2008-03-19 15:33:03 -0500 (Wed, 19 Mar 2008) | 4 lines

Add a missing unlock in the case that memory allocation fails in app_chanspy.
Thanks to Russell for confirming that this was an issue.


........

................
r110087 | jpeeler | 2008-03-19 17:05:24 -0400 (Wed, 19 Mar 2008) | 2 lines

This change adds DNS manager support for registrations not referencing a peer entry. It looks like there is support for DNS manager for realtime peers as well, however it is not implemented correctly. The improper usage occurs when ast_dnsmgr_lookup is called with one of the arguments being an address from the stack to be continually updated. The variable from the stack will go out of scope and dnsmgr will continue to try and update the memory there, causing possible stack corruption. This problem will be worked on next as well as adding DNS manager support for peer entries.

................
r110132 | qwell | 2008-03-19 17:56:15 -0400 (Wed, 19 Mar 2008) | 1 line

Rename very poorly named function to reflect what it actually does.  This was causing quite a bit of confusion for me...
................
r110161 | qwell | 2008-03-19 18:25:34 -0400 (Wed, 19 Mar 2008) | 5 lines

Rename DSP_FEATURE_DTMF_DETECT, because we are *NOT* only detecting DTMF digits.
This was very misleading.

Early cleanup for issue ASTERISK-11413

................
r110164 | russell | 2008-03-19 18:58:33 -0400 (Wed, 19 Mar 2008) | 13 lines

Merged revisions 110163 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
r110163 | russell | 2008-03-19 17:57:59 -0500 (Wed, 19 Mar 2008) | 5 lines

Fix a bug where when calls on the trunk side hang up while on hold, the state
is not properly reflected.

(closes issue ASTERISK-11434, reported by anakaoka, patched by me)

........

................
r110211 | tilghman | 2008-03-19 23:14:59 -0400 (Wed, 19 Mar 2008) | 2 lines

Fix recent trunk breakage

................
r110237 | tilghman | 2008-03-20 01:06:12 -0400 (Thu, 20 Mar 2008) | 5 lines

Upgrade the sounds version; add several directory enhancements:
1) Number of digits to enter can now be configured
2) The digits can now match on both first AND last name, instead of only one or the other
(Closes issue ASTERISK-6965)

................
r110268 | russell | 2008-03-20 13:41:22 -0400 (Thu, 20 Mar 2008) | 27 lines

Add some fixes that I made in regards to wideband codec handling to get
G.722 music on hold working for me.

(issue ASTERISK-11594, reported by milazzo and jsmith, patches by me)

res/res_musiconhold.c:
- I moved a single line so that the sample queue update happened before
  ast_write().  The reason that this was a bug is that the G.722 frame
  originally says it has 320 samples in it (which is correct).  However,
  when the frame is written to a channel that uses RTP, main/rtp.c modifies
  the frame to cut the number of samples in half before it sends it on
  the wire.  This is to account for the stupid incorrect G.722 spec that
  makes it so we have to lie about the number of samples with RTP.  I should
  probably go and re-work the RTP code so it doesn't modify the frame so
  that a bug like this won't happen in the future.  However, this change to
  MOH is harmless.

main/channel.c:
- I made two fixes in regards to generator timing.  Generators use samples
  for timing.  However, this code assumed 8 kHz samples.  In one case, it was
  a hard coded 160 samples, that is now written as the sample rate / 50.  The
  other place was dealing with timing a generator based on frames coming from
  the other direction.  However, that would have only worked if the sample
  rates for the formats in both directions were the same.  The code now takes
  into account that the sample rates may differ, and scales the generator
  samples accordingly.

................
r110270 | russell | 2008-03-20 13:45:29 -0400 (Thu, 20 Mar 2008) | 2 lines

Remove astobj.h from some places where it wasn't needed

................
r110272 | mmichelson | 2008-03-20 14:01:36 -0400 (Thu, 20 Mar 2008) | 3 lines

Add missing unlock


................
r110303 | russell | 2008-03-20 16:08:26 -0400 (Thu, 20 Mar 2008) | 8 lines

Fix a bug when using zaptel timing for playing back files that have a sample rate
other than 8 kHz.  The issue here is that format modules give a "whennext" sample
value, which is used to calculate when to set a timer for to retrieve the next
frame.  However, the zaptel timer operates on 8 kHz samples, so this must be taken
into account.

(another part of issue ASTERISK-11594, reported by milazzo and jsmith, patch by me)

................
r110337 | russell | 2008-03-20 17:55:50 -0400 (Thu, 20 Mar 2008) | 22 lines

Merged revisions 110336 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

................
r110336 | russell | 2008-03-20 16:54:58 -0500 (Thu, 20 Mar 2008) | 14 lines

Merged revisions 110335 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.2

........
r110335 | russell | 2008-03-20 16:53:27 -0500 (Thu, 20 Mar 2008) | 6 lines

Fix some very broken code that was introduced in 1.2.26 as a part of the security
fix.  The dnsmgr is not appropriate here.  The dnsmgr takes a pointer to an address
structure that a background thread continuously updates.  However, in these cases,
a stack variable was passed.  That means that the dnsmgr thread would be continuously
writing to bogus memory.

........

................

................
r110339 | russell | 2008-03-20 18:02:20 -0400 (Thu, 20 Mar 2008) | 3 lines

Use the correct buffer for g722tolin16_sample.  This shouldn't have caused any
problems, but Qwell noticed the typo here.

................
r110396 | russell | 2008-03-20 19:14:13 -0400 (Thu, 20 Mar 2008) | 17 lines

Merged revisions 110395 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
r110395 | russell | 2008-03-20 18:13:56 -0500 (Thu, 20 Mar 2008) | 9 lines

Shorten the ast_waitfor() timeout from 500 ms to 50 ms in the autoservice thread.
This really should not make a difference except in very rare cases.  That case would
be that all of the channels in autoservice are not generating any frames.  In that
case, this change reduces the potential amount of time that a thread waits in
ast_autoservice_stop() for the autoservice thread to wrap back around to the beginning
of its loop.

(closes issue ASTERISK-11689, reported by dimas)

........

................
r110444 | tilghman | 2008-03-20 21:44:38 -0400 (Thu, 20 Mar 2008) | 2 lines

Add note of the added Directory options, from commit 110237 (closes issue ASTERISK-6965)

................

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=113925