Terry Wilson [Fri, 6 May 2011 07:55:21 +0000 (07:55 +0000)]
Re-fix queue round-robin
This part of the change for r315596 was incorrect. No bridge occurs
when doing a roundrobin dial and no one answers, so this code shouldn't
have been removed.
This change optimizes the free_via() function and removes some redundant null
checking. It also fixes compliance with RFC 3261 section 18.2.2 by always using
the port specified in the Via header for routing responses (even when maddr is
not set). Also the htons() function is now used when setting the port.
Additional documentation comments have been added in various places to make the
logic in the code clearer.
Terry Wilson [Tue, 26 Apr 2011 21:16:10 +0000 (21:16 +0000)]
Allow transfer loops without allowing forwarding loops
We try to avoid the situation where two phones may be forwarded to each other
causing an infinite loop by storing each dialed interface in a channel
datastore and checking the list before dialing out. This works, but currently
breaks situations like A calls B, A transfers B to C, B transfers C to A, and A
transfers C to B. Since human interaction is happening here and not an
automated forwarding loop, it should be allowed.
This patch removes the dialed_interfaces datastore when a call is bridged (a
suggestion from the brilliant mmichelson). If a call is being bridged, it
should be safe to assume that we aren't stuck in a loop.
Since we are now handling this is the bridge code, the previous attempts at
handling it in app_dial and app_queue are removed.
The code that set the bit within the select bitfield was correct, but the
bounds-checking code was not. The change to that line uses the new _bitsize
macro for clarity. Also, FD_ZERO macro did not zero-out anything but the
first word of the bitfield, so this could have caused problems with modules
using that macro with the expanded bitfield.
Reverted part of r314607, as it can introduce a regression.
Specifically, the security check for the "system" privilege was removed. If a user had the "call" privilege but not the "system" privilege, they would loose the ability to execute the system app and dialplan functions that run commands in a shell. This branch never used the "system" privilege for that purpose and did not need to be patched.
Russell Bryant [Fri, 22 Apr 2011 14:34:23 +0000 (14:34 +0000)]
Initialize buffers in getvar and getvarfull.
Initialize the buffers used to hold the result from GET VARIABLE or
GET VARIABLE FULL. The bug report shows func_read returning garbage in
the result. It assumed that the buffer passed in was initialized, like many
other functions do. In the more common code path (through the dialplan), it
is initialized, so just initialize it here too.
Added limits to the number of unauthenticated sessions TCP based protocols are allowed to have open simultaneously. Also added timeouts for unauthenticated sessions where it made sense to do so.
Unrelated, the manager interface now properly checks if the user has the "system" privilege before executing shell commands via the Originate action.
Richard Mudgett [Wed, 13 Apr 2011 16:21:24 +0000 (16:21 +0000)]
Asterisk does not hangup a channel after endpoint hangs up.
If the call that the dialplan started an AGI script for is hungup while
the AGI script is in the middle of a command then the AGI script is not
notified of the hangup. There are many AGI Exec commands that this can
happen with. The reported applications have been: Background, Wait, Read,
and Dial. Also the AGI Get Data command.
* Don't wait on the Asterisk channel after it has hung up. The channel is
likely to never need servicing again.
* Restored the AGI script's ability to return the AGI_RESULT_HANGUP value
in run_agi(). It previously only could return AGI_RESULT_SUCCESS or
AGI_RESULT_FAILURE after the DeadAGI and AGI applications were merged.
(closes issue #17954)
Reported by: mn3250
Patches:
issue17954_v1.8.patch uploaded by rmudgett (license 664)
issue17954_v1.6.2.patch uploaded by rmudgett (license 664)
issue17954_v1.4.patch uploaded by rmudgett (license 664)
Tested by: rmudgett
JIRA SWP-2171
Richard Mudgett [Mon, 11 Apr 2011 15:27:52 +0000 (15:27 +0000)]
Stuck channel using FEATD_MF if caller hangs up at the right time.
The cause was actually a caller hanging up just at the end of the Feature
Group D DTMF tones that setup the call. The reason for this is a "guard
timer" that's implemented using ast_safe_sleep(100). If the caller
happens to hang up AFTER the final tone of the DTMF string but BEFORE the
end of that ast_safe_sleep(), then ast_safe_sleep() will return non-zero.
This causes the code to bounce to the end of ss_thread(), but it does NOT
tear down the call properly.
This should be a rare occurrence because the caller has to hang up at
EXACTLY the right time. Nonetheless, it was happening quite regularly on
the reporter's system. It's not easily reproducible, unless you purposely
increase the guard-time to 2000 or more. Once you do that, you can
reproduce it every time by watching the DTMF debug and hanging up just as
it ends.
Richard Mudgett [Mon, 4 Apr 2011 15:49:30 +0000 (15:49 +0000)]
Issues with ISDN calls changing B channels during call negotiations.
The handling of the PROCEEDING message was not using the correct call
structure if the B channel was changed. (The same for PROGRESS.) The call
was also not hungup if the new B channel is not provisioned or is busy.
* Made all call connection messages (SETUP_ACKNOWLEDGE, PROCEEDING,
PROGRESS, ALERTING, CONNECT, CONNECT_ACKNOWLEDGE) ensure that they are
using the correct structure and B channel. If there is any problem with
the operations then the call is now hungup with an appropriate cause code.
* Made miscellaneous messages (INFORMATION, FACILITY, NOTIFY) find the
correct structure by looking for the call and not using the channel ID.
NOTIFY is an exception with versions of libpri before v1.4.11 because a
call pointer is not available for Asterisk to use.
* Made all hangup messages (DISCONNECT, RELEASE, RELEASE_COMPLETE) find
the correct structure by looking for the call and not using the channel
ID.
Alec L Davis [Fri, 1 Apr 2011 11:02:26 +0000 (11:02 +0000)]
app_voicemail: leave_vociemail doesn't use last_message_index to store next message
trivial change to bring inline with 1.6.2 1.8 and trunk.
The symptom was if msg0000 was missing, and the last was msg0004,
the next msgnum would be msg0000 when it should have been msg0005
Alec L Davis [Fri, 1 Apr 2011 08:29:49 +0000 (08:29 +0000)]
voicemail: get real last_message_index and count_messages, ODBC resequence
change last_message_index to read the max msgnum stored in the database
change count_messages to actually count the number of messages.
last_message_index change:
This fixed overwriting of the last message if msgnum=0 was missing.
Previously every incoming message would overwrite msgnum=1.
count_messages change:
allows us to detect when requencing is required in opneA_mailbox.
resequence enabled for ODBC storage:
Assists with fixing up corrupt databases with gaps, but only when
a user actively opens there mailboxes.
(closes issue #18692,#18582,#19032)
Reported by: elguero
Patches:
based on odbc_resequence_mailbox2.1.diff uploaded by elguero (license 37)
Tested by: elguero, nivek, alecdavis
Alec L Davis [Fri, 1 Apr 2011 06:46:56 +0000 (06:46 +0000)]
app_voicemail: close_mailbox needs to respect additional messages while mailbox is open.
close_mailbox leave gaps in message sequence if messages are deleted and new messages
arrive during this time, this is because the shuffle down to slot 0, only shuffles
the number of pre-existing messages when mailbox is opened, ignoring new arrivals.
Fix: in close_mailbox re-evaluate number of messages before the shuffle, this then includes new arrivals.
Terry Wilson [Wed, 16 Mar 2011 16:58:42 +0000 (16:58 +0000)]
Don't delay DTMF in core bridge while listening for DTMF features
This patch is mostly the work of Olle Johansson. I did some cleanup and
added the silence generating code if transmit_silence is set.
When a channel listens for DTMF in the core bridge, the outbound DTMF is not
sent until we have received DTMF_END. For a long DTMF, this is a disaster. We
send 4 seconds of DTMF to Asterisk, which sends no audio for those 4 seconds.
Some products see this delay and the time skew on RTP packets that results and
start ignoring the audio that is sent afterward.
With this change, the DTMF_BEGIN frame is inspected and checked. If it matches
a feature code, we wait for DTMF_END and activate the feature as before. If
transmit_silence=yes in asterisk.conf, silence is sent if we paritally match a
multi-digit feature. If it doesn't match a feature, the frame is forwarded
along with the DTMF_END without delay. By doing it this way, DTMF is not delayed.
(closes issue #15642)
Reported by: jasonshugart
Patches:
issue_15652_dtmf_ast-1.4.patch.txt uploaded by twilson (license 396)
Tested by: globalnetinc, jde
Richard Mudgett [Mon, 14 Mar 2011 16:38:24 +0000 (16:38 +0000)]
"Caller*ID failed checksum" on Wildcard TDM2400P and TDM410
The last character in the caller id message is getting a framing error.
The checksum is the last character in the message. A framing error in the
checksum could be because:
1) The sender did not send a full stop bit.
2) The sender cut off the FSK carrier too soon.
3) The sender opted to send zero of the specified zero to 10 trailing mark
bits and round-off errors in the code resulted in the code not being where
it thought it was in the demodulated bit stream.
Bit 8 of 'b' is set when parity error.
Bit 9 of 'b' is set when framing error.
Made ignore the framing and parity error bits if the errored character is
the checksum. We can tolerate a framing/parity error there. The checksum
character validates the message.
Tilghman Lesher [Sat, 12 Mar 2011 20:22:07 +0000 (20:22 +0000)]
Add AELSub, which provides a stable entry point into AEL subroutines.
This commit needs some explanation, given that we're adding a new application
into an existing release branch. This is generally a violation of our release
policy, except in very limited circumstances, and I believe this is one of
those circumstances.
The problem that this solves is one of the sanity of using multiple dialplan
languages to define a dialplan. In the case of the reporter, he or she is
using AEL is define subroutines, while using Realtime extensions to invoke
those subroutines. While you can do this, it's based upon the reality of AEL
using actual dialplan extensions; however, there is no guarantee that the
details of _how_ AEL is compiled into extensions will remain stable. In fact,
at the time of this commit, it has already changed twice, once in a
fundamental way.
Now normally, a new application would only be added to trunk. However, this
application is explicitly to create a stable user-level API between versions,
and adding it to trunk only will not solve the user's problem of switching
between 1.6.2 and 1.8, nor will it help anybody switching from 1.8 to 1.10.
Therefore, it needs to go into existing release branches. For the sake of
consistency, and also because one of the changes was between 1.4 and 1.6.x,
I am also electing to commit this to 1.4.
Terry Wilson [Thu, 24 Feb 2011 17:42:16 +0000 (17:42 +0000)]
Don't broadcast FullyBooted to every AMI connection
The FullyBooted event should not be sent to every AMI connection every
time someone connects via AMI. It should only be sent to the user who
just connected.
Properly check the bounds of arrays when decoding UDPTL packets. Also, remove broken support for receiving UDPTL packets larger than 16k. That shouldn't ever happen anyway.
Jason Parker [Tue, 15 Feb 2011 23:32:20 +0000 (23:32 +0000)]
Fix regression that changed behavior of queues when ringing a queue member.
This reverts r298596, which was to fix a highly bizarre and contrived issue
with a queue member that called into his own queue being transferred back
into his own queue. I couldn't reproduce that issue in any way. I think one
of the other recent transfer fixes actually fixed this.
Richard Mudgett [Fri, 11 Feb 2011 00:29:17 +0000 (00:29 +0000)]
Reentrancy problem if outgoing call gets different B channel than requested.
The chan_dahdi pri_fixup_principle() routine needs to protect the Asterisk
channel with the channel lock when it changes the technology private
pointer to a new private structure.
* Added lock protection while pri_fixup_principle() moves a call from one
private structure to another.
* Made some pri_fixup_principle() messages more meaningful.
Terry Wilson [Mon, 7 Feb 2011 22:35:20 +0000 (22:35 +0000)]
Don't try to pickup a call in the middle of a masquerade
If A calls B which doesn't answer and C & D both try to do a call pickup, it is
possible for ast_pickup_call to answer the call, then fail to masquerade one of
the calls because the other one is already in the process of masquerading. This
patch checks to see if the channel is in the process of masquerading before
call before selecting it for a pickup.
Terry Wilson [Mon, 7 Feb 2011 21:51:43 +0000 (21:51 +0000)]
Don't allow a REFER w/replaces to replace its own dialog
Asterisk currently accepts a REFER with a Refer-To with an embedded Replaces
header that matches the dialog of the REFER. This would be a situation like A
calls B, A calls C, A transfers B to A, which is just silly. This patch makes
the transfer fail instead of making Asterisk freak out and forget to hang other
channels up.
Terry Wilson [Thu, 3 Feb 2011 20:36:34 +0000 (20:36 +0000)]
Set hangup cause in local_hangup
When a call involves a local channel (like SIP -> Local -> SIP), the hangup
cause was not being set. This resulted in SIP channels sometimes getting a
503 error instead of a 486 when the far side sent a busy. In Asterisk 1.8+
this also can cause issues with CCSS that involve a local channel. This patch
sets the hangupcause for one side of the local channel to the other in
local_hangup for outbound calls.
Richard Mudgett [Thu, 3 Feb 2011 00:02:43 +0000 (00:02 +0000)]
Minor AST_FRAME_TEXT related issues.
* Include the null terminator in the buffer length. When the frame is
queued it is copied. If the null terminator is not part of the frame
buffer length, the receiver could see garbage appended onto it.
* Add channel lock protection with ast_sendtext().
Jason Parker [Mon, 31 Jan 2011 22:56:54 +0000 (22:56 +0000)]
Prevent a crash when dialing a technology with no destination (ex: Dial(SIP/))
chan_iax2 and other channel drivers already had code to prevent this. The
attempt that app_dial was making to prevent it was not correct, so I fixed that.
Jason Parker [Thu, 27 Jan 2011 16:57:46 +0000 (16:57 +0000)]
Fix default prefix=/usr regression on non-Linux systems.
This partially reverts a change made in branches/1.4/ r267759, which will
cause issue #17013 to be reopened. This issue was pointed out by a user
on #asterisk, who helpfully discovered that paths were being set incorrectly.
To truly understand what was wrong, one should run:
svn diff --force -c<this revision> configure
This patch modifies chan_sip to route responses to the address the request came from. It also modifies chan_sip to respect the maddr parameter in the Via header.
Richard Mudgett [Tue, 25 Jan 2011 23:21:09 +0000 (23:21 +0000)]
DTMF attended transfers sometimes fail for no apparent reason.
The loop in feature_request_and_dial() can exit when Party C has answered
without processing an AST_CONTROL_ANSWER. Also sometimes an
AST_CONTROL_ANSWER never happens even though Party C has answered.
Don't hangup Party C if he is up or we receive an AST_CONTROL_ANSWER.
Terry Wilson [Tue, 25 Jan 2011 20:50:59 +0000 (20:50 +0000)]
Guard against retransmitting BYEs indefinitely
In the case of an attended transfer (A calls B, A atxfers to C) where
A becomes unreachable before replying to Asterisk's BYE, Asterisk can
sometimes retransmit the BYE indefinitely. This is because
__sip_autodestruct tests p->refer && !ast_test_flag(&p->flags[0],
SIP_ALREADYGONE and will then transmit a BYE. When this BYE times out,
it will not ever be marked as ALREADYGONE, so when __sip_autodestruct
is called again, we end up starting the cycle over.
This patch adds a call to sip_alreadygone(pkt->owner) in retrans_pkt
in the case of a BYE that has timed out. This should prevent Asterisk
from trying to transmit new BYE messages in the future.
Richard Mudgett [Tue, 25 Jan 2011 17:36:50 +0000 (17:36 +0000)]
Sending out unnecessary PROCEEDING messages breaks overlap dialing.
Issue #16789 was a good idea. Unfortunately, it breaks overlap dialing
through Asterisk. There is not enough information available at this point
to know if dialing is complete. The ast_exists_extension(),
ast_matchmore_extension(), and ast_canmatch_extension() calls are not
adequate to detect a dial through extension pattern of "_9!".
Workaround is to use the dialplan Proceeding() application early in
non-dial through extensions.
* Effectively revert issue #16789.
* Allow outgoing overlap dialing to hear dialtone and other early media.
A PROGRESS "inband-information is now available" message is now sent after
the SETUP_ACKNOWLEDGE message for non-digital calls. An
AST_CONTROL_PROGRESS is now generated for incoming SETUP_ACKNOWLEDGE
messages for non-digital calls.
* Handling of the AST_CONTROL_CONGESTION in chan_dahdi/sig_pri was
inconsistent with the cause codes.
* Added better protection from sending out of sequence messages by
combining several flags into a single enum value representing call
progress level.
(closes issue #18509)
Reported by: wimpy
Patches:
issue18509_early_media_v1.8_v3.patch uploaded by rmudgett (license 664)
Expanded upon issue18509_early_media_v1.8_v3.patch to include analog
and SS7 because of backporting requirements.
Tested by: wimpy, rmudgett
Jeff Peeler [Tue, 25 Jan 2011 16:58:29 +0000 (16:58 +0000)]
Fix voicemail sequencing for file based storage.
A previous change was made to account for when the number of voicemail messages
exceeds the max limit to be handled properly, but it caused gaps in the messages
to not be properly handled. This has now been resolved.
In later non 1.4 branches, it appears that resequencing wasn't even occurring
due from what appears and accidental code removal.
Russell Bryant [Mon, 24 Jan 2011 20:32:21 +0000 (20:32 +0000)]
Fix channel redirect out of MeetMe() and other issues with channel softhangup.
Mantis issue #18585 reports that a channel redirect out of MeetMe() stopped
working properly. This issue includes a patch that resolves the issue by
removing a call to ast_check_hangup() from app_meetme.c. I left that in my
patch, as it doesn't need to be there. However, the rest of the patch fixes
this problem with or without the change to app_meetme.
The key difference between what happens before and after this patch is the
effect of the END_OF_Q control frame. After END_OF_Q is hit in ast_read(),
ast_read() will return NULL. With the ast_check_hangup() removed, app_meetme
sees this which causes it to exit as intended. Checking ast_check_hangup()
caused app_meetme to exit earlier in the process, and the target of the
redirect saw the condition where ast_read() returned NULL.
Removing ast_check_hangup() works around the issue in app_meetme, but doesn't
solve the issue if another application did the same thing. There are also
other edge cases where if an application finishes at the same time that a
redirect happens, the target of the redirect will think that the channel hung
up. So, I made some changes in pbx.c to resolve it at a deeper level. There
are already places that unset the SOFTHANGUP_ASYNCGOTO flag in an attempt to
abort the hangup process. My patch extends this to remove the END_OF_Q frame
from the channel's read queue, making the "abort hangup" more complete. This
same technique was used in every place where a softhangup flag was cleared.
Jason Parker [Fri, 21 Jan 2011 21:45:34 +0000 (21:45 +0000)]
Reset configuration before parsing users.conf.
Some values configured in chan_dahdi.conf were able to leak in to users.conf
configuration. This was surprising users, and potentially setting non-sane
"defaults".
Richard Mudgett [Wed, 19 Jan 2011 21:21:56 +0000 (21:21 +0000)]
DTMF transfer plays the wrong sounds for wrong number or other call failure.
* Set the default for features.conf.sample xferfailsound option to "beeperr"
as documented instead of "pbx-invalid" and corrected the use of it in DTMF
blind transfer (#1).
* Improved DTMF blind transfer handling of wrong numbers.
Most of the concerns in this issue were taken care of by the patch for
issue 17999: Issues with DTMF triggered attended transfers.
Richard Mudgett [Tue, 18 Jan 2011 18:04:36 +0000 (18:04 +0000)]
Issues with DTMF triggered attended transfers.
Issue #17999
1) A calls B. B answers.
2) B using DTMF dial *2 (code in features.conf for attended transfer).
3) A hears MOH. B dial number C
4) C ringing. A hears MOH.
5) B hangup. A still hears MOH. C ringing.
6) A hangup. C still ringing until "atxfernoanswertimeout" expires.
For v1.4 C will ring forever until C answers the dead line. (Issue #17096)
Problem: When A and B hangup, C is still ringing.
Issue #18395
SIP call limit of B is 1
1. A call B, B answered
2. B *2(atxfer) call C
3. B hangup, C ringing
4. Timeout waiting for C to answer
5. Recall to B fails because B has reached its call limit.
Because B reached its call limit, it cannot do anything until the transfer
it started completes.
Issue #17273
Same scenario as issue 18395 but party B is an FXS port. Party B cannot
do anything until the transfer it started completes. If B goes back off
hook before C answers, B hears ringback instead of the expected dialtone.
**********
Note for the issue #17273 and #18395 fix:
DTMF attended transfer works within the channel bridge. Unfortunately,
when either party A or B in the channel bridge hangs up, that channel is
not completely hung up until the transfer completes. This is a real
problem depending upon the channel technology involved.
For chan_dahdi, the channel is crippled until the hangup is complete.
Either the channel is not useable (analog) or the protocol disconnect
messages are held up (PRI/BRI/SS7) and the media is not released.
For chan_sip, a call limit of one is going to block that endpoint from any
further calls until the hangup is complete.
For party A this is a minor problem. The party A channel will only be in
this condition while party B is dialing and when party B and C are
conferring. The conversation between party B and C is expected to be a
short one. Party B is either asking a question of party C or announcing
party A. Also party A does not have much incentive to hangup at this
point.
For party B this can be a major problem during a blonde transfer. (A
blonde transfer is our term for an attended transfer that is converted
into a blind transfer. :)) Party B could be the operator. When party B
hangs up, he assumes that he is out of the original call entirely. The
party B channel will be in this condition while party C is ringing, while
attempting to recall party B, and while waiting between call attempts.
WARNING:
The ATXFER_NULL_TECH conditional is a hack to fix the problem. It will
replace the party B channel technology with a NULL channel driver to
complete hanging up the party B channel technology. The consequences of
this code is that the 'h' extension will not be able to access any channel
technology specific information like SIP statistics for the call.
ATXFER_NULL_TECH is not defined by default.
**********
Only offer codecs both sides support for directmedia
When using directmedia, Asterisk needs to limit the codecs offered to just
the ones that both sides recognize, otherwise they may end up sending audio
that the other side doesn't understand.
Jeff Peeler [Wed, 12 Jan 2011 18:10:42 +0000 (18:10 +0000)]
Fix CPU spike when pressing DTMF after agent login.
The problem here is that DTMF was being continuously deferred and requeued
since ast_safe_sleep is called in a loop. There are serveral other places in the
code that sleeps and then loops in a similar fashion. Because of this fact I
opted to not defer DTMF any more, which will not affect the original fix:
Terry Wilson [Tue, 4 Jan 2011 17:11:48 +0000 (17:11 +0000)]
Don't authenticate SUBSCRIBE re-transmissions
This only skips authentication on retransmissions that are already
authenticated. A similar method is already used for INVITES. This
is the kind of thing we end up having to do when we don't have a
transaction layer...
Tilghman Lesher [Fri, 17 Dec 2010 21:40:56 +0000 (21:40 +0000)]
Let Asterisk find better backtrace information with libbfd.
The menuselect option BETTER_BACKTRACES, if enabled, will use libbfd to search
for better symbol information within both the Asterisk binary, as well as
loaded modules, to assist when using inline backtraces to track down problems.
projects / thirdparty / asterisk.git / log
