[asterisk-commits] murf: branch group/newcdr r175546 - in /team/group/newcdr: ./ apps/ build_too...

[SVN commits to the Asterisk project]

Author: murf
Date: Fri Feb 13 09:47:56 2009
New Revision: 175546

URL: http://svn.digium.com/svn-view/asterisk?view=rev&rev=175546
Log:
Merged revisions 174945,174948,174951,175058,175089,175121,175125,175127,175188,175250,175255,175295,175298,175334,175344,175368,175408,175411,175475,175508,175512 via svnmerge from 
https://origsvn.digium.com/svn/asterisk/trunk

................
r174945 | mmichelson | 2009-02-11 15:41:01 -0700 (Wed, 11 Feb 2009) | 29 lines

Fix 'd' option for app_dial and add new option to Answer application

The 'd' option would not work for channel types which use RTP to transport
DTMF digits. The only way to allow for this to work was to answer the channel
if we saw that this option was enabled.

I realized that this may cause issues with CDRs, specifically with giving false
dispositions and answer times. I therefore modified ast_answer to take another
parameter which would tell if the CDR should be marked answered.

I also extended this to the Answer application so that the channel may be answered
but not CDRified if desired.

I also modified app_dictate and app_waitforsilence to only answer the channel if it
is not already up, to help not allow for faulty CDR answer times.

All of these changes are going into Asterisk trunk. For 1.6.0 and 1.6.1, however, all
the changes except for the change to the Answer application will go in since we do
not introduce new features into stable branches

(closes issue #14164)
Reported by: DennisD
Patches:
      14164.patch uploaded by putnopvut (license 60)
Tested by: putnopvut

Review: http://reviewboard.digium.com/r/145


................
r174948 | mmichelson | 2009-02-11 16:03:08 -0700 (Wed, 11 Feb 2009) | 20 lines

Fix odd "thank you" sound playing behavior in app_queue.c

If someone has configured the queue to play an position or holdtime
announcement, then it is odd and potentially unexpected to hear a 
"Thank you for your patience" sound when no position or holdtime
was actually announced.

This fixes the announcement so that the "thanks" sound is only played
in the case that a position or holdtime was actually announced.

There is a way that the "thank you" sound can be played without a
position or holdtime, and that is to set announce-frequency to a value
but keep announce-position and announce-holdtime both turned off.

(closes issue #14227)
Reported by: caspy
Patches:
      14227_v3.patch uploaded by putnopvut (license 60)
Tested by: caspy

................
r174951 | mmichelson | 2009-02-11 16:12:57 -0700 (Wed, 11 Feb 2009) | 3 lines

Fix a bit of odd logic for announcing position. Sync with 1.6.0's logic


................
r175058 | phsultan | 2009-02-12 03:31:36 -0700 (Thu, 12 Feb 2009) | 20 lines

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

........
r175029 | phsultan | 2009-02-12 11:16:21 +0100 (Thu, 12 Feb 2009) | 12 lines

Set the initiator attribute to lowercase in our replies when receiving calls.

This attribute contains a JID that identifies the initiator of the GoogleTalk
voice session. The GoogleTalk client discards Asterisk's replies if the 
initiator attribute contains uppercase characters.

(closes issue #13984)
Reported by: jcovert
Patches:
      chan_gtalk.2.patch uploaded by jcovert (license 551)
Tested by: jcovert

........

................
r175089 | phsultan | 2009-02-12 07:25:03 -0700 (Thu, 12 Feb 2009) | 6 lines

Issue a warning message if our candidate's IP is the loopback address.

(closes issue #13985)
Reported by: jcovert
Tested by: phsultan

................
r175121 | mmichelson | 2009-02-12 09:28:06 -0700 (Thu, 12 Feb 2009) | 11 lines

Make lock information for ao2_trylock be more useful and gnarly

Core show locks information involving an ao2_trylock did not
show the function that called ao2_trylock, but would instead
show ao2_trylock as the source of the lock. This is not useful
when trying to debug locking issues.

One bizarre note is that this logic is already in 1.4 but somehow
did not get merged to trunk or the 1.6.X branches.


................
r175125 | russell | 2009-02-12 09:57:25 -0700 (Thu, 12 Feb 2009) | 35 lines

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

........
r175124 | russell | 2009-02-12 10:51:13 -0600 (Thu, 12 Feb 2009) | 27 lines

Don't send DTMF for infinite time if we do not receive an END event.

I thought that this was going to end up being a pretty gnarly fix, but it turns
out that there was actually already a configuration option in rtp.conf, 
dtmftimeout, that was intended to handle this situation.  However, in between 
Asterisk 1.2 and Asterisk 1.4, the code that processed the option got lost.
So, this commit brings it back to life.

The default timeout is 3 seconds.  However, it is worth noting that having
this be configurable at all is not really the recommended behavior in RFC 2833.