........
  r202601 | mmichelson | 2009-06-23 10:22:35 -0500 (Tue, 23 Jun 2009) | 3 lines
  
  Fix more memory leaks that may result if rtp is not successfully allocated.
........


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

........
  r202572 | mmichelson | 2009-06-23 10:08:27 -0500 (Tue, 23 Jun 2009) | 3 lines
  
  Fix potential memory leak in chan_sip when video rtp is not allocated properly.
........


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

(closes issue #2264)
Reported by: pfn
Patches:
      silent-vm-1.6.2.txt uploaded by pfn (license 810)


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

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

........
  r202496 | russell | 2009-06-22 15:08:53 -0500 (Mon, 22 Jun 2009) | 4 lines
  
  Report CallerID change during a masquerade.
  
  Reported by: markster
........


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

Pointed out by Russell while working on the CEL branch.


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

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

........
  r202414 | russell | 2009-06-22 11:00:00 -0500 (Mon, 22 Jun 2009) | 2 lines
  
  Make Polycom subscription type override check more explicit.
........


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

Modules placed in the priority heap for loading were not properly removed from the linked list.  This resulted in some modules attempting to load twice.



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

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

........
  r202341 | mmichelson | 2009-06-22 09:42:55 -0500 (Mon, 22 Jun 2009) | 26 lines
  
  Fix a situation in which Asterisk would not stop retransmitting 487s.
  
  If a CANCEL were received by Asterisk, we would send a 487 in response
  to the original INVITE and a 200 OK for the CANCEL. If there were a network
  hiccup which caused the 200 OK and the 487 to be lost, then the UA communicating
  with Asterisk may try to retransmit its CANCEL. Asterisk's response to this used
  to be to try sending another 487 to the canceled INVITE and another 200 OK to the
  CANCEL.
  
  The problem here is that the originally-sent 487 was sent "reliably" meaning that
  it will be retransmitted until it is received properly. So when we receive the second
  CANCEL it is likely that the first batch of 487s we sent is still going strong and
  reaches the UA. The result was that the second set of 487s would be retransmitted
  constantly until the maximum number of retries had been reached.
  
  The fix for this is that if we receive a second CANCEL for an INVITE, then we cancel
  the retransmission of the first set of 487s and start a second set. This causes the
  dialog to be terminated reasonably.
  
  (closes issue #14584)
  Reported by: klaus3000
  Patches:
        14584_v2.patch uploaded by mmichelson (license 60)
  Tested by: klaus3000
........
  r202342 | mmichelson | 2009-06-22 09:44:58 -0500 (Mon, 22 Jun 2009) | 3 lines
  
  Remove an extra debug line left from previous commit.
........


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

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

........
  r202336 | mmichelson | 2009-06-22 09:34:05 -0500 (Mon, 22 Jun 2009) | 25 lines
  
  Fix a possible infinite loop in SDP parsing during glare situation.
  
  There was a while loop in get_ip_and_port_from_sdp which was controlled
  by a call to get_sdp_iterate. The loop would exit either if what we were
  searching for was found or if the return was NULL. The problem is that
  get_sdp_iterate never returns NULL. This means that if what we were searching
  for was not present, the loop would run infinitely. This modification of the
  loop fixes the problem.
  
  (closes issue #15213)
  Reported by: schmidts
  
  (closes issue #15349)
  Reported by: samy
  
  (closes issue #14464)
  Reported by: pj
  
  (closes issue #15345)
  Reported by: aragon
  Patches:
        sip_inf_loop.patch uploaded by mmichelson (license 60)
  Tested by: aragon
........


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

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

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

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

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

(closes issue #15355)
Reported by: deuffy


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

In passing, also tweak cdr_unregister() to hold the list lock a bit less time.


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

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

........
  r202022 | mnicholson | 2009-06-19 16:21:15 -0500 (Fri, 19 Jun 2009) | 4 lines
  
  Added deadlock protection to try_suggested_sip_codec in chan_sip.c.
  
  Review: https://reviewboard.asterisk.org/r/287/
........


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

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

........
  r201993 | dvossel | 2009-06-19 15:22:02 -0500 (Fri, 19 Jun 2009) | 8 lines
  
  timestamp was being converted to host order as a short rather than a long
  
  (closes issue #15361)
  Reported by: ffloimair
  Patches:
        ts_issue.diff uploaded by dvossel (license 671)
........


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

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

Reported by Benny Amorsen via the asterisk-users mailing list.
http://lists.digium.com/pipermail/asterisk-users/2009-June/233622.html


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

Add support for allowing an RTP engine to decide on whether it is possible for specific formats to be transcoded for an RTP instance.


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

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

........
  r201828 | tilghman | 2009-06-18 19:40:41 -0500 (Thu, 18 Jun 2009) | 6 lines
  
  If the "h" extension fails, give it another chance in main/pbx.c.
  If the "h" extension fails, give it another chance in main/pbx.c, when it
  returns from the bridge code.  Fixes an issue where the "h" extension may
  occasionally not fire, when a Dial is executed from a Macro.
  Debugged in #asterisk with user tompaw.
........


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

within app_voicemail for directory functions.  It is therefore no longer
necessary for app_directory to be linked against the ODBC libraries (and it
never was necessary for app_directory to be linked against IMAP, though it
was).


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

(closes issue #15320)
 Reported by: chappell
 Patches: 
       cut_fix.patch uploaded by chappell (license 8)
       cut_clarify.patch uploaded by chappell (license 8)


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

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


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

(closes issue #15269)
Reported by: contactmayankjain
Patches:
      patch.txt uploaded by contactmayankjain (license 740)
      memory_leak_stuff.trunk.diff uploaded by dvossel (license 671)
Tested by: contactmayankjain, dvossel




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

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

........
  r201600 | russell | 2009-06-18 10:24:31 -0500 (Thu, 18 Jun 2009) | 29 lines
  
  Fix memory corruption and leakage related reloads of non files mode MoH classes.
  
  For Music on Hold classes that are not files mode, meaning that we are executing
  an application that will feed us audio data, we use a thread to monitor the
  external application and read audio from it.  This thread also makes use of the
  MoH class object.  In the MoH class destructor, we used pthread_cancel() to ask
  the thread to exit.  Unfortunately, the code did not wait to ensure that the
  thread actually went away.  What needed to be done is a pthread_join() to ensure
  that the thread fully cleans up before we proceed.  By adding this one line, we
  resolve two significant problems:
  
    1) Since the thread was never joined, it never fully goes away.  So, on every
       reload of non-files mode MoH, an unused thread was sticking around.
  
    2) There was a race condition here where the application monitoring thread
       could still try to access the MoH class, even though the thread executing
       the MoH reload has already destroyed it.
  
  (issue #15109)
  Reported by: jvandal
  
  (issue #15123)
  Reported by: axisinternet
  
  (issue #15195)
  Reported by: amorsen
  
  (issue AST-208)
........


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

This contains the interface by which we can let an rtp instance know
that it might start receiving audio from a new source. This is similar
in nature to revision 197588 of Asterisk 1.4.

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



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

If a transport type was specified, but no extension, parsing of the extension would return whatever was after the transport rather than defaulting to 's'.

(closes issue #15111)
Reported by: ffs
Patches:
      chan_sip.c_register-parser.patch uploaded by ffs (license 730)
Tested by: ffs, dvossel



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

chan_sip has an option to save the sysname on rtupdate.  This patch copies that same logic to chan_iax.

(closes issue #14837)
Reported by: barthpbx
Patches:
      iax2-rtsavesysname.patch uploaded by barthpbx (license 744)
      rt_iax.diff uploaded by dvossel (license 671)



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

(closes issue #15186)
 Reported by: ajohnson
 Patches: 
       20090528__issue15186.diff.txt uploaded by tilghman (license 14)
 Tested by: ajohnson


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

A recent change to our SDP version comparison made audio not function
on some calls. This was because of a test wherein we were trying to
see if an unsigned value was less than 0. This is a dumb comparison
and arguably the compiler should have warned about it. Alas, though,
it slipped past. Now it's fixed by changing the variable to be a
signed type.

Found by several developers. Tested by mnicholson and dbrooks.



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

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

........
  r201450 | mmichelson | 2009-06-17 14:59:31 -0500 (Wed, 17 Jun 2009) | 9 lines
  
  Change the datastore traversal in ast_do_masquerade to use a safe list traversal.
  
  It is possible for datastore fixup functions to remove the datastore from the list
  and free it. In particular, the queue_transfer_fixup in app_queue does this. While
  I don't yet know of this causing any crashes, it certainly could.
  
  Found while discussing a separate issue with Brian Degenhardt.
........


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

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

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

........
  r201423 | dvossel | 2009-06-17 14:28:12 -0500 (Wed, 17 Jun 2009) | 19 lines
  
  StopMixMonitor race condition (not giving up file immediately)
  
  StopMixMonitor only indicates to the MixMonitor thread to stop
  writing to the file.  It does not guarantee that the recording's
  file handle is available to the dialplan immediately after execution.
  This results in a race condition.  To resolve this, the filestream
  pointer is placed in a datastore on the channel. When StopMixMonitor
  is called, the datastore is retrieved from the channel and the
  filestream is closed immediately before returning to the dialplan.
  Documentation indicating the use of StopMixMonitor to free files
  has been updated as well.
  
  (closes issue #15259)
  Reported by: travisghansen
  Tested by: dvossel
  
  Review: https://reviewboard.asterisk.org/r/283/
........


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

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

........
  r201380 | dbrooks | 2009-06-17 13:45:50 -0500 (Wed, 17 Jun 2009) | 9 lines
  
  Checks for NULL sip_pvt pointer in chan_sip.c->acf_channel_read()
  
  Zombie channels could be passed, and chan_sip.c wasn't checking for it.
  Could crash Asterisk. Now checking for NULL pointer.
  
  (closes issue #15330)
  Reported by: okrief
  Tested by: dbrooks
........


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

During a sip reload, the list of sip_registry objects are
supposed to be traversed, unlinked, and destroyed, but
destruction never takes place due to a ref counting error.
This causes a memory leak when registry items are removed
from sip.conf and reloaded.  While the registries are removed
from the global list, they are not removed from the scheduler.
Because of this, SIP register attempts continue to be sent
out for the item even though it may no longer be in the .conf.

(closes issue #15295)
Reported by: amorsen

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


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

(closes issue #15335)
Reported by: lmadsen

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


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

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

........
  r201261 | kpfleming | 2009-06-17 07:03:25 -0500 (Wed, 17 Jun 2009) | 9 lines
  
  Correct AST_LIST_APPEND_LIST behavior when list to be appended is empty.
  
  When the list to be appended is empty, and the list to be appended to is *not*,
  AST_LIST_APPEND_LIST would actually cause the target list to become broken,
  and no longer have a pointer to its last entry. This patch fixes the problem.
  
  (reported by Stanislaw Pitucha on the asterisk-dev mailing list)
........


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

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