The CLI "dahdi show channel" command was not correctly reporting the
InAlarm status.
The inalarm flag is now consistently passed between chan_dahdi and
submodules.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@261007 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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: https://origsvn.digium.com/svn/asterisk/trunk@260437 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Created
SIG_PRI_MAX_CHANNELS, SIG_PRI_NUM_DCHANS
SIG_SS7_MAX_CHANNELS, SIG_SS7_NUM_DCHANS
SIG_MFCR2_MAX_CHANNELS
Also fixed the declaration of pollers[] in mfcr2_monitor(). It was
dimensioned to the number of bytes in struct dahdi_mfcr2.pvts[] and not to
the same dimension of the struct dahdi_mfcr2.pvts[].
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@260435 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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: https://origsvn.digium.com/svn/asterisk/trunk@260231 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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: https://origsvn.digium.com/svn/asterisk/trunk@259870 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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: https://origsvn.digium.com/svn/asterisk/trunk@259538 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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: https://origsvn.digium.com/svn/asterisk/trunk@259307 65c4cc65-6c06-0410-ace0-fbb531ad65f3
(closes issue #16988)
Reported by: frawd
Patches:
chan_sip_sdp_verbose_fix.diff uploaded by frawd (license 610)
Tested by: russell
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@258934 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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: https://origsvn.digium.com/svn/asterisk/trunk@258305 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Revision 1072 of libpri added SERVICE message support for the 'national'
switchtype. The attached patch enables the use of 'pri service' CLI commands
on dahdi channels that are configured for the 'national' switchtype.
(closes issue #17142)
Reported by: dhubbard
Patches:
dw-ni2.patch uploaded by dhubbard (license 733)
Tested by: elguero, dhubbard
Review: https://reviewboard.asterisk.org/r/612/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@257642 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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: https://origsvn.digium.com/svn/asterisk/trunk@257493 65c4cc65-6c06-0410-ace0-fbb531ad65f3
To guarantee the channel is valid when calling setvar on the MASTER_CHANNEL
dialplan function, a channel reference must be taken before unlocking. Thanks
to russell for pointing out the error.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@256823 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Call completion code tries to grab the call completion parameters
from the requesting channel during local_request. When originating
a call to a local channel, however, this channel is NULL. This
was causing an issue for me when trying to run a test script.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@256646 65c4cc65-6c06-0410-ace0-fbb531ad65f3
From the original issue report opened by Nick Lewis:
Many sip headers in many sip methods contain the ABNF structure
name-andor-addr = name-addr / addr-spec
Examples include the to-header, from-header, contact-header, replyto-header
At the moment chan_sip.c makes various different attempts to parse this name-andor-addr structure for each header type and for each sip method with sometimes limited degrees of success.
I recommend that this name-andor-addr structure be parsed by a dedicated function and that it be used irrespective of the specific method or header that contains the name-andor-addr structure
Nick has also included unit tests for verifying these routines as well, so...heck yeah.
(closes issue #16708)
Reported by: Nick_Lewis
Patches:
reqresp_parser-nameandoraddr2.patch uploaded by Nick Lewis (license 657
Review: https://reviewboard.asterisk.org/r/549
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@256530 65c4cc65-6c06-0410-ace0-fbb531ad65f3
From Reviewboard:
CCSS stands for Call Completion Supplementary Services. An admittedly out-of-date
overview of the architecture can be found in the file doc/CCSS_architecture.pdf
in the CCSS branch. Off the top of my head, the big differences between what is
implemented and what is in the document are as follows:
1. We did not end up modifying the Hangup application at all.
2. The document states that a single call completion monitor may be used across
multiple calls to the same device. This proved to not be such a good idea
when implementing protocol-specific monitors, and so we ended up using one
monitor per-device per-call.
3. There are some configuration options which were conceived after the document
was written. These are documented in the ccss.conf.sample that is on this
review request.
For some basic understanding of terminology used throughout this code, see the
ccss.tex document that is on this review.
This implements CCBS and CCNR in several flavors.
First up is a "generic" implementation, which can work over any channel technology
provided that the channel technology can accurately report device state. Call
completion is requested using the dialplan application CallCompletionRequest and can
be canceled using CallCompletionCancel. Device state subscriptions are used in order
to monitor the state of called parties.
Next, there is a SIP-specific implementation of call completion. This method uses the
methods outlined in draft-ietf-bliss-call-completion-06 to implement call completion
using SIP signaling. There are a few things to note here:
* The agent/monitor terminology used throughout Asterisk sometimes is the reverse of
what is defined in the referenced draft.
* Implementation of the draft required support for SIP PUBLISH. I attempted to write
this in a generic-enough fashion such that if someone were to want to write PUBLISH
support for other event packages, such as dialog-state or presence, most of the effort
would be in writing callbacks specific to the event package.
* A subportion of supporting PUBLISH reception was that we had to implement a PIDF
parser. The PIDF support added is a bit minimal. I first wrote a validation
routine to ensure that the PIDF document is formatted properly. The rest of the
PIDF reading is done in-line in the call-completion-specific PUBLISH-handling
code. In other words, while there is PIDF support here, it is not in any state
where it could easily be applied to other event packages as is.
Finally, there are a variety of ISDN-related call completion protocols supported. These
were written by Richard Mudgett, and as such I can't really say much about their
implementation. There are notes in the CHANGES file that indicate the ISDN protocols
over which call completion is supported.
Review: https://reviewboard.asterisk.org/r/523
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@256528 65c4cc65-6c06-0410-ace0-fbb531ad65f3
From Review Board:
There are two interrelated changes here.
First, there is the introduction of func_srv. This adds two new read-only
dialplan functions, SRVQUERY and SRVRESULT. They work very similarly to the
ENUMQUERY and ENUMRESULT functions, except that this allows one to query SRV
records instead. In order to facilitate this work, I added a couple of new API
calls to srv.h. ast_srv_get_record_count tells the number of records returned
by an SRV lookup. This number is calculated at the time of the SRV lookup.
ast_srv_get_nth_record allows one to get a numbered SRV record.
Second, there is the modification to chan_sip that allows one to specify a
hostname or IP address (along with a port) to send an outgoing INVITE to when
dialing a SIP peer. This goes hand-in-hand with func_srv. You can query SRV
records and then use the host and port from the results to dial via a specific
host instead of what is configured in sip.conf.
Review: https://reviewboard.asterisk.org/r/608
SWP-1200
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@256485 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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: https://origsvn.digium.com/svn/asterisk/trunk@256015 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Bulk lot of generally trivial changes for cleaning up the transmit stuff. Line state request has been modified for line only responses.
(closes issue #16994)
Reported by: wedhorn
Patches:
skinny-clean07.diff uploaded by wedhorn (license 30)
Tested by: wedhorn
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@255850 65c4cc65-6c06-0410-ace0-fbb531ad65f3
There was a bug where we split the URI on the @ sign and then attempted
to compare to "anonymous@anonymous.invalid" afterwards. This comparison
could never evaluate true. So now we keep a copy of the URI prior to the
split so that the comparison is valid.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@255701 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This adds rtpsource options analogous to the rtpdest
functions that already exist. In addition, this fixes
potential crashes which could result due to trying to
read values from nonexistent RTP streams.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@254551 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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: https://origsvn.digium.com/svn/asterisk/trunk@254450 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch removes some cases where the channel number for an ioctl was
passed as a member in a struct rather then through the file descriptor.
The gain setting functions passed around a channel which is always 0,
and thus this parameter is simply dropped.
Review: https://reviewboard.asterisk.org/r/584/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@254406 65c4cc65-6c06-0410-ace0-fbb531ad65f3
users expect them to work.
'core set debug' and 'core set verbose' can optionally change the
level for a specific filename; however, this is actually for a
specific source file name, not the module that source file is included
in. With examples like chan_sip, chan_iax2, chan_misdn and others
consisting of multiple source files, this will not lead to the
behavior that users expect. If they want to set the debug level for
chan_sip, they want it set for all of chan_sip, and not to have to
also set it for reqresp_parser and other files that comprise the
chan_sip module.
This patch changes this functionality to be module-name based instead
of file-name based.
To make this work, some Makefile modifications were required to ensure
that the AST_MODULE definition is present in each object file produced
for each module as well.
Review: https://reviewboard.asterisk.org/r/574/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@253917 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This change basically reverts the change reviewed in
https://reviewboard.asterisk.org/r/374/ and instead limits the
updating of the RTP synchronization source to only those times when we
detect that the other side of the conversation has changed the ssrc.
The problem is that SRCUPDATE control frames are sent many times where
we don't want a new ssrc, including whenever Asterisk has to send DTMF
in a normal bridge. This is also not the first time that this mistake
has been made. The initial implementation of the ast_rtp_new_source
function also changed the ssrc--and then it was removed because of
this same issue. Then, we put it back in again to fix a different
issue. This patch attempts to only change the ssrc when we see that
the other side of the conversation has changed the ssrc.
It also renames some functions to make their purpose more clear.
Review: https://reviewboard.asterisk.org/r/540/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@252089 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Rework HAVE_PRI_SERVICE_MESSAGES to not use the active values directly
from the database. Database access is likely expensive. Database access
now only happens on initialization, destruction, and when the B channel is
taken in or out of service.
This change is not related to call waiting but it would cause the search
for a call waiting interface to be very expensive and slow down D channel
message servicing.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@251538 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Small patch changing skinny_set_rtp_peer to use transmit_stopmediatransmission and to use new transmit_startmediatransmission.
Basic testing on 30VIP's by wedhorn
Basic testing on 7960 by me
(closes issue #16956)
Reported by: wedhorn
Patches:
skinny-clean05b.diff uploaded by wedhorn (license 30)
Tested by: wedhorn,mvanbaak
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@251222 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Broke the various functions included in transmit_callstate to their own functions. Transmit_callstate now just transmits callstate.
Generally left the functionality as it was, which highlight some minor code issues (eg multiple transmit_callstate's). I did however revise the hint code usage of the old transmit_callstate as it it not appropriate to put a device on hook based on the change of a hinted device.
(closes issue #16939)
Reported by: wedhorn
Patches:
skinny-clean04.diff uploaded by wedhorn (license 30)
Tested by: mvanbaak,wedhorn
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@251221 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The first real test added to the external test suite found a pretty nasty crash
that occurred in Asterisk trunk. The crash was due to a race condition between
the REFER handling and channel destruction in the channel thread. After the
transfer has been completed, we go back to the transferrer channel and try to
lock it so we can fire off a CEL event. However, there was no guarantee that
the channel was still around at that point since it's racing against the channel
thread.
Since ast_channel is a reference counted object, the fix is simple. The code
unlocks the transferrer channel before finally completing the transfer with
an async goto. At this point the channel thread is going to start call tear
down and the channel will eventually be destroyed. To ensure that the channel
is valid when we want to fire off the CEL event, increase the channel's
reference count.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@251137 65c4cc65-6c06-0410-ace0-fbb531ad65f3
