Fix memory leak in res_calendar_icalendar

The ICalendar module had a systemic memory leak on each fetch of data from
the ICalendar source. The previous fetched data was not being properly
disposed. This patch makes it so that before each fetch of data, we dispose
of the previously fetched data.

(closes issue ASTERISK-21012)
Reported by: Joel Vandal
Tested by: Joel Vandal
........

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


git-svn-id: http://svn.asterisk.org/svn/asterisk/branches/11@380452 f38db490-d61c-443f-a65b-d21fe96a405b
Perform case insensitive comparisons for T.38 attributes

RFC5347 section 2.5.2 states the following:
...
The attribute "T38MaxBitRate" was once incorrectly registered with
IANA as "T38maxBitRate" (lower-case "m"). In accordance with T.38
examples and common implementation practice, the form "T38MaxBitRate"
SHOULD be generated by implementations conforming to this package.
In general, it is RECOMMENDED that implementations of this package
accept lowercase, uppercase, and mixed upper/lowercase encodings of
all the T.38 attributes.
...

Asterisk currently does not perform case insensitive matching on the T.38
attributes. This causes the T38MaxBitRate attribute to be negotiated at
2400 baud instead of 14400 (or whatever value you actually wanted).

This patch makes it so that when we compare T.38 attributes, we do so in a case
insensitive fashion.

Note that while the issue reporter did not directly write the patch, they
contributed to it (and would have provided one themselves if the license had
gone through a tad faster), and hence get attribution for it.

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

(closes issue ASTERISK-20897)
Reported by: Eric Hill
Tested by: Eric Hill
patches:
  -- uploaded by Eric Hill
........

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


git-svn-id: http://svn.asterisk.org/svn/asterisk/branches/11@380465 f38db490-d61c-443f-a65b-d21fe96a405b
Unregister SIP provider API if module load is declined

A user in #asterisk ran into a problem where a configuration error prevented
the chan_sip module from being loaded. Upon fixing their configuratione error,
they could no longer load the chan_sip module. This was because the
configuration checking happened after the SIP provider was registered with the
Asterisk core, and subsequent attempts to load the SIP module failed as the
provider was already registered.

Since we want to detect any failure in registering chan_sip as early as
possible (as that could be emblematic of a deeper mismatch between module
and Asterisk core), this patch does not change the registration location, but
does ensure that if a module load is declined, we unregister the module as
the SIP api provider.



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