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.
(closes issue #16057;#17363)
Reported by: amorsen;davidw,alecdavis
Patches:
bug16057.diff4.txt uploaded by alecdavis (license 585)
Tested by: ramonpeek, davidw, alecdavis
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@287682 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Specifically, before prompting to record a prepended message the capacity is
checked first. If the mailbox is full the extension will be reprompted.
ABE-2517
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@286941 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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.
ABE-2473
(related to issue #2342)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@286679 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@286113 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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.
(closes issue #17888)
Reported by: zerohalo
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@286070 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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.
(closes issue #17673)
Reported by: Guggemand
Review: https://reviewboard.asterisk.org/r/903/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@286059 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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).
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@285889 65c4cc65-6c06-0410-ace0-fbb531ad65f3
ast_fileexists returns -1 for error and 0 for a non-existant file. The existing
code treated missing files as though they were existed.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@284881 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Handling of the relatedpeer structure associated with a
sip_pvt should be done during the final sip_destruction
function, not in sip_autodestruct.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@284703 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@283690 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@283380 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@283048 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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.
(closes issue #17712)
Reported by: nickb
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@282893 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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!).
(closes issue #17007)
Reported by: addix
Patches:
1001-reset-SSRC-original-channel.diff uploaded by addix (license 1006)
srcchange.diff uploaded by twilson (license 396)
Tested by: addix, twilson
Review: https://reviewboard.asterisk.org/r/862/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@282430 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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
(closes issue #17404)
Reported by: sdolloff
Patches:
bug17404.patch uploaded by jpeeler (license 325)
Tested by: sdolloff
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@281911 65c4cc65-6c06-0410-ace0-fbb531ad65f3
