configure: Undefine FORTIFY_SOURCE prior to defining it for patched gcc

Some distributions of Linux patch gcc to define FORTIFY_SOURCE when gcc is
executed with optimization. This "help" unfortunately results in re-definition
warnings when FORTIFY_SOURCE is later defined in Asterisk's build system. This
patch undefines FORTIFY_SOURCE prior to defining it to prevent this warning.

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

ASTERISK-24032 #close
Reported by: Kilburn
Tested by: Kilburn, wdoekes
patches:
  1.8.diff uploaded by cloos (License 5956)
  10.diff uploaded by cloos (License 5956)
  11.diff uploaded by cloos (License 5956)
  12.diff uploaded by cloos (License 5956)
  13.diff uploaded by cloos (License 5956)
........

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

Merged revisions 421228 from http://svn.asterisk.org/svn/asterisk/branches/11
apps/app_dial: Fix Dial 'z' option

The 'z' option is supposed to disable the dial timeout in the case of a call
forward. Unfortunately, the wrong timeout timer was passed to the do_forward
function, resulting in the option not working.

ASTERISK-24225 #close
Reported by: dimitripietro
Tested by: dimitripietro
patches:
  jira_asterisk_24225_v1.8.patch uploaded by rmudgett (License 5621)
  jira_asterisk_24225_v11.patch uploaded by rmudgett (License 5621)
........

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

Merged revisions 421233 from http://svn.asterisk.org/svn/asterisk/branches/11
apps/app_meetme: Fix crash when publishing MeetMe messages with no channel

The same function, meetme_stasis_generate_msg, handles creating and publishing
Stasis message both when there are channels in the MeetMe conference and when
there are no channels in the conference. When the performance improvement was
made to use cached snapshots, this created a situation where Asterisk would
crash: obtaining a cached snapshot is not NULL tolerant.

This patch restores the previous implementation, which used a NULL safe set
of routines to produce a blob containing the channel snapshot (if available)
and information about the MeetMe conference.

ASTERISK-24234 #close
Reported by: Shaun Ruffell
Tested by: Shaun Ruffell
func_config: Change 'Not Found' message from ERROR to DEBUG

When you call the CONFIG dialplan function with the name of a variable that
doesn't exist in the target context you get an ERROR.  This does nothing but
clutter up the logs with messages that may be perfectly acceptable.  Just
because a variable wasn't in the context doesn't mean it's an error.  Maybei
t's optional or just needs to be defaulted or ignored.

This patch changes the log level from ERROR to DEBUG.  If a dialplan developer
wants to debug their dialplan they still canby setting the console debug level 
as needed.

Tested by: George Joseph
Review: https://reviewboard.asterisk.org/r/3919/
........

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

Merged revisions 421328 from http://svn.asterisk.org/svn/asterisk/branches/11
chan_pjsip: Fix attended transfer connected line name update.

A calls B
B answers
B SIP attended transfers to C
C answers, B and C can see each other's connected line information
B completes the transfer
A has number but no name connected line information about C
  while C has the full information about A

I examined the incoming and outgoing party id information handling of
chan_pjsip and found several issues:

* Fixed ast_sip_session_create_outgoing() not setting up the configured
endpoint id as the new channel's caller id.  This is why party A got
default connected line information.

* Made update_initial_connected_line() use the channel's CALLERID(id)
information.  The core, app_dial, or predial routine may have filled in or
changed the endpoint caller id information.

* Fixed chan_pjsip_new() not setting the full party id information
available on the caller id and ANI party id.  This includes the configured
callerid_tag string and other party id fields.

* Fixed accessing channel party id information without the channel lock
held.

* Fixed using the effective connected line id without doing a deep copy
outside of holding the channel lock.  Shallow copy string pointers can
become stale if the channel lock is not held.

* Made queue_connected_line_update() also update the channel's
CALLERID(id) information.  Moving the channel to another bridge would need
the information there for the new bridge peer.

* Fixed off nominal memory leak in update_incoming_connected_line().

* Added pjsip.conf callerid_tag string to party id information from
enabled trust_inbound endpoint in caller_id_incoming_request().

AFS-98 #close
Reported by: Mark Michelson

Review: https://reviewboard.asterisk.org/r/3913/
ARI: Fix a bug where /channels/{channelID}/continue doesn't execute PBX

If /channels/{channelID}/continue is called on a channel that was originated
without a PBX (such as the ARI command POST channel with a stasis application
argument), the channel will not start dialplan execution. This patch will now
run the PBX out of the stasis execution if the channel doesn't currently have
an active PBX upon continuing.

ASTERISK-24043 #close
Reported by: Krandon Bruse
Review: https://reviewboard.asterisk.org/r/3917/
Patches:
    stasis-continue.diff submitted by Krandon Bruse (license 6631)
AMI Docs: Fix Status channel parameter optionality
........

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

Merged revisions 421443 from http://svn.asterisk.org/svn/asterisk/branches/11
Fix compilation error on certain versions of GCC.
Alter documentation for callerid_privacy to use correct values.
Stasis: Add information to blind transfer event

When a blind transfer occurs that is forced to create a local channel
pair to satisfy the transfer request, information about the local
channel pair is not published. This adds a field to describe that
channel to the blind transfer message struct so that this information
is conveyed properly to consumers of the blind transfer message.

This also fixes a bug in which Stasis() was unable to properly identify
the channel that was replacing an existing Stasis-controlled channel
due to a blind transfer.

Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/3921/
Move evaluation of set_var options in pjsip to the end of channel initialization.

This allows for set_var to override certain defaults such as caller ID and codec
values. This also fixes a test suite regression. The "set_var" test suite test attempted
to use set_var to override caller ID, but a recent change caused that to no longer work.
cli.c: Fix tab completion of "module load" when MALLOC_DEBUG is enabled.

filename_completion_function() returns memory that was not allocated by
the MALLOC_DEBUG allocation tracker so the memory must be freed by
ast_std_free().
........

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

Merged revisions 421602 from http://svn.asterisk.org/svn/asterisk/branches/11
Clean up files that do not end with newlines

Trivial patch to add new lines to several files missing them. This fixes
warnings when compiling with gcc 4.1.2 on CentOS 5.

ASTERISK-24245 #close
Reported by: Shaun Ruffell
patches:
  0002-Trivial-addition-of-newlines-at-end-of-three-files.patch uploaded by Shaun Ruffell (License 5417)
ARI: Fix implicit answer when playback is initiated on unanswered channel

When issuing a POST /channels/{channel_id}/play on a channel that is not
yet answered, ARI is supposed to:
* Queue up an AST_CONTROL_PROGRESS on the channel
* Start up the playback of the media

Instead, we sneak an answer on the channel right before starting playing media.

This is due to ARI's usage of control_streamfile. This function implicitly
answers the channel (and doesn't give ARI the option to stop it). The answering
of the channel here is probably unnecessary:
* app_voicemail, by far the biggest consumer of this function, always answers
  the channels anyway
* control stream file (in res_agi) and ControlPlayback probably shouldn't be
  implicitly answering the channel. Answering should not be tied directly to
  playing back media.

As it turns out, the answering of the channel here is pretty old:
356042    twilson       if (ast_channel_state(chan) != AST_STATE_UP) {
  3087      anthm               res = ast_answer(chan);
180259   tilghman       }

(As in, ancient?)

Note that others ran into this problem and commented about it on various
mailing lists.

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

ASTERISK-24229 #close
Reported by: Matt Jordan
chan_sip: Don't use port derived from fromdomain if it isn't set

If a user does not provide a port in the fromdomain setting, chan_sip will set
the fromdomainport to STANDARD_SIP_PORT (5060). The fromdomainport value will
then get used unilaterally in certain places. This causes issues with TLS,
where the default port is expected to be 5061.

This patch modifies chan_sip such that fromdomainport is only used if it is
not the standard SIP port; otherwise, the port from the SIP pvt's recorded
self IP address is used.

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

ASTERISK-24178 #close
Reported by: Elazar Broad
patches:
  fromdomainport_fix.diff uploaded by Elazar Broad (License 5835)
........

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

Merged revisions 421718 from http://svn.asterisk.org/svn/asterisk/branches/11
Improve consistency of party ID privacy usage.

Prior to this change, the Remote-Party-ID header took the position of
"If caller name and number are not explicitly allowed, then they are private"
and P-Asserted-Identity took the position of
"Caller name and number are only private if marked explicitly so"

Now both mechanisms of conveying party identification use the former approach.
res_musiconhold: Fix reference leaks caused when reloading with REF_DEBUG set

Due to a faulty function for debugging reference decrementing, it was possible
to reduce the refcount on the wrong object if two moh classes of the same name
were in the moh class container.

(closes issue ASTERISK-22252)
Reported by: Walter Doekes
Patches:
    18_moh_debug_ref_patch.diff Uploaded by Jonathan Rose (license 6182)
........

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

Merged revisions 421777 from http://svn.asterisk.org/svn/asterisk/branches/11
Let's try checking the name and number, instead of the name twice.
Ensure after-bridge behavior is correct when moving from Stasis to a non-Stasis bridge.

Because of the departable state of channels that enter Stasis bridges, Stasis has to
take responsibility for directing the channel to its intended after-bridge destination
if the channel moves from a Stasis bridge to a non-Stasis bridge. This change ensures
that when such a move occurs, when the channel leaves the bridging system, any after
bridge gotos are honored.

Review: https://reviewboard.asterisk.org/r/3920
Switch from hostname to an IP address in the SDP origin line.

Using the hostname in the SDP origin line may not satisfy the requirement
of RFC 4566 that we use a FQDN or IP address. This change has us use the
same information from the SDP connection line if possible. If not possible,
we'll use the configured media address. And if that's not possible, we use
the result of a PJLIB call to get the IP address of ourself.

ASTERISK-23994 #close
Reported by Private Name

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