Calling ne_uri_parse allocates memory that needs to be freed with a
corresponding call to ne_uri_free.

ASTERISK-28572 #close

Change-Id: I8a6834da27000a6807d89cb7a157b2a88fcb5e61

ASTERISK-27680

Change-Id: Ifb77912e424fe3710a025c18526fada673ec0b79

Change-Id: I31eee8be30c6b0fc3dadb31111dd47742da8892d

ASTERISK_REGISTER_FILE no longer has any purpose so this commit removes
all traces of it.

Previously exported symbols removed:
* __ast_register_file
* __ast_unregister_file
* ast_complete_source_filename

This also removes the mtx_prof static variable that was declared when
MTX_PROFILE was enabled.  This variable was only used in lock.c so it
is now initialized in that file only.

ASTERISK-26480 #close

Change-Id: I1074af07d71f9e159c48ef36631aa432c86f9966

Git does not support the ability to replace a token with a version
string during check-in. While it does have support for replacing a
token on clone, this is somewhat sub-optimal: the token is replaced
with the object hash, which is not particularly easy for human
consumption. What's more, in practice, the source file version was often
not terribly useful. Generally, when triaging bugs, the overall version
of Asterisk is far more useful than an individual SVN version of a file. As a
result, this patch removes Asterisk's support for showing source file
versions.

Specifically, it does the following:

* Rename ASTERISK_FILE_VERSION macro to ASTERISK_REGISTER_FILE, and
  remove passing the version in with the macro. Other facilities
  than 'core show file version' make use of the file names, such as
  setting a debug level only on a specific file. As such, the act of
  registering source files with the Asterisk core still has use. The
  macro rename now reflects the new macro purpose.

* main/asterisk:
  - Refactor the file_version structure to reflect that it no longer
    tracks a version field.
  - Remove the "core show file version" CLI command. Without the file
    version, it is no longer useful.
  - Remove the ast_file_version_find function. The file version is no
    longer tracked.
  - Rename ast_register_file_version/ast_unregister_file_version to
    ast_register_file/ast_unregister_file, respectively.

* main/manager: Remove value from the Version key of the ModuleCheck
  Action. The actual key itself has not been removed, as doing so would
  absolutely constitute a backwards incompatible change. However, since
  the file version is no longer tracked, there is no need to attempt to
  include it in the Version key.

* UPGRADE: Add notes for:
  - Modification to the ModuleCheck AMI Action
  - Removal of the "core show file version" CLI command

Change-Id: I6cf0ff280e1668bf4957dc21f32a5ff43444a40e

Allow res_calendar_ews to work not only with libneon-0.29 but also
with 0.30.

ASTERISK-24325 #close
Reported by: Tzafrir Cohen

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

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

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

Merged revisions 425288 from http://svn.asterisk.org/svn/asterisk/branches/12
........

Merged revisions 425289 from http://svn.asterisk.org/svn/asterisk/branches/13


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

ASTERISK-23919 #close
Reported by Malcolm Davenport

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



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

This resolves a large number of compiler warnings from GCC 4.10 which
cause the build to fail under dev mode. The vast majority are
signed/unsigned mismatches in printf-style format strings.
........

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

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

Merged revisions 413588 from http://svn.asterisk.org/svn/asterisk/branches/12


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

Much needed was a way to assign id to objects on creation, and
much change was necessary to accomplish it.  Channel uniqueids
and linkedids are split into separate string and creation time
components without breaking linkedid propgation.  This allowed
the uniqueid to be specified by the user interface - and those
values are now carried through to channel creation, adding the
assignedids value to every function in the chain including the
channel drivers. For local channels, the second channel can be
specified or left to default to a ;2 suffix of first.  In ARI,
bridge, playback, and snoop objects can also be created with a
specified uniqueid.

Along the way, the args order to allocating channels was fixed
in chan_mgcp and chan_gtalk, and linkedid is no longer lost as
masquerade occurs.

(closes issue ASTERISK-23120)
Review: https://reviewboard.asterisk.org/r/3191/
........

Merged revisions 410157 from http://svn.asterisk.org/svn/asterisk/branches/12


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

Unlike all other calendar modules, res_calendar_ews fails to extract the Body
information for a calendar item.  This is due, in part, to a quirk in the
schema in the XML - not only does a CalendarItem contain a Body element, but
the CalendarItem exists as a descendant of a different Body element.  The neon
parser was erroneously skipping all Body elements.

This patch fixes that by bypassing Body elements that are not a child of
CalendarItem, and parsing the Body element out if it is a child.

Note that the original patch by Terry Wilson only needed slight modifications
to make it properly pull the Body information out; as such, while I've linked
to the patch that I uploaded for Dmitry, I've attributed the patch to Terry.

