directmediapermit/directmediadeny support to restrict which peers can do
directmedia based on ip address. In some networks not all phones are fully
routed, i.e. not all phones can ping each other. This patch adds a way to
restrict directmedia for certain peers between certain networks.

(closes issue #16645)
Reported by: raarts
Patches: 
      directmediapermit.patch uploaded by raarts (license 937)
Tested by: raarts

Review: https://reviewboard.asterisk.org/r/467/


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@264626 65c4cc65-6c06-0410-ace0-fbb531ad65f3

git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@264540 65c4cc65-6c06-0410-ace0-fbb531ad65f3

Nick Lewis pointed out that the patch as committed wouldn't actually include
dynamic logger levels, which was missed by the other reviewers. Thanks!



git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@264497 65c4cc65-6c06-0410-ace0-fbb531ad65f3

From reviewboard:
The problem here is a bit complex, so try to bear with me...

It was noticed by a Digium customer that generic PLC (as configured in
codecs.conf) did not appear to actually be having any sort of benefit when
packet loss was introduced on an RTP stream. I reproduced this issue myself
by streaming a file across an RTP stream and dropping approx. 5% of the
RTP packets. I saw no real difference between when PLC was enabled or disabled
when using wireshark to analyze the RTP streams.

After analyzing what was going on, it became clear that one of the problems
faced was that when running my tests, the translation paths were being set
up in such a way that PLC could not possibly work as expected. To illustrate,
if packets are lost on channel A's read stream, then we expect that PLC will
be applied to channel B's write stream. The problem is that generic PLC can
only be done when there is a translation path that moves from some codec to
SLINEAR. When I would run my tests, I found that every single time, read
and write translation paths would be set up on channel A instead of channel
B. There appeared to be no real way to predict which channel the translation
paths would be set up on.

This is where Kevin swooped in to let me know about the transcode_via_sln
option in asterisk.conf. It is supposed to work by placing a read translation
path on both channels from the channel's rawreadformat to SLINEAR. It also
will place a write translation path on both channels from SLINEAR to the
channel's rawwriteformat. Using this option allows one to predictably set up
translation paths on all channels. There are two problems with this, though.
First and foremost, the transcode_via_sln option did not appear to be working
properly when I was placing a SIP call between two endpoints which did not
share any common formats. Second, even if this option were to work, for PLC
to be applied, there had to be a write translation path that would go from
some format to SLINEAR. It would not work properly if the starting format
of translation was SLINEAR.

The one-line change presented in this review request in chan_sip.c fixed the
first issue for me. The problem was that in sip_request_call, the
jointcapability of the outbound channel was being set to the format passed to
sip_request_call. This is nativeformats of the inbound channel. Because of this,
when ast_channel_make_compatible was called by app_dial, both channels already
had compatibly read and write formats. Thus, no translation path was set up at
the time. My change is to set the jointcapability of the sip_pvt created during
sip_request_call to the intersection of the inbound channel's nativeformats and
the configured peer capability that we determined during the earlier call to
create_addr. Doing this got the translation paths set up as expected when using
transcode_via_sln.

The changes presented in channel.c fixed the second issue for me. First and
foremost, when Asterisk is started, we'll read codecs.conf to see the value of
the genericplc option. If this option is set, and ast_write is called for a
frame with no data, then we will attempt to fill in the missing samples for
the frame. The implementation uses a channel datastore for maintaining the
PLC state and for creating a buffer to store PLC samples in. Even when we
receive a frame with data, we'll call plc_rx so that the PLC state will have
knowledge of the previous voice frame, which it can use as a basis for when
it comes time to actually do a PLC fill-in.

So, reviewers, now I ask for your help. First off, there's the one line change
in chan_sip that I have put in. Is it right? By my logic it seems correct, but
I'm sure someone can tell me why it is not going to work. This is probably the
change I'm least concerned about, though. What concerns me much more is the
set of changes in channel.c. First off, am I even doing it right? When I run
tests, I can clearly see that when PLC is activated, I see a significant increase
in RTP traffic where I would expect it to be. However, in my humble opinion, the
audio sounds kind of crappy whenever the PLC fill-in is done. It sounds worse to
me than when no PLC is used at all. I need someone to review the logic I have used
to be sure that I'm not misusing anything. As far as I can see my pointer arithmetic
is correct, and my use of AST_FRIENDLY_OFFSET should be correct as well, but I'm
sure someone can point out somewhere where I've done something incorrectly.

As I was writing this review request up, I decided to give the code a test run under
valgrind, and I find that for some reason, calls to plc_rx are causing some invalid
reads. Apparently I'm reading past the end of a buffer somehow. I'll have to dig around
a bit to see why that is the case. If it's obvious to someone reviewing, speak up!

Finally, I have one other proposal that is not reflected in my code review. Since
without transcode_via_sln set, one cannot predict or control where a translation
path will be up, it seems to me that the current practice of using PLC only when
transcoding to SLINEAR is not useful. I recommend that once it has been determined
that the method used in this code review is correct and works as expected, then
the code in translate.c that invokes PLC should be removed.

Review: https://reviewboard.asterisk.org/r/622/



git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@264452 65c4cc65-6c06-0410-ace0-fbb531ad65f3

When decode_length returns the length there is a check to see if that
length is negative, if so the decode loop breaks as this means the
limit has been reached.  The problem here is that length is an
unsigned int, so length can never be negative.  This resulted in
an infinite loop.

(issue #17352)



git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@264400 65c4cc65-6c06-0410-ace0-fbb531ad65f3

(AST-377)


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@264379 65c4cc65-6c06-0410-ace0-fbb531ad65f3

https://origsvn.digium.com/svn/asterisk/branches/1.4

........
  r264334 | mnicholson | 2010-05-19 15:01:38 -0500 (Wed, 19 May 2010) | 5 lines
  
  Set quieted flag when receiving a dtmf tone during playback in speechbackground.
  
  (closes issue #16966)
  Reported by: asackheim
........


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@264335 65c4cc65-6c06-0410-ace0-fbb531ad65f3

During deadlock avoidance the sip dialog pvt is locked and
unlocked.  When this occurs we have no guarantee the pvt's owner
is still valid.  We were trying to access the pvt's owner after
this without checking to see if it still existed first. 

(closes issue #17271)
Reported by: under
Patches:
      check_rtp_timeout.diff uploaded by under (license 914)
Tested by: dvossel


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@264331 65c4cc65-6c06-0410-ace0-fbb531ad65f3

https://origsvn.digium.com/svn/asterisk/branches/1.4

........
  r264248 | tilghman | 2010-05-19 12:41:29 -0500 (Wed, 19 May 2010) | 17 lines
  
  Internal timing is now on by default, if you're using DAHDI 2.3 or above.
  
  The reason for ensuring DAHDI 2.3 or above is that this version ensures that
  a timer is always available, whereas in previous versions, it was possible
  for DAHDI to be loaded, but have no drivers to actually generate timing.  If
  internal_timing was turned on in this circumstance, a complete lack of audio
  would result.  This is the reason why internal_timing was not on by default.
  However, now that DAHDI ensures the availability of a timer, there is no
  reason for this setting to be off (and in fact, it solves a great many initial
  user problems).
  
  (closes issue #15932)
   Reported by: dimas
   Patches: 
         20100519__issue15932.diff.txt uploaded by tilghman (license 14)
   Tested by: tilghman
........


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@264249 65c4cc65-6c06-0410-ace0-fbb531ad65f3

(closes issue #17235)
 Reported by: frawd
 Patches: 
       new_dtmf_dsp_len.patch uploaded by frawd (license 610)
       20100518__issue17235.diff.txt uploaded by tilghman (license 14)
 Tested by: frawd


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@264204 65c4cc65-6c06-0410-ace0-fbb531ad65f3

(issue #16009)

git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@264161 65c4cc65-6c06-0410-ace0-fbb531ad65f3

Now that Asterisk modules can dynamically create and destroy logger levels
on demand, it's useful to be able to configure a logger channel (console,
file, whatever) to be able to accept log messages from *all* levels, even
levels created dynamically. This patch adds support for this, by allowing
the '*' level name to be used in logger.conf.

Review: https://reviewboard.asterisk.org/r/663/



git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@264160 65c4cc65-6c06-0410-ace0-fbb531ad65f3

Added the keyword 'all' to the 'channel hangup request' CLI command
so that you can request all channels to be hungup without having to
restart Asterisk.

(closes issue #16009)
Reported by: moy
Patches:
      hangup-all-rev-221688.patch uploaded by moy (license 222)
Tested by: moy, russell

git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@264117 65c4cc65-6c06-0410-ace0-fbb531ad65f3

During the processing of Cisco dtmf the dtmf samples were
not being calculated correctly.  In an attempt to determine
what sample rate was being used, a NULL frame was processed
which caused a crash.  This patch resolves this.

(closes issue #17248)
Reported by: falves11
Patches:
      issue_17248.diff uploaded by dvossel (license 671)



git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@264114 65c4cc65-6c06-0410-ace0-fbb531ad65f3

(closes issue #17359)
Reported by: alecdavis
Patches: 
      bug17359.diff.txt uploaded by alecdavis (license 585)



git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@264031 65c4cc65-6c06-0410-ace0-fbb531ad65f3

https://origsvn.digium.com/svn/asterisk/branches/1.4

........
  r263949 | tilghman | 2010-05-19 01:32:27 -0500 (Wed, 19 May 2010) | 8 lines
  
  Because progress is called multiple times, across several frames, we must persist states when detecting multitone sequences.
  
  (closes issue #16749)
   Reported by: dant
   Patches: 
         dsp.c-bug16749-1.patch uploaded by dant (license 670)
   Tested by: dant
........


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@263950 65c4cc65-6c06-0410-ace0-fbb531ad65f3

git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@263905 65c4cc65-6c06-0410-ace0-fbb531ad65f3

(closes issue #17331)
Reported by: under
Patches:
      utils.diff uploaded by under (license 914)
      segfault_on_logging.diff uploaded by dvossel (license 671)
Tested by: under, dvossel


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@263904 65c4cc65-6c06-0410-ace0-fbb531ad65f3

git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@263860 65c4cc65-6c06-0410-ace0-fbb531ad65f3

git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@263858 65c4cc65-6c06-0410-ace0-fbb531ad65f3

Thanks to Richard for pointing this out.



git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@263810 65c4cc65-6c06-0410-ace0-fbb531ad65f3

git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@263808 65c4cc65-6c06-0410-ace0-fbb531ad65f3

https://origsvn.digium.com/svn/asterisk/branches/1.4

........
  r263769 | jpeeler | 2010-05-18 13:54:58 -0500 (Tue, 18 May 2010) | 10 lines
  
  Modify directory name reading to be interrupted with operator or pound escape.
  
  In the case of accidentally entering the wrong first three letters for the
  reading, users could be very frustrated if the name listing is very long. This
  allows interrupting the reading by pressing 0 or #. 0 will attempt to execute
  a configured operator (o) extension and # will exit and proceed in the
  dialplan.
  
  ABE-2200
........


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@263807 65c4cc65-6c06-0410-ace0-fbb531ad65f3

Cache sound tarfiles in a common directory, such that a clean reinstall does not force a re-download of the tarballs.

(closes issue #15370)
 Reported by: pprindeville
 Patches: 
       asterisk-trunk-bugid15370.patch uploaded by pprindeville (license 347)
 Tested by: pprindeville, tilghman, seanbright


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@263724 65c4cc65-6c06-0410-ace0-fbb531ad65f3

https://origsvn.digium.com/svn/asterisk/branches/1.4

........
  r263639 | mmichelson | 2010-05-17 17:00:28 -0500 (Mon, 17 May 2010) | 10 lines
  
  Fix logic error when checking for a devstate provider.
  
  When using strsep, if one of the list of specified separators is not found,
  it is the first parameter to strsep which is now NULL, not the pointer returned
  by strsep.
  
  This issue isn't especially severe in that the worst it is likely to do is waste
  some cycles when a device with no '/' and no ':' is passed to ast_device_state.
........


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@263640 65c4cc65-6c06-0410-ace0-fbb531ad65f3

........
  r263637 | mmichelson | 2010-05-17 16:48:46 -0500 (Mon, 17 May 2010) | 8 lines
  
  Remove arbitrary size limitation for hints.
  
  (closes issue #17257)
  Reported by: tim_ringenbach
  Patches:
        hints_crash_fix.diff uploaded by tim ringenbach (license 540)
........


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@263638 65c4cc65-6c06-0410-ace0-fbb531ad65f3

(closes issue #17135)
 Reported by: edhorton
 Patches: 
       20100513__issue17135.diff.txt uploaded by tilghman (license 14)
       17135_2.diff uploaded by ebroad (license 878)
 Tested by: edhorton, ebroad


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@263589 65c4cc65-6c06-0410-ace0-fbb531ad65f3

From reviewboard:

Digium has a commercial customer who has made extensive use of the connected party and
redirecting information present in later versions of Asterisk Business Edition and which
is to be in the upcoming 1.8 release. Through their use of the feature, new problems and solutions
have come about. This patch adds several enhancements to maximize usage of the connected party
and redirecting information functionality.

First, Asterisk trunk already had connected line interception macros. These macros allow you to
manipulate connected line information before it was sent out to its target. This patch adds the
same feature except for redirecting information instead.

Second, the ast_callerid and ast_party_id structures have been enhanced to provide a "tag." This
tag can be set with func_callerid, func_connectedline, func_redirecting, and in the case of DAHDI,
mISDN, and SIP channels, can be set in a configuration file. The idea behind the callerid tag is
that it can be set to whatever value the administrator likes. Later, when running connected line
and redirecting macros, the admin can read the tag off the appropriate structure to determine what
action to take. You can think of this sort of like a channel variable, except that instead of having
the variable associated with a channel, the variable is associated with a specific identity within
Asterisk.

Third, app_dial has two new options, s and u. The s option lets a dialplan writer force a specific
caller ID tag to be placed on the outgoing channel. The u option allows the dialplan writer to force
a specific calling presentation value on the outgoing channel.

Fourth, there is a new control frame subclass called AST_CONTROL_READ_ACTION added. This was added
to correct a very specific situation. In the case of SIP semi-attended (blond) transfers, the party
being transferred would not have the opportunity to run a connected line interception macro to
possibly alter the transfer target's connected line information. The issue here was that during a
blond transfer, the SIP transfer code has no bridged channel on which to queue the connected line
update. The way this was corrected was to add this new control frame subclass. Now, we queue an
AST_CONTROL_READ_ACTION frame on the channel on which the connected line interception macro should
be run. When ast_read is called to read the frame, ast_read responds by calling a callback function
associated with the specific read action the control frame describes. In this case, the action taken
is to run the connected line interception macro on the transferee's channel.

Review: https://reviewboard.asterisk.org/r/652/


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@263541 65c4cc65-6c06-0410-ace0-fbb531ad65f3

Sean Bright pointed out that we lost a set of newline characters in commit
190349 on a line I had recently changed. Yay for code review on commits.

(issue #17231, #10961)


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@263460 65c4cc65-6c06-0410-ace0-fbb531ad65f3

https://origsvn.digium.com/svn/asterisk/branches/1.4

........
  r263456 | lmadsen | 2010-05-17 09:35:18 -0500 (Mon, 17 May 2010) | 11 lines
  
  Manager cookies are not compatible with RFC2109.
  
  The Version field in the cookies we're setting contain quotes around the version
  number which is not compatible with RFC2109 and breaks some implementations.
  
  (closes issue #17231)
  Reported by: ecarruda
  Patches:
        manager_rfc2109-trunk-v1.patch uploaded by ecarruda (license 559)
        manager_rfc2109-1.6.2-v1.patch uploaded by ecarruda (license 559)
  Tested by: ecarruda, russell
........


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@263457 65c4cc65-6c06-0410-ace0-fbb531ad65f3

https://origsvn.digium.com/svn/asterisk/branches/1.4

........
  r263374 | lmadsen | 2010-05-17 09:04:57 -0500 (Mon, 17 May 2010) | 8 lines
  
  Update link to new version of core sounds.
  
  The latest version of the core sounds files 1.4.19 now includes the missing
  queue-minute sound file which is called by app_queue but which has been
  missing.
  
  (closes issue #17123)
  Reported by: n8ideas
........


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@263375 65c4cc65-6c06-0410-ace0-fbb531ad65f3

git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@263294 65c4cc65-6c06-0410-ace0-fbb531ad65f3

This adds the following two commands to live_ast:
* rsync [user]@host directory
  Copy over all generated files to <directory> at remote host.
  Would allow running live_ast there. Hence allows separating a build
  machine from a test machine.
* gen-live-asteris: regenerate live/asterisk . Useful if copying over
  files to a different directory.


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@263250 65c4cc65-6c06-0410-ace0-fbb531ad65f3

As pointed out by 'akshayb' on #asterisk-dev, the code here called a list of
bucket entries a 'bucket', and the entries within the bucket were called
'bucket_list'. This made the code very hard to understand without reading
all of it... so I've renamed 'bucket_list' to 'bucket_entry' to clarify the
purpose of the structure.



git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@263208 65c4cc65-6c06-0410-ace0-fbb531ad65f3

Very unfortunate things happen if we add an iax_frame
to the frame queue and let go of the lock before scheduling
the frame's transmit... There is a race condition that
exists where the frame can be removed from the frame_queue
and freed before the transmit is scheduled if we do not
hold on to that lock.  This results in a freed frame
being scheduled for transmit later.



git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@263151 65c4cc65-6c06-0410-ace0-fbb531ad65f3

git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@263069 65c4cc65-6c06-0410-ace0-fbb531ad65f3

Nobody seems to actually test PRI_VERSION. It is only useful for failing PRI
support in chan_dahdi.


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@263028 65c4cc65-6c06-0410-ace0-fbb531ad65f3

git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@262987 65c4cc65-6c06-0410-ace0-fbb531ad65f3

git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@262940 65c4cc65-6c06-0410-ace0-fbb531ad65f3

Thanks to Raymond Burke for pointing it out.


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@262897 65c4cc65-6c06-0410-ace0-fbb531ad65f3