Clear the DTMF sending digit tracking on off nominal paths

In certain situations, when the RTP engine goes to send a DTMF end digit
it may be in a situation where the remote address is no longer available,
or the digit that was supposed to be sent is invalid. In such cases, we
need to clear the RTP counters appropriately. Otherwise, when the RTP
source is set again, we'll continue to think that we're in the middle of
sending a DTMF digit, which can confuse the remote party (signficantly).

(closes issue ASTERISK-21522)
Reported by: Corey Farrell
patches:
  rtp_dtmf_process_end.patch uploaded by Corey Farrell (License 5909)
........

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

Merged revisions 387216 from http://svn.asterisk.org/svn/asterisk/branches/11


git-svn-id: http://svn.asterisk.org/svn/asterisk/trunk@387220 f38db490-d61c-443f-a65b-d21fe96a405b
Cleanup chan_local.c:local_new().

* Remove t and ama local variables.  There is no way they could be
anything other than default because p->owner can only be NULL at this
point.

* Rename tmp and tmp2 to owner and chan respectively.

* Remove redundant initialization of channel context, exten, priority.


git-svn-id: http://svn.asterisk.org/svn/asterisk/trunk@387260 f38db490-d61c-443f-a65b-d21fe96a405b
Simplify chan_local.c:manager_optimize_away() using ao2_find().


git-svn-id: http://svn.asterisk.org/svn/asterisk/trunk@387261 f38db490-d61c-443f-a65b-d21fe96a405b