Check all 4 combinations of (original/clonechan) * (masq/masqr).
Initially original->masq and clonechan->masqr were only checked.
It's possible with multiple masq's planned - and not yet executed, that
the 'original' chan could already have another masq'd into it - thus original->masqr
would be set, that masqr would lost.
Likewise for the clonechan->masq.
Only drop duplicate answer frames if the channel is bridged.
Back in r3710 ast_read() was modified to drop answer frames on channels that were in the UP state. This modification prevented bridges that were up before the answer from being broken and reestablished by an ANSWER control frame. That change also prevents pickup of channels called from the ast_dial framework from working properly. The ast_dial framework expects to see an ANSWER frame after dialing and the pickup code queues one but ast_read() drops it. This new change only drops ANSWER frames when the channel is bridged, allowing the answer queued by the pickup code to properly pass through ast_read() on to the ast_dial framework.
Richard Mudgett [Fri, 10 Sep 2010 20:33:16 +0000 (20:33 +0000)]
An outgoing call may not get hung up if a pre-connect incoming ISDN call is disconnected.
If the ISDN link a pre-connect incoming call is using fails or is reset,
the outgoing leg may not hang up or be delayed in hanging up. (Causes:
PRI_CAUSE_NETWORK_OUT_OF_ORDER, PRI_CAUSE_DESTINATION_OUT_OF_ORDER, and
PRI_CAUSE_NORMAL_TEMPORARY_FAILURE.)
Just hang up the call if the incoming call leg hangs up before connecting
for any reason. It makes no sense to send a BUSY or CONGESTION control
frame to the outgoing call leg under these circumstances.
David Vossel [Fri, 10 Sep 2010 20:03:50 +0000 (20:03 +0000)]
Fixes sip extension state update DEADLOCK
PROBLEM:
In chan_sip, and all the other channel drivers, it is common for
us to hold the tech_pvt lock while we ask the Asterisk core about
an extension and context. Every time we do this the locking
order becomes, (1. tech_pvt lock ---> 2. global context lock). In
chan_sip when a dialog subscribes to a hint, that locking order
is reversed in the extensionstate callback which will occur outside
of the channel_driver's monitor loop. So, on an extension state
update we have (1. global context lock ----> 2. tech_pvt lock).
Typically when we have to do a reversed locking order like this
we'd just do some sort of deadlock avoidance to fix the problem...
That will not work here. There are more locks involved here than
just the context and tech_pvt. Those are the two that are colliding,
but it is impossible to give up the context lock because the global
hints list lock MUST be held as well and we can not give that lock
up during the extensionstate callback traversal... The locking order
for the context and hints are (1. global context lock ----> 2.
hints list lock). Deadlock avoidance is not an option here.
SOLUTION:
The solution this patch implements is to queue the extension state updates
into a list and send the NOTIFY messages out during the do_monitor pvt
traversal. This clears out the problem of having to hold the context
lock before the tech_pvt lock entirely.
Terry Wilson [Fri, 10 Sep 2010 19:25:08 +0000 (19:25 +0000)]
Inherit CHANNEL() writes to both sides of a Local channel
Having Local (/n) channels as queue members and setting the language in the
extension with Set(CHANNEL(language)=fr) sets the language on the Local/...,2
channel. Hold time report playbacks happen on the Local/...,1 channel and
therefor do not play in the specified language.
This patch modifies func_channel_write to call the setoption callback and pass
the CHANNEL() write info to the callback. chan_local uses this information to
look up the other side of the channel and apply the same changes to it.
This also fixes a rather grievous calculation error for the offset of
ast_fdset, which was masked on Linux and FreeBSD, because these platforms
check the first 256 FDs regardless of the bitmask setting (due to backwards
compatibility).
Fixes an issue with MOH where it doesn't recover cleanly when it can't play a file and would just stop, instead of continuing to find the next playable file in the MOH class.
Ensure that all areas that previously used select(2) now use poll(2), with implementations that need poll(2) implemented with select(2) safe against 1024-bit overflows.
This is a followup to the fix for the pthread timer in 1.6.2 and beyond, fixing
a potential crash bug in all supported releases.
(closes issue #17678)
Reported by: russell
Branch: https://origsvn.digium.com/svn/asterisk/team/tilghman/ast_select
David Vossel [Thu, 26 Aug 2010 15:22:28 +0000 (15:22 +0000)]
Fixed how Asterisk destroys a dialog on channel hangup before invite receives a response.
If an ast_channel with a SIP tech pvt hangs up before the sip dialog gets a response
to its outgoing INVITE, Asterisk used to pretend_ack the INVITE. This is not rfc
compliant and results in confusion at the other endpoint. sip_pretend_ack will ack
and remove all the packets in the retransmit queue. This means that the INVITE will
stop retransmitting, and that any response to that INVITE that comes after the pretend_ack
occurs will be ignored.
Instead of faking any sort of acknowledgement for an outgoing INVITE during an internal
hangup, we should let the protocol stack process the INVITE transaction and terminate
the dialog properly. This is achieved by setting the PENDING_BYE flag. When this flag
is used, once the dialog proceeds to an escapable state the transaction will either be
canceled with a SIP_CANCEL or completed followed immediately by a BYE. Attempting to do
this any other way is incorrect. If the endpoint is not responding to the INVITE request,
the INVITE must continue to be retransmitted until it times out which will result in the
dialog being destroyed.
David Vossel [Tue, 24 Aug 2010 16:01:51 +0000 (16:01 +0000)]
This fix makes sure the ast_channel hangs up correctly when the dialog's PENDING_BYE flag is set.
When the pending bye flag is used, it is possible that the dialog will terminate
and leave the sip_pvt->owner channel up. This is because we never hangup the
ast_channel after sending the SIP_BYE request. When we receive the response for
the SIP_BYE we set need_destroy which we would expect to destroy the dialog on the
next do_monitor loop, but this is not the case. The dialog will only be destroyed
once the owner is hungup even with the need_destroy flag set. This patch sets the
softhangup flag on the ast_channel when a SIP_BYE request is sent as a result of the
pending bye flag.
Richard Mudgett [Fri, 20 Aug 2010 15:24:36 +0000 (15:24 +0000)]
Q931 - Sending PROGRESS after sending ALERTING is a protocol error
The PRI layer in chan_dadhi will check if a PROGRESS message has already
been sent, and not allow sending another (although that is technically
allowed by the Q931 spec), however it does not protect against sending an
ALERTING and then sending a PROGRESS message, which is a violation of the
specification.
Most switches don't seem to care too deeply about this, but some do, and
will disconnect the call when receiving this invalid sequence.
Protocol specification reference: T-REC-Q.931-199805-I page 223, "Figure
A.5/Q.931 -- Overview protocol control (network side) point-point
(sheet 3 of 8)"
(closes issue #17874)
Reported by: nic_bellamy
Patches:
asterisk-1.4-r282537_no-progress-after-alerting.patch uploaded by nic bellamy (license 299)
asterisk-1.6.2-r282537_no-progress-after-alerting.patch uploaded by nic bellamy (license 299)
asterisk-trunk-r282537_no-progress-after-alerting.patch uploaded by nic bellamy (license 299)
David Vossel [Thu, 19 Aug 2010 21:03:24 +0000 (21:03 +0000)]
tos_sip option was not being set correctly
When tos_sip is used, the tos of the sip socket is only set
correctly if the socket binding changes on a reload. If the binding
stays the same but the TOS changes, the new tos value would not take
into effect. This patch fixes that.
Terry Wilson [Mon, 16 Aug 2010 17:06:37 +0000 (17:06 +0000)]
Send a SRCCHANGE indication when we masquerade
Masquerading a channel means that the src of the audio is potentially
changing, so send a SRCCHANGE so that RTP-based media streams can get
a new SSRC generated to reflect the change. Original patch by addix
(along with lots of testing--thanks!).
Jeff Peeler [Thu, 12 Aug 2010 03:00:14 +0000 (03:00 +0000)]
Ensure SSRC is changed when media source is changed to resolve audio delay.
This change causes the SSRC to change right before the channels are bridged,
which is what used to happen. It seems that fixes were made to attempt limiting
SSRC changes, targeted mainly at sending DTMF. DTMF is not affecting the SSRC
with this change.
There are two other control frames sent in ast_channel_bridge that probably
should also be changed to AST_CONTROL_SRCCHANGE as well, but I'm going to leave
this change up to the discretion of resolving issue #17007.
For reference - old review implementing new control frame SRCCHANGE:
https://reviewboard.asterisk.org/r/540
Jeff Peeler [Mon, 9 Aug 2010 20:04:30 +0000 (20:04 +0000)]
Prevent loss of Caller ID information set on local channel after masquerade.
Caller ID set on the channel before a masquerade occurs when using a local
channel would cause the information to be lost. The problem was that the
information was set on a channel destined to be hung up. The somewhat confusing
fix is to detect if any Caller ID has been set on the channel and if so
preswap the Caller ID data so that basically the masquerade puts the data back.
There is a scheduler item in chan_sip that keeps sending the
last provisional message in response to an INVITE Request for
a period of time until a final response to that INVITE is
sent. Because of the way this scheduler item works, it requires
a reference to a sip_pvt pointer to work properly. The problem
with this is that it is currently possible (but rare) for the
sip_pvt to get destroyed and that scheduler item to still
exist. When this occurs, the scheduler event fires and attempts
to access a freed sip_pvt which causes a crash.
David Vossel [Tue, 27 Jul 2010 20:33:40 +0000 (20:33 +0000)]
remove empty audiohook write list on channel
If a channel has an audiohook write list created on it, that
list stays on the channel until the channel is destroyed. There
is no reason to keep that list on the channel if it becomes empty.
If it is empty that just means we are doing needless translating
for every ast_read and ast_write. This patch removes the audiohook
list from the channel once it is detected to be empty on either a
read or write. If a audiohook is added back to the channel after
this list is destroyed, the list just gets recreated as if it never
existed to begin with.
Jeff Peeler [Sat, 24 Jul 2010 23:27:22 +0000 (23:27 +0000)]
Provide a default value for DAHDI_TRANSCODE so when DAHDI is not installed
menuselect doesn't get confused:
Unknown value '' found in build_tools/menuselect-deps for DAHDI_TRANSCODE
Richard Mudgett [Fri, 23 Jul 2010 21:56:44 +0000 (21:56 +0000)]
SIP promiscuous redirect could fail to dial the redirect.
The ast_channel was created with one variable to ast_request() but the
call to ast_call() that initiates the outgoing call was using a different
variable. The two variables are not equivalent if the call_forward string
included a channel technology specifier. e.g., SIP/200
Richard Mudgett [Thu, 22 Jul 2010 19:31:34 +0000 (19:31 +0000)]
DNID does not get cleard on a new call when using immediate=yes with ISDN signaling.
When you are using chan_dahdi ISDN signaling with immediate=yes and a call
comes in without a DNID then you get the DNID of a previous call.
Chan_dahdi does not touch the DNID field on a new call if it does not have
a DNID.
Made always copy the DNID from the new call.
The patches backport the relevant changes from trunk -r210387.
(closes issue #17568)
Reported by: wuwu
Patches:
issue17568_v1.4.patch uploaded by rmudgett (license 664)
issue17568_v1.6.2.patch uploaded by rmudgett (license 664)
Mark Michelson [Thu, 22 Jul 2010 14:55:04 +0000 (14:55 +0000)]
Allow PLC to function properly when channels use SLIN for audio.
If a channel involved in a bridge was using SLIN audio, then translation
paths were not guaranteed to be set up properly since in all likelihood
the number of translation steps was only 1.
This patch enforces the transcode_via_slin behavior if transcode_via_slin
or generic_plc is enabled and one of the formats to make compatible is
SLIN.
Jean Galarneau [Mon, 19 Jul 2010 20:16:36 +0000 (20:16 +0000)]
Avoid trying to pickup a parked extension before the park operation is completed.
A crash could occur if the extension is picked up while the parking extension is
being announced. Testing pu->notquiteyet while searching for a parked extension
resolves this crash.
Tim Ringenbach [Fri, 16 Jul 2010 22:43:39 +0000 (22:43 +0000)]
Save and restore AST_FLAG_BRIDGE_HANGUP_DONT on attended transfer.
ast_bridge_call() clears AST_FLAG_BRIDGE_HANGUP_DONT. But during an attended
transfer, ast_bridge_call() is called for a second bridge on the same channel,
and it clears that flag, which still needs to get set for when the original
ast_bridge_call() gets control back and checks it.
Default to no udptl error correction so that error correction will be disabled in the event that the remote end indicates that they do not support the error correction mode we requested.
Richard Mudgett [Fri, 16 Jul 2010 20:18:54 +0000 (20:18 +0000)]
priexclusive in chan_dahdi.conf ignored when reloading dahdi module
During a reload, the priexclusive and outsignalling parameters are not
read in from the config file as intended. Unfortunately, they get set to
defaults as a result. This patch makes sure that they do not get set to
defaults during a reload.
(closes issue #17441)
Reported by: mtryfoss
Patches:
issue17441_v1.4.patch uploaded by rmudgett (license 664)
issue17441_v1.6.2.patch uploaded by rmudgett (license 664)
issue17441_trunk.patch uploaded by rmudgett (license 664)
Tested by: rmudgett
For pass through DTMF tones, measure the actual duration between the begin and end packets on the wire. If it is detected to be less than AST_MIN_DTMF_DURATION, trigger dtmf emulation.
Russell Bryant [Tue, 13 Jul 2010 16:51:18 +0000 (16:51 +0000)]
Access peer->cdr directly instead of through a saved off reference.
At this point in the code, it is possible that peer_cdr may be invalid.
Specifically, in the blind transfer code, CDRs are swapped between channels.
So, peer_cdr is no longer == peer->cdr.
The scenario that exposed a crash in this code was a blind transfer that hit
the system call limit, causing the transferee channel to get destroyed after
the transfer attempt failed. Even if it succeeds and this code doesn't crash,
this code was still trying to reset a CDR on a channel that was now owned by
a different thread, which is a BadThing(tm).
Jeff Peeler [Mon, 12 Jul 2010 20:34:51 +0000 (20:34 +0000)]
Make user removals and traversals thread safe in meetme.
Race conditions present in meetme involving the user list where a lack of
locking has the potential for a user to be removed during a traversal or as in
the case of the reporter after checking if the list is empty could cause a
crash. Fixing this was done by convering the userlist to an ao2 container.
Jeff Peeler [Mon, 12 Jul 2010 16:58:39 +0000 (16:58 +0000)]
Change ast_write to not stop generator when called from ast_prod.
For SIP channels configured with the progressinband option on, the ringback was
being immediately stopped. This problem was due to ast_prod being moved for a
deadlock fix in 259858. Prodding the channel after setting up the generator
triggered the check in ast_write to stop the generator. The fix here should
write the frame the same as was done before the call to ast_prod was moved.
Correct how 100, 200, 300, etc. is said. Also add the crazy British numbers.
(closes issue #16102)
Reported by: Delvar
Patches:
say.conf.fix.patch uploaded by Delvar (license 908)
(plus a few additional fixes and simplifications by me)
projects / thirdparty / asterisk.git / log
