app_chanspy: Documentation Update To Clarify "x" Option

When using the "x" option (specify a DTMF digit to exit the application), it is
not obvious in the documentation that this only works when spying on a channel.
If a channel being used to spy on other channels is waiting to connect to a
channel or is no longer attached to a channel, the DTMF is ignored.

As noted on the issue tracker, since there are workarounds available and this is
a rarely used option we are opting for a documentation change here.

(closes issue ASTERISK-22661)
Reported by: Chris Hillman
Patches:
    asterisk-22661-doc-clarify-chan_spy.diff uploaded by Michael L. Young

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

Merged revisions 408536 from http://svn.asterisk.org/svn/asterisk/branches/1.8


git-svn-id: http://svn.asterisk.org/svn/asterisk/branches/11@408537 f38db490-d61c-443f-a65b-d21fe96a405b
Fix type of roundTripDelay variables
........

Merged revisions 408589 from http://svn.asterisk.org/svn/asterisk/branches/1.8


git-svn-id: http://svn.asterisk.org/svn/asterisk/branches/11@408590 f38db490-d61c-443f-a65b-d21fe96a405b
channel.c: MOH is not working for transferee after attended transfer

Updated the code to check to see if MOH is playing on the transferor and if
so then start it on the channel that replaces it during a masquerade.

Example scenario of the problem:
Alice calls Bob and then Bob begins the attended transfer process into a queue.
Upon going on hold Alice hears music and so does Bob once he is in the queue.
Bob then transfers Alice into the queue and then music for Alice stops even
though she should be hearing it since has now replaced Bob in the queue.

The problem that was occurring is that once the channel was masqueraded the app
(queues, confbridge, etc...) had no way of knowing that the channel had just
been swapped out thus it did not start music for the present channel.

Credit to Olle Johansson for pointing me in the right direction on this issue.

(closes issue ASTERISK-19499)
Reported by: Timo Teräs
Review: https://reviewboard.asterisk.org/r/3226/
........

Merged revisions 408642 from http://svn.asterisk.org/svn/asterisk/branches/1.8


git-svn-id: http://svn.asterisk.org/svn/asterisk/branches/11@408643 f38db490-d61c-443f-a65b-d21fe96a405b
rtp_engine: Output mixup in ${CHANNEL(rtpqos,audio,all)}

Fixed the output of CHANNEL(rtpqos,audio,all) to use txjitter instead
of rxjitter.

(closes issue ASTERISK-23261)
Reported by: rsw686
Patches:
     rtpqos.patch uploaded by rsw686 (license 5887)
........

Merged revisions 408646 from http://svn.asterisk.org/svn/asterisk/branches/1.8


git-svn-id: http://svn.asterisk.org/svn/asterisk/branches/11@408647 f38db490-d61c-443f-a65b-d21fe96a405b
rtp_engine: Dynamic payload change in rtp mapping not supported

Asterisk didn't support the dynamic payload change in rtp mapping in the 200
OK response.

Scenario:
Asterisk sends the INVITE proposing alaw and telephone-event, it proposes
rtpmap:101 for telephone-event.  Peer responds with 2xx, it answers with
alaw and telephone-event also, but it proposes a different rtpmap number
(rtpmap:103) for telephone-event.

Expected Behaviour:
Asterisk should honour the rtpmapping in the response and send DTMF packets
using 103 as payload type for DTMF.

Actual Behaviour: Asterisk sends DTMF packets using payload type 101.

With this patch asterisk now supports changes that can occur in the rtp mapping
in the response.

(closes issue ASTERISK-23279)
Reported by: NITESH BANSAL
Review: https://reviewboard.asterisk.org/r/3225/
Patches:
     dynamic_payload_change.patch uploaded by nbansal (license 6418)


git-svn-id: http://svn.asterisk.org/svn/asterisk/branches/11@408729 f38db490-d61c-443f-a65b-d21fe96a405b
install_prereq: Missing uuid[-dev] for debian distros

Added uuid and uuid-dev to install prereq script.

(closes issue ASTERISK-23255)
Reported by: Rusty Newton


git-svn-id: http://svn.asterisk.org/svn/asterisk/branches/11@408733 f38db490-d61c-443f-a65b-d21fe96a405b
app_forkcdr: ForkCDR v option does not keep CDR variables for subsequent records

When the 'v' option is specified to ForkCDR application, AST_CDR_FLAG_KEEP_VARS
flag is set only for the first CDR in the chain. So ForkCDR works fine with this
option only once. After the second and further calls to ForkCDR, CDR variables
get cleared on all CDRs besides the first one and moved to the newly forked CDR.
It always sets the KEEP_VARS flag on the first CDR in the chain, instead of the
most recent CDR which is used as a base to fork a new CDR.

This patch sets KEEP_VARS flag on the most recent CDR on the stack (the CDR used
for forking).

(closes issue ASTERISK-23260)
Reported by: zvision
Patches:
     app_forkcdr.diff uploaded by zvision (license 5755)
........

Merged revisions 408747 from http://svn.asterisk.org/svn/asterisk/branches/1.8


git-svn-id: http://svn.asterisk.org/svn/asterisk/branches/11@408748 f38db490-d61c-443f-a65b-d21fe96a405b
Remove extra defines of AST_PBX_MAX_STACK.

* Ensure AST_PBX_MAX_STACK is only defined in extconf.h and pbx.h.
* Fix incorrect function parameters in utils/extconf.c.

(closes issue ASTERISK-23141)
Reported by: Maxim
Review: https://reviewboard.asterisk.org/r/3241/
........

Merged revisions 408785 from http://svn.asterisk.org/svn/asterisk/branches/1.8


git-svn-id: http://svn.asterisk.org/svn/asterisk/branches/11@408786 f38db490-d61c-443f-a65b-d21fe96a405b
ignore AST_CONTROL_PVT_CAUSE_CODE without any messages

(closes issue ASTERISK-23336)
Reported by: Alexander Semych



git-svn-id: http://svn.asterisk.org/svn/asterisk/branches/11@408838 f38db490-d61c-443f-a65b-d21fe96a405b