Age | Commit message (Collapse) | Author | Files | Lines |
|
https://origsvn.digium.com/svn/asterisk/trunk
................
r271903 | mnicholson | 2010-06-22 12:35:17 -0500 (Tue, 22 Jun 2010) | 15 lines
Merged revisions 271902 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r271902 | mnicholson | 2010-06-22 12:31:57 -0500 (Tue, 22 Jun 2010) | 8 lines
Decrease the module ref count in sip_hangup when SIP_DEFER_BYE_ON_TRANSFER is set. This is necessary to keep the ref count correct.
(closes issue #16815)
Reported by: rain
Patches:
chan_sip-unref-fix.diff uploaded by rain (license 327) (modified)
Tested by: rain
........
................
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@271904 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
................
r271690 | mnicholson | 2010-06-22 07:58:28 -0500 (Tue, 22 Jun 2010) | 18 lines
Merged revisions 271689 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r271689 | mnicholson | 2010-06-22 07:52:27 -0500 (Tue, 22 Jun 2010) | 8 lines
Modify chan_sip's packet generation api to automatically calculate the Content-Length. This is done by storing packet content in a buffer until it is actually time to send the packet, at which time the size of the packet is calculated. This change was made to ensure that the Content-Length is always correct.
(closes issue #17326)
Reported by: kenner
Tested by: mnicholson, kenner
Review: https://reviewboard.asterisk.org/r/693/
........
This change also adds an ast_str_copy_string() function (similar to ast_copy_string), that copies one ast_str into another, properly handling embedded nulls.
................
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@271691 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
........
r269307 | rmudgett | 2010-06-09 11:54:38 -0500 (Wed, 09 Jun 2010) | 12 lines
Eliminate deadlock potential in dahdi_fixup().
Calling dahdi_indicate() within dahdi_fixup() while the owner pointers are
in a potentially inconsistent state is a potentially bad thing in
principle.
However, calling dahdi_indicate() when the channel private lock is already
held can cause a deadlock if the PRI lock is needed because
dahdi_indicate() will also get the channel private lock. The pri_grab()
function assumes that the channel private lock is held once to avoid
deadlock.
........
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@271338 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
................
r270981 | qwell | 2010-06-16 16:10:48 -0500 (Wed, 16 Jun 2010) | 11 lines
Merged revisions 270980 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r270980 | qwell | 2010-06-16 16:10:09 -0500 (Wed, 16 Jun 2010) | 4 lines
Need to lock the agent chan before access its internal bits.
Pointed out by russellb on asterisk-dev mailing list.
........
................
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@270982 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
................
r270867 | dvossel | 2010-06-16 12:36:51 -0500 (Wed, 16 Jun 2010) | 28 lines
Merged revisions 270866 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r270866 | dvossel | 2010-06-16 12:35:29 -0500 (Wed, 16 Jun 2010) | 22 lines
fixes chan_iax2 race condition
There is code in chan_iax2.c that attempts to guarantee that only a single
active thread will handle a call number at a time. This code works once
the thread is added to an active_list of threads, but we are not currently
guaranteed that a newly activated thread will enter the active_list immediately
because it is left up to the thread to add itself after frames have been
queued to it. This means that if two frames come in for the same call number
at the same time, it is possible for them to grab two separate threads because
the first thread did not add itself to the active_list fast enough. This
causes some pretty complex problems.
This patch resolves this race condition by immediately adding an activated
thread to the active_list within the network thread and only depending on
the thread to remove itself once it is done processing the frames queued to
it. By doing this we are guaranteed that if another frame for the same call
number comes in at the same time, that this thread will immediately be found
in the active_list of threads.
Review: https://reviewboard.asterisk.org/r/720/
........
................
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@270868 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
........
r270658 | twilson | 2010-06-15 15:18:04 -0500 (Tue, 15 Jun 2010) | 20 lines
Make contactdeny apply to src ip when nat=yes
chan_sip's "contactdeny" feature screens the "to be registered contact".
In case of nat=yes it should not use the address information from the
Contact header (which is not used at all for routing), but the source
IP address of the request.
Thus, if nat=yes and a client sends a request from a denied IP address
(e.g. by spoofing the src-IP address) it can bypass the screening.
This commit makes contactdeny apply to the src ip when nat=yes instead.
(closes issue #17276)
Reported by: klaus3000
Patches:
patch-asterisk-trunk-contactdeny.txt uploaded by klaus3000 (license 65)
Tested by: klaus3000
Review: [full review board URL with trailing slash]
........
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@270693 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
................
r269497 | russell | 2010-06-09 17:19:20 -0500 (Wed, 09 Jun 2010) | 9 lines
Merged revisions 269495 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r269495 | russell | 2010-06-09 17:18:37 -0500 (Wed, 09 Jun 2010) | 2 lines
Don't stop Asterisk if chan_oss fails to register 'Console' (due to another channel driver already claiming it).
........
................
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@269502 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
........
r268817 | tilghman | 2010-06-07 17:47:13 -0500 (Mon, 07 Jun 2010) | 9 lines
Mailbox list would previously grow at each reload, containing duplicates.
Also, optimize the allocation of mailboxes to avoid additional memory structures.
(closes issue #16320)
Reported by: Marquis
Patches:
20100525__issue16320.diff.txt uploaded by tilghman (license 14)
........
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@268819 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
This is what caused a bunch of tests to fail on 1.6.2. They expected a console
channel driver, but chan_oss was failing to load.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@268815 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
........
r268495 | tilghman | 2010-06-05 19:37:30 -0500 (Sat, 05 Jun 2010) | 2 lines
Finally track down and eliminate the "FRACK! warnings from chan_iax2".
........
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@268496 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
........
r267537 | russell | 2010-06-03 12:31:41 -0500 (Thu, 03 Jun 2010) | 2 lines
Don't stop Asterisk if chan_usbradio isn't configured.
........
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@267538 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
........
r267490 | russell | 2010-06-03 12:05:30 -0500 (Thu, 03 Jun 2010) | 2 lines
Remove a line that was killing Asterisk on startup.
........
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@267491 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
........
r267445 | russell | 2010-06-03 09:48:09 -0500 (Thu, 03 Jun 2010) | 2 lines
Comment out a rule that likes to run implicitly unnecessarily, breaking builds
........
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@267446 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
........
r267352 | russell | 2010-06-02 17:46:37 -0500 (Wed, 02 Jun 2010) | 7 lines
try to fix some random chan_h323 compilation failures
After some debugging, the random chan_h323 build failures appear to be due
to complications introduced by some chan_h323 specific build stuff getting
triggered during a clean. Simplify this by moving the h323 clean commands
down into channels/makefile.
........
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@267353 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
........
r266292 | dvossel | 2010-05-28 12:55:38 -0500 (Fri, 28 May 2010) | 9 lines
fixes crash when creation of UDPTL fails
(closes issue #17264)
Reported by: falves11
Patches:
issue_17264_reviewboard_fix.diff uploaded by dvossel (license 671)
issue_17264_1.6.2_reviewboard_fix.diff uploaded by dvossel (license 671)
Tested by: falves11
........
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@266293 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
........
r266006 | dvossel | 2010-05-26 13:32:51 -0500 (Wed, 26 May 2010) | 8 lines
fixes failed SIP Directed pickup resulting in dead channel
(closes issue #17339)
Reported by: one47
Patches:
sip_magic_pickup2 uploaded by one47 (license 23)
Tested by: one47, dvossel
........
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@266007 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
........
r265842 | mmichelson | 2010-05-26 09:41:55 -0500 (Wed, 26 May 2010) | 9 lines
Re-enable "always" option for videosupport option in sip.conf.
(closes issue #17016)
Reported by: twilson
Patches:
17016.patch uploaded by mmichelson (license 60)
Tested by: devmod
........
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@265890 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
........
r265698 | mmichelson | 2010-05-25 15:59:04 -0500 (Tue, 25 May 2010) | 12 lines
Properly use peer's outboundproxy for outbound REGISTERs.
The logic used in transmit_register to get the outboundproxy for a peer
was flawed since this value would be overridden shortly afterwards when
create_addr was called.
In addition, this also fixes some logic used when parsing users.conf so
that the peer name is placed in the internally-generated register string
so that an outboundproxy set in the Asterisk GUI will be used for outbound
REGISTERs.
........
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@265699 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
(closes issue 0017394)
Reported by: aragon
Patches:
half_buffer_fix.diff uploaded by dvossel (license 671)
Tested by: aragon
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@265615 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
........
r265451 | mmichelson | 2010-05-24 17:05:15 -0500 (Mon, 24 May 2010) | 8 lines
Print openh323 log to the Asterisk console.
(closes issue #17109)
Reported by: under
Patches:
logstream.diff uploaded by under (license 914)
........
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@265452 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
........
r265449 | mmichelson | 2010-05-24 16:44:30 -0500 (Mon, 24 May 2010) | 11 lines
Allow type=user SIP endpoints to be loaded properly from realtime.
(closes issue #16021)
Reported by: Guggemand
Patches:
realtime-type-fix.patch uploaded by Guggemand (license 897)
(altered by me slightly to avoid ref leaks)
Tested by: Guggemand
........
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@265450 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
........
r265087 | mmichelson | 2010-05-21 15:38:14 -0500 (Fri, 21 May 2010) | 7 lines
Be sure to set the sin_family on the proxy when allocating.
(closes issue #17157)
Reported by: stuarth
........
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@265088 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
........
r264452 | mmichelson | 2010-05-19 16:29:08 -0500 (Wed, 19 May 2010) | 86 lines
Fix transcode_via_sln option with SIP calls and improve PLC usage.
From reviewboard:
The problem here is a bit complex, so try to bear with me...
It was noticed by a Digium customer that generic PLC (as configured in
codecs.conf) did not appear to actually be having any sort of benefit when
packet loss was introduced on an RTP stream. I reproduced this issue myself
by streaming a file across an RTP stream and dropping approx. 5% of the
RTP packets. I saw no real difference between when PLC was enabled or disabled
when using wireshark to analyze the RTP streams.
After analyzing what was going on, it became clear that one of the problems
faced was that when running my tests, the translation paths were being set
up in such a way that PLC could not possibly work as expected. To illustrate,
if packets are lost on channel A's read stream, then we expect that PLC will
be applied to channel B's write stream. The problem is that generic PLC can
only be done when there is a translation path that moves from some codec to
SLINEAR. When I would run my tests, I found that every single time, read
and write translation paths would be set up on channel A instead of channel
B. There appeared to be no real way to predict which channel the translation
paths would be set up on.
This is where Kevin swooped in to let me know about the transcode_via_sln
option in asterisk.conf. It is supposed to work by placing a read translation
path on both channels from the channel's rawreadformat to SLINEAR. It also
will place a write translation path on both channels from SLINEAR to the
channel's rawwriteformat. Using this option allows one to predictably set up
translation paths on all channels. There are two problems with this, though.
First and foremost, the transcode_via_sln option did not appear to be working
properly when I was placing a SIP call between two endpoints which did not
share any common formats. Second, even if this option were to work, for PLC
to be applied, there had to be a write translation path that would go from
some format to SLINEAR. It would not work properly if the starting format
of translation was SLINEAR.
The one-line change presented in this review request in chan_sip.c fixed the
first issue for me. The problem was that in sip_request_call, the
jointcapability of the outbound channel was being set to the format passed to
sip_request_call. This is nativeformats of the inbound channel. Because of this,
when ast_channel_make_compatible was called by app_dial, both channels already
had compatibly read and write formats. Thus, no translation path was set up at
the time. My change is to set the jointcapability of the sip_pvt created during
sip_request_call to the intersection of the inbound channel's nativeformats and
the configured peer capability that we determined during the earlier call to
create_addr. Doing this got the translation paths set up as expected when using
transcode_via_sln.
The changes presented in channel.c fixed the second issue for me. First and
foremost, when Asterisk is started, we'll read codecs.conf to see the value of
the genericplc option. If this option is set, and ast_write is called for a
frame with no data, then we will attempt to fill in the missing samples for
the frame. The implementation uses a channel datastore for maintaining the
PLC state and for creating a buffer to store PLC samples in. Even when we
receive a frame with data, we'll call plc_rx so that the PLC state will have
knowledge of the previous voice frame, which it can use as a basis for when
it comes time to actually do a PLC fill-in.
So, reviewers, now I ask for your help. First off, there's the one line change
in chan_sip that I have put in. Is it right? By my logic it seems correct, but
I'm sure someone can tell me why it is not going to work. This is probably the
change I'm least concerned about, though. What concerns me much more is the
set of changes in channel.c. First off, am I even doing it right? When I run
tests, I can clearly see that when PLC is activated, I see a significant increase
in RTP traffic where I would expect it to be. However, in my humble opinion, the
audio sounds kind of crappy whenever the PLC fill-in is done. It sounds worse to
me than when no PLC is used at all. I need someone to review the logic I have used
to be sure that I'm not misusing anything. As far as I can see my pointer arithmetic
is correct, and my use of AST_FRIENDLY_OFFSET should be correct as well, but I'm
sure someone can point out somewhere where I've done something incorrectly.
As I was writing this review request up, I decided to give the code a test run under
valgrind, and I find that for some reason, calls to plc_rx are causing some invalid
reads. Apparently I'm reading past the end of a buffer somehow. I'll have to dig around
a bit to see why that is the case. If it's obvious to someone reviewing, speak up!
Finally, I have one other proposal that is not reflected in my code review. Since
without transcode_via_sln set, one cannot predict or control where a translation
path will be up, it seems to me that the current practice of using PLC only when
transcoding to SLINEAR is not useful. I recommend that once it has been determined
that the method used in this code review is correct and works as expected, then
the code in translate.c that invokes PLC should be removed.
Review: https://reviewboard.asterisk.org/r/622/
........
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@264453 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
........
r264331 | dvossel | 2010-05-19 14:21:04 -0500 (Wed, 19 May 2010) | 13 lines
fixes crash in check_rtp_timeout
During deadlock avoidance the sip dialog pvt is locked and
unlocked. When this occurs we have no guarantee the pvt's owner
is still valid. We were trying to access the pvt's owner after
this without checking to see if it still existed first.
(closes issue #17271)
Reported by: under
Patches:
check_rtp_timeout.diff uploaded by under (license 914)
Tested by: dvossel
........
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@264332 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@263293 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
........
r263069 | rmudgett | 2010-05-13 17:01:36 -0500 (Thu, 13 May 2010) | 1 line
Fix inverted logic in cli command: ss7 set debug on/off
........
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@263070 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
........
r262897 | russell | 2010-05-13 10:36:12 -0500 (Thu, 13 May 2010) | 4 lines
Fix an off by one error that causes a crash.
Thanks to Raymond Burke for pointing it out.
........
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@262898 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
........
r262414 | pabelanger | 2010-05-11 15:26:17 -0400 (Tue, 11 May 2010) | 8 lines
Improve logging information for misconfigured contexts
(closes issue #17238)
Reported by: pprindeville
Patches:
chan_sip-bug17238.patch uploaded by pprindeville (license 347)
Tested by: pprindeville
........
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@262415 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
........
r262236 | dvossel | 2010-05-10 13:36:10 -0500 (Mon, 10 May 2010) | 11 lines
fixes crash in chan_console
There is a race condition between console_hangup()
and start_stream(). It is possible for console_hangup()
to be called and then the stream thread to begin after the hangup.
To avoid this a check in start_stream() to make sure the pvt-owner
still exists while the pvt lock is held is made. If the owner
is gone that means the channel hung up and start_stream should
be aborted.
........
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@262237 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
........
r261560 | tilghman | 2010-05-06 10:39:10 -0500 (Thu, 06 May 2010) | 8 lines
Permit more lines within a SIP body to be parsed.
The example given within the related issue showed 120 lines, which was mostly
a result of the body being XML.
(closes issue #17179)
Reported by: khw
........
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@261563 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
........
r261451 | tzafrir | 2010-05-06 10:27:31 +0300 (ה', 06 מאי 2010) | 4 lines
When failing to configure, don't destroy 'cfg' twice
Fixes a crash when some config section had an incorrect channel config.
........
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@261453 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
................
r261314 | pabelanger | 2010-05-05 14:43:03 -0400 (Wed, 05 May 2010) | 19 lines
Merged revisions 261274 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r261274 | pabelanger | 2010-05-05 12:42:22 -0400 (Wed, 05 May 2010) | 12 lines
Registration fix for SIP realtime.
Make sure realtime fields are not empty.
(closes issue #17266)
Reported by: Nick_Lewis
Patches:
chan_sip.c-realtime.patch uploaded by Nick Lewis (license 657)
Tested by: Nick_Lewis, sberney
Review: https://reviewboard.asterisk.org/r/643/
........
................
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@261315 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
........
r254450 | kpfleming | 2010-03-25 10:27:31 -0500 (Thu, 25 Mar 2010) | 49 lines
Improve handling of T.38 re-INVITEs that arrive before a T.38-capable
application is executing on a channel.
This patch addresses an issue found during working with end-users
using res_fax. If an incoming call is answered in the dialplan, or
jumps to the 'fax' extension due to reception of a CNG tone (with
faxdetect enabled), and then the remote endpoint sends a T.38
re-INVITE, it is possible for the channel's T.38 state to be
'T38_STATE_NEGOTIATING' when the application starts up. Unfortunately,
even if the application wants to use T.38, it can't respond to the
peer's negotiation request, because the AST_CONTROL_T38_PARAMETERS
control frame that chan_sip sent originally has been lost, and the
application needs the content of that frame to be able to formulate a
reply.
This patch adds a new 'request' type to AST_CONTROL_T38_PARAMETERS,
AST_T38_REQUEST_PARMS. If the application sends this request, chan_sip
will re-send the original control frame (with
AST_T38_REQUEST_NEGOTIATE as the request type), and the application
can respond as normal. If this occurs within the five second timeout
in chan_sip, the automatic cancellation of the peer reinvite will be
stopped, and the application will 'own' the negotiation process from
that point onwards.
This also improves the code path in chan_sip to allow sip_indicate(),
when called for AST_CONTROL_T38_PARAMETERS, to be able to return a
non-zero response, which should have been in place before since the
control frame *can* fail to be processed properly. It also modifies
ast_indicate() to return whatever result the channel driver returned
for this control frame, rather than converting all non-zero results
into '-1'. Finally, the new request type intentionally returns a
positive value, so that an application that sends
AST_T38_REQUEST_PARMS can know for certain whether the channel driver
accepted it and will be replying with a control frame of its own, or
whether it was ignored (if the sip_indicate()/ast_indicate() path had
properly supported failure responses before, this would not be
necessary).
This patch also modifies res_fax to take advantage of the new request.
In addition, this patch makes sip_t38_abort() actually lock the
private structure before doing its work... bad programmer, no donut.
This patch also enhances chan_sip's 'faxdetect' support to allow
triggering on T.38 re-INVITEs received as well as CNG tone detection.
Review: https://reviewboard.asterisk.org/r/556/
........
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@260884 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
................
r260437 | jpeeler | 2010-04-30 17:36:49 -0500 (Fri, 30 Apr 2010) | 18 lines
Merged revisions 260434 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r260434 | jpeeler | 2010-04-30 17:22:46 -0500 (Fri, 30 Apr 2010) | 11 lines
Ensure channel state is not incorrectly set in the case of a very early answer.
The needringing bit was being read in dahdi_read after answering thereby
setting the state to ringing from up. This clears needringing upon answering
so that is no longer possible.
(closes issue #17067)
Reported by: tzafrir
Patches:
needringing.diff uploaded by tzafrir (license 46)
........
................
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@260441 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
................
r260231 | rmudgett | 2010-04-29 17:44:14 -0500 (Thu, 29 Apr 2010) | 33 lines
Merged revisions 260195 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r260195 | rmudgett | 2010-04-29 17:11:47 -0500 (Thu, 29 Apr 2010) | 26 lines
DTMF CallerID detection problems.
The code handling DTMF CallerID drops digits on long CallerID numbers and
may timeout waiting for the first ring with shorter numbers.
The DTMF emulation mode was not turned off when processing DTMF CallerID.
When the emulation code gets behind in processing the DTMF digits it can
skip a digit.
For shorter numbers, the timeout may have been too short. I increased it
from 2 seconds to 4 seconds. Four seconds is a typical time between rings
for many countries.
(closes issue #16460)
Reported by: sum
Patches:
issue16460.patch uploaded by rmudgett (license 664)
issue16460_v1.6.2.patch uploaded by rmudgett (license 664)
Tested by: sum, rmudgett
Review: https://reviewboard.asterisk.org/r/634/
JIRA SWP-562
JIRA AST-334
JIRA SWP-901
........
................
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@260234 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
........
r259957 | mmichelson | 2010-04-28 17:34:15 -0500 (Wed, 28 Apr 2010) | 11 lines
Don't override peer context with domain context.
(closes issue #17040)
Reported by: pprindeville
Patches:
asterisk-1.6-bugid17040.patch uploaded by pprindeville (license 347)
Tested by: pprindeville
Review: https://reviewboard.asterisk.org/r/565/
........
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@259959 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
................
r259870 | dvossel | 2010-04-28 16:20:03 -0500 (Wed, 28 Apr 2010) | 39 lines
Merged revisions 259858 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r259858 | dvossel | 2010-04-28 16:16:03 -0500 (Wed, 28 Apr 2010) | 33 lines
resolves deadlocks in chan_local
Issue_1.
In the local_hangup() 3 locks must be held at the same time... pvt, pvt->chan,
and pvt->owner. Proper deadlock avoidance is done when the channel to hangup
is the outbound chan_local channel, but when it is not the outbound channel we
have an issue... We attempt to do deadlock avoidance only on the tech pvt, when
both the tech pvt and the pvt->owner are locked coming into that loop. By
never giving up the pvt->owner channel deadlock avoidance is not entirely possible.
This patch resolves that by doing deadlock avoidance on both the pvt->owner and the pvt
when trying to get the pvt->chan lock.
Issue_2.
ast_prod() is used in ast_activate_generator() to queue a frame on the channel
and make the channel's read function get called. This function is used in
ast_activate_generator() while the channel is locked, which mean's the channel
will have a lock both from the generator code and the frame_queue code by the
time it gets to chan_local.c's local_queue_frame code... local_queue_frame
contains some of the same crazy deadlock avoidance that local_hangup requires,
and this recursive lock prevents that deadlock avoidance from happening correctly.
This patch removes ast_prod() from the channel lock so only one lock is held during
the local_queue_frame function.
(closes issue #17185)
Reported by: schmoozecom
Patches:
issue_17185_v1.diff uploaded by dvossel (license 671)
issue_17185_v2.diff uploaded by dvossel (license 671)
Tested by: schmoozecom, GameGamer43
Review: https://reviewboard.asterisk.org/r/631/
........
................
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@259899 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
................
r259538 | rmudgett | 2010-04-27 17:18:09 -0500 (Tue, 27 Apr 2010) | 18 lines
Merged revisions 259531 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r259531 | rmudgett | 2010-04-27 16:53:07 -0500 (Tue, 27 Apr 2010) | 11 lines
DAHDI "WARNING" message is confusing and vague
"WARNING[28406]: chan_dahdi.c:6873 ss_thread: CallerID feed failed: Success"
Changed the warning to "Failed to decode CallerID on channel 'name'". The
message before it is likely more specific about why the CallerID decode
failed.
SWP-501
AST-283
........
................
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@259616 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
................
r259307 | rmudgett | 2010-04-27 13:29:33 -0500 (Tue, 27 Apr 2010) | 21 lines
Merged revisions 259270 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r259270 | rmudgett | 2010-04-27 13:14:54 -0500 (Tue, 27 Apr 2010) | 14 lines
hidecalleridname parameter in chan_dahdi.conf
Issue #7321 implements a new chan_dahdi configuration option. However, a
change mentioned in the issue was never implemented. This is the change
that will allow the feature to work.
I added a note to chan_dahdi.conf.sample about the feature.
(closes issue #17143)
Reported by: djensen99
Patches:
diff.txt uploaded by djensen99 (license NA) (One line change)
Tested by: djensen99
........
................
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@259310 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
........
r258934 | lmadsen | 2010-04-26 10:59:34 -0500 (Mon, 26 Apr 2010) | 7 lines
Small error in the T.140 RTP port verbose log.
(closes issue #16988)
Reported by: frawd
Patches:
chan_sip_sdp_verbose_fix.diff uploaded by frawd (license 610)
Tested by: russell
........
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@258935 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
........
r258305 | dvossel | 2010-04-21 13:13:36 -0500 (Wed, 21 Apr 2010) | 12 lines
fixes issue with double "sip:" in header field
This is a clear mistake in logic. Future discussions
about how to avoid having to handle uri's like this
should take place in the future, but this fix needs
to go in for now.
(closes issue #15847)
Reported by: ebroad
Patches:
doublesip.patch uploaded by ebroad (license 878)
........
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@258314 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
................
r257493 | tilghman | 2010-04-15 15:30:15 -0500 (Thu, 15 Apr 2010) | 20 lines
Merged revisions 257467 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r257467 | tilghman | 2010-04-15 15:24:50 -0500 (Thu, 15 Apr 2010) | 13 lines
Don't recreate peer, when responding to a repeated deregistration attempt.
When a reply to a deregistration is lost in transmit, the client retries the
deregistration. Previously, this would cause a realtime/autocreate peer to be
loaded back into memory, after it had already been correctly purged. Instead,
we just want to resend the reply without loading the peer.
(closes issue #16908)
Reported by: kkm
Patches:
20100412__issue16908.diff.txt uploaded by tilghman (license 14)
Tested by: kkm
........
................
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@257510 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
........
r257191 | tilghman | 2010-04-13 14:17:48 -0500 (Tue, 13 Apr 2010) | 10 lines
Also unref the pvt when we delete the provisional keepalive job.
(closes issue #16774)
Reported by: kowalma
Patches:
20100315__issue16774.diff.txt uploaded by tilghman (license 14)
Tested by: falves11, jamicque
Review: https://reviewboard.asterisk.org/r/591/
........
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@257210 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
The bug is exposed if MFC/R2 support is built into asterisk (i.e.,
openr2.h is present in the include path). Code that unconditionally
clears the CallerID name and number is included.
Also fixed a malformed if test in mkintf() added by issue 15883.
Converted the if statement to a switch statement for clarity.
Regression of the issue 15883 fix.
(closes issue #16968)
Reported by: grecco
Patches:
issue16968.patch uploaded by rmudgett (license 664)
(closes issue #16747)
Reported by: viniciusfontes
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@256368 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
................
r256265 | rmudgett | 2010-04-05 19:39:44 -0500 (Mon, 05 Apr 2010) | 12 lines
Merged revisions 256225 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r256225 | rmudgett | 2010-04-05 19:10:16 -0500 (Mon, 05 Apr 2010) | 5 lines
DAHDI/PRI call to pri_channel_bridge() not protected by PRI lock.
SWP-1231
ABE-2163
........
................
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@256268 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
................
r256015 | russell | 2010-04-02 18:46:45 -0500 (Fri, 02 Apr 2010) | 16 lines
Merged revisions 256014 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r256014 | russell | 2010-04-02 18:45:56 -0500 (Fri, 02 Apr 2010) | 9 lines
Resolve a deadlock that occurs due to a pointless call to ast_bridged_channel()
(closes issue #16840)
Reported by: bzing2
Patches:
patch.txt uploaded by bzing2 (license 902)
issue_16840.rev1.diff uploaded by russell (license 2)
Tested by: bzing2, russell
........
................
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@256018 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
................
r255410 | russell | 2010-03-30 15:56:26 -0500 (Tue, 30 Mar 2010) | 9 lines
Merged revisions 255409 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r255409 | russell | 2010-03-30 15:56:00 -0500 (Tue, 30 Mar 2010) | 2 lines
Don't kill Asterisk if the H323 listener does not start.
........
................
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@255413 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
........
r254718 | russell | 2010-03-25 15:08:40 -0500 (Thu, 25 Mar 2010) | 2 lines
chan_usbradio depends on alsa.
........
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@254721 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@254548 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@254542 f38db490-d61c-443f-a65b-d21fe96a405b
|