(closes issue ASTERISK-19738)
Reported by: Dmitry Burilov
Tested by: Dmitry Burilov
patches:
  calendar_ews_body_2012_10_29.diff uploaded by Terry Wilson (license 6283)
........

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

Merged revisions 375531 from http://svn.asterisk.org/svn/asterisk/branches/10
........

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


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

This patch fixes two problems pointed out by a static analysis tool.

* In chan_dahdi, when an event is handled the index of the sub channel is first
  obtained.  In very off nominal cases, the method that determines the index
  can return a negative value.  In the event handling code, whether or not
  the index returned is valid was being checked after that value was used to
  index into an array.  This patch makes it so the value is checked before
  any indexing is done.

* In res_calendar_ews, sizeof was being passed a pointer instead of the struct to
  determine the amount of memory to allocate.

(issue ASTERISK-19651)
Reported by: Matt Jordan

(closes issue ASTERISK-19671)
Reported by: Matt Jordan
........

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

Merged revisions 366741 from http://svn.asterisk.org/svn/asterisk/branches/10


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

If the XML calendar data returned by a Microsoft Exchange Web Service
specifies an XML Event E-Mail Address ("EmailAddress"), and no e-mail address
is provided, a condition existed where an ast_calendar_attendee struct would
be allocated but not appended to the list of attendees.  Because of that,
the memory associated with the attendee would never be freed.  This patch
frees the memory if no e-mail address is provided.
........

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

Merged revisions 361607 from http://svn.asterisk.org/svn/asterisk/branches/10


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

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

................
  r328247 | lmadsen | 2011-07-14 16:25:31 -0400 (Thu, 14 Jul 2011) | 14 lines
  
  Merged revisions 328209 via svnmerge from 
  https://origsvn.digium.com/svn/asterisk/branches/1.8
  
  ........
    r328209 | lmadsen | 2011-07-14 16:13:06 -0400 (Thu, 14 Jul 2011) | 6 lines
    
    Introduce <support_level> tags in MODULEINFO.
    This change introduces MODULEINFO into many modules in Asterisk in order to show
    the community support level for those modules. This is used by changes committed
    to menuselect by Russell Bryant recently (r917 in menuselect). More information about
    the support level types and what they mean is available on the wiki at
    https://wiki.asterisk.org/wiki/display/AST/Asterisk+Module+Support+States
  ........
................


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

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

........
  r287269 | pitel | 2010-09-17 10:37:49 +0200 (Pá, 17 zář 2010) | 8 lines
  
  Support for HTTP redirects in calendar's URL
  
  libneon does not support HTTP redirects (3xx responses) by default. You must tell it to follow them.
  Also, another little unsigned int fix.
  
  (closes issue #17776)
  Review: https://reviewboard.asterisk.org/r/921/
........
  r287270 | pitel | 2010-09-17 10:42:37 +0200 (Pá, 17 zář 2010) | 6 lines
  
  Asterisk crashing because of double free when EWS request fails
  
  The free is done later in code. I think ast_free() should have built in checks for double free.
  
  (closes issue #17782)
........
  r287271 | pitel | 2010-09-17 10:44:28 +0200 (Pá, 17 zář 2010) | 6 lines
  
  Events are visible after they were removed from EWS calendar
  
  Because we must merge calendar even when it's empty.
  
  (closes issue #17786)
........


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

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

........
  r286617 | pitel | 2010-09-14 08:55:44 +0200 (Út, 14 zář 2010) | 7 lines
  
  Merging events for Exchange web service doesn't work as expected, resulting in only one event in calendar
  
  The solution is to use "global" counter of events, since we do new requests for every event and calendar sync after every request. So now we do sync only after last request.
  
  (closes issue #17877)
  Review: https://reviewboard.asterisk.org/r/916/
........


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

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

See RFC 5545 ch. 3.8.1.2 and 9.

(closes issue #17837)
Review: https://reviewboard.asterisk.org/r/880/


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

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

This uses a modified version of pabelanger's patch that checks for NTLM support
instead, which was added in 0.29.0 which is what is required for
res_calendar_ews.

(closes issue #17391)
Reported by: loloski
Patches: 
      issue17391.patch.v2 uploaded by pabelanger (license 224)
Tested by: twilson


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

This ensures cross-platform compatibility, even among Linux distributions,
which don't always put headers in the same place.

(closes issue #17391)
 Reported by: loloski


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

This commit adds support for calendaring with Exchange Server 2007+ via
Exchange Web Services. Full write support and for querying attendees. Many
thanks to Jan Kaláb for the feature.

(closes issue #17022)
Reported by: pitel
Patches: 
      res_calendar_ews.c uploaded by pitel (license 1008)
Tested by: pitel, twilson

Review: https://reviewboard.asterisk.org/r/557/
Review: https://reviewboard.asterisk.org/r/668/


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