aboutsummaryrefslogtreecommitdiffstats
path: root/channels
AgeCommit message (Collapse)AuthorFilesLines
2010-07-16priexclusive in chan_dahdi.conf ignored when reloading dahdi modulermudgett1-2/+4
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 git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@277419 f38db490-d61c-443f-a65b-d21fe96a405b
2010-07-09Fix logging message for stale nonce.pabelanger1-1/+1
(closes issue #17582) Reported by: kenner Patches: chan_sip.c.diff uploaded by kenner (license 1040) Tested by: lmadsen git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@275241 f38db490-d61c-443f-a65b-d21fe96a405b
2010-07-07Close the DAHDI FD on error when processing chan_dahdi toneduration config ↵rmudgett1-0/+1
parameter. git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@274579 f38db490-d61c-443f-a65b-d21fe96a405b
2010-07-06Add option to not do a call forward on 482 Loop Detectedtwilson1-10/+19
Asterisk has always set up a forwarded call when receiving a 482 Loop Detected. This prevents handling the call failure by just continuing on in the dialplan. Since this would be a change in behavior, the new option to disable this behavior is forwardloopdetected which defaults to 'yes'. Review: https://reviewboard.asterisk.org/r/764/ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@274280 f38db490-d61c-443f-a65b-d21fe96a405b
2010-07-05Command 'stop gracefully' doesn't.tilghman2-16/+44
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@273981 f38db490-d61c-443f-a65b-d21fe96a405b
2010-07-02Have the DEADLOCK_AVOIDANCE macro warn when an unlock fails, to help catch ↵tilghman4-8/+23
potentially large software bugs. (closes issue #17407) Reported by: pdf Patches: 20100527__issue17407.diff.txt uploaded by tilghman (license 14) Review: https://reviewboard.asterisk.org/r/751/ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@273793 f38db490-d61c-443f-a65b-d21fe96a405b
2010-07-02Fix various typos, reported by Lintiantzafrir3-9/+9
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@273640 f38db490-d61c-443f-a65b-d21fe96a405b
2010-06-29Allow the "useragent" value to be restored into memory from the realtime ↵tilghman1-6/+8
backend. This value is purely informational. It does not alter configuration at all. (closes issue #16029) Reported by: Guggemand Patches: realtime-useragent.patch uploaded by Guggemand (license 897) Tested by: Guggemand git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@273060 f38db490-d61c-443f-a65b-d21fe96a405b
2010-06-28Decode URI in contact header of 302 response.mmichelson1-0/+1
ABE-2352 git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@272804 f38db490-d61c-443f-a65b-d21fe96a405b
2010-06-24ss_thread calls pri_grab without lock during overlap dialrmudgett1-0/+2
Recent changes to chan_dahdi with relation to overlap dialing call pri_grab without first obtaining a lock. (closes issue #17414) Reported by: pdf Patches: bug17414.patch uploaded by jpeeler (license 325) git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@272446 f38db490-d61c-443f-a65b-d21fe96a405b
2010-06-22Decrease the module ref count in sip_hangup when SIP_DEFER_BYE_ON_TRANSFER ↵mnicholson1-0/+1
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.4@271902 f38db490-d61c-443f-a65b-d21fe96a405b
2010-06-22Modify chan_sip's packet generation api to automatically calculate the ↵mnicholson1-71/+61
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/ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@271689 f38db490-d61c-443f-a65b-d21fe96a405b
2010-06-18Eliminate deadlock potential in dahdi_fixup().jpeeler1-2/+2
(This is a backport of 269307, committed to trunk by rmudgett.) 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. (closes issue #17261) Reported by: aragon git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@271335 f38db490-d61c-443f-a65b-d21fe96a405b
2010-06-16Need to lock the agent chan before access its internal bits.qwell1-0/+2
Pointed out by russellb on asterisk-dev mailing list. git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@270980 f38db490-d61c-443f-a65b-d21fe96a405b
2010-06-16fixes chan_iax2 race conditiondvossel1-6/+4
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.4@270866 f38db490-d61c-443f-a65b-d21fe96a405b
2010-06-15Merged revisions 270658 via svnmerge from twilson1-18/+20
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.4@270724 f38db490-d61c-443f-a65b-d21fe96a405b
2010-06-15fixes FXS port still ringing when answered, as reported by Tzafrir on dev-list.alecdavis1-0/+1
(issue #17067) Reported by: tzafrir Tested by: alecdavis git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@270404 f38db490-d61c-443f-a65b-d21fe96a405b
2010-06-09Don't stop Asterisk if chan_oss fails to register 'Console' (due to another ↵russell1-1/+1
channel driver already claiming it). git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@269495 f38db490-d61c-443f-a65b-d21fe96a405b
2010-06-04Comment out a rule that likes to break the chan_h323 build randomly.russell1-2/+6
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@268053 f38db490-d61c-443f-a65b-d21fe96a405b
2010-06-01Fix formatting issue with previous patch.pabelanger1-4/+3
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@266580 f38db490-d61c-443f-a65b-d21fe96a405b
2010-06-01Missing fallback to audio fax feature when T.38 re-INVITE failedpabelanger1-14/+26
When a T.38 re-INVITE failed with an 488 or 606 answer, we should fallback to audio fax by send a re-re-INVITE without T.38. The function is backported from 1.6 asterisk. (closes issue #16795) Reported by: vrban (closes issue #16692) Reported by: vrban Patches: t38_fallback_to_audio_v3.patch uploaded by vrban (license 756) Tested by: lmadsen, vrban, haggard https://reviewboard.asterisk.org/r/514/ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@266579 f38db490-d61c-443f-a65b-d21fe96a405b
2010-05-26add dahdi_func_write to zap_tech structuredvossel1-0/+1
This was supposed to be committed with r263292, the back-port of teh DAHDI buffer policy dial string option git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@266140 f38db490-d61c-443f-a65b-d21fe96a405b
2010-05-25fixes build issue with zapteldvossel1-0/+2
(closes issue #17394) 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.4@265613 f38db490-d61c-443f-a65b-d21fe96a405b
2010-05-17backport of DAHDI buffer policy dial string optiondvossel1-21/+100
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@263292 f38db490-d61c-443f-a65b-d21fe96a405b
2010-05-05Registration fix for SIP realtime.pabelanger1-3/+7
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.4@261274 f38db490-d61c-443f-a65b-d21fe96a405b
2010-04-30Ensure channel state is not incorrectly set in the case of a very early answer.jpeeler1-1/+1
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.4@260434 f38db490-d61c-443f-a65b-d21fe96a405b
2010-04-29DTMF CallerID detection problems.rmudgett1-12/+22
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.4@260195 f38db490-d61c-443f-a65b-d21fe96a405b
2010-04-28resolves deadlocks in chan_localdvossel1-5/+14
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.4@259858 f38db490-d61c-443f-a65b-d21fe96a405b
2010-04-27DAHDI "WARNING" message is confusing and vaguermudgett1-3/+14
"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.4@259531 f38db490-d61c-443f-a65b-d21fe96a405b
2010-04-27hidecalleridname parameter in chan_dahdi.confrmudgett1-0/+1
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.4@259270 f38db490-d61c-443f-a65b-d21fe96a405b
2010-04-15Don't recreate peer, when responding to a repeated deregistration attempt.tilghman1-0/+15
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.4@257467 f38db490-d61c-443f-a65b-d21fe96a405b
2010-04-06DAHDI/PRI call to pri_channel_bridge() not protected by PRI lock.rmudgett1-7/+8
SWP-1231 ABE-2163 git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@256225 f38db490-d61c-443f-a65b-d21fe96a405b
2010-04-02Resolve a deadlock that occurs due to a pointless call to ast_bridged_channel()russell1-24/+8
(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.4@256014 f38db490-d61c-443f-a65b-d21fe96a405b
2010-03-30Don't kill Asterisk if the H323 listener does not start.russell1-1/+1
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@255409 f38db490-d61c-443f-a65b-d21fe96a405b
2010-03-20Resolve a number of FreeBSD build issues.russell1-1/+1
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@253631 f38db490-d61c-443f-a65b-d21fe96a405b
2010-03-17Revert API change in release branchestwilson4-8/+8
This re-renames ast_rtp_update_source to ast_rtp_new_source git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@253158 f38db490-d61c-443f-a65b-d21fe96a405b
2010-03-13Merged revisions 252089 via svnmerge from twilson4-28/+22
https://origsvn.digium.com/svn/asterisk/trunk ........ r252089 | twilson | 2010-03-12 16:04:51 -0600 (Fri, 12 Mar 2010) | 20 lines Only change the RTP ssrc when we see that it has changed 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: http://svn.digium.com/svn/asterisk/branches/1.4@252175 f38db490-d61c-443f-a65b-d21fe96a405b
2010-03-12Forward declaring dahdi_pri was already done.rmudgett1-1/+0
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@251997 f38db490-d61c-443f-a65b-d21fe96a405b
2010-03-12Make chan_dahdi wakeup_sub() prototype not conditional.rmudgett1-5/+2
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@251986 f38db490-d61c-443f-a65b-d21fe96a405b
2010-03-03Make sure to clear red alarm after polarity reversal.jpeeler1-0/+12
From the issue: The automatic overnight line tests (or manual ones) used on UK (BT) lines causes a red alarm on a dahdi / TDM400P connected channel. This is because the line uses voltage tests (battery loss) and polarity reversal. The polarity reversal causes chan_dahdi to initiate v23 CallerID processing but during this the event DAHDI_EVENT_NOALARM is ignored so that the alarm is never cleared. (closes issue #14163) Reported by: jedi98 Patches: chan_dahdi-1.4-inalarm.diff uploaded by jedi98 (license 653) Tested by: mattbrown, Chainsaw, mikeeccleston git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@250480 f38db490-d61c-443f-a65b-d21fe96a405b
2010-03-03fixes problem with duplicate TXREQ packetsdvossel1-3/+8
When Asterisk receives an IAX2 TXREQ packet, try_transfer() will call store_by_transfercallno() to link the chan_iax2_pvt struct into iax_transfercallno_pvts. If a duplicate TXREQ packet is received for the same call, the pvt struct will be linked into iax_transfercallno_pvts multiple times. This patch fixes this. Thanks rain for debugging this and providing a patch! (closes issue #16904) Reported by: rain Patches: iax2-double-txreq-fix.diff uploaded by rain (license 327) Tested by: rain, dvossel git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@250394 f38db490-d61c-443f-a65b-d21fe96a405b
2010-03-01Modify queued frames from local channels to not set the other side to upjpeeler1-30/+1
In this case, attended transfers were broken due to ast_feature_request_and_dial detecting the channel being set to up before the answer frame could be read and therefore failing to mark the channel as ready. This fix is a regression fix for 244785, which should continue to work properly as well. (closes issue #16816) Reported by: jamhed Tested by: jamhed, corruptor git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@249536 f38db490-d61c-443f-a65b-d21fe96a405b
2010-02-27overlap receiving: automatically send CALL PROCEEDING when dialplan startsalecdavis1-1/+14
Following Q.931 5.2.4 When the user has determined that sufficient call information has been received the user shall stop T302 and send CALL PROCEEDING to the network. Previously timeouts were possible if the dialplan took a long time to issue any response back to the network. Verified that our local TELCO also does the same. (issue #16789) Reported by: alecdavis Patches: based on overlap_receiving_trunk.diff.txt uploaded by alecdavis (license 585) Tested by: alecdavis (closes issue #16789) git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@249365 f38db490-d61c-443f-a65b-d21fe96a405b
2010-02-27add a reference to the now-published IAX2 RFCkpfleming1-0/+1
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@249234 f38db490-d61c-443f-a65b-d21fe96a405b
2010-02-26For T.38 reINVITEs treat a 606 the same as a 488.mmichelson1-0/+2
(closes issue #16792) Reported by: vrban Patches: t38_606.patch uploaded by vrban (license 756) git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@249100 f38db490-d61c-443f-a65b-d21fe96a405b
2010-02-23fixes invite with replaces deadlockdvossel1-14/+46
(closes issue #16862) Reported by: pwalker Patches: replaces_deadlock_1.4 uploaded by dvossel (license 671) Tested by: pwalker, dvossel git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@248396 f38db490-d61c-443f-a65b-d21fe96a405b
2010-02-19Merged revision 247904 fromrmudgett1-27/+5
https://origsvn.digium.com/svn/asterisk/be/branches/C.2-... .......... r247904 | rmudgett | 2010-02-19 10:49:44 -0600 (Fri, 19 Feb 2010) | 49 lines Make chan_misdn DTMF processing consistent with other channel technologies. The processing of DTMF tones on the receiving side of an ISDN channel is inconsistent with the way it is handled in other channels, especially DAHDI analog. This causes DTMF tones sent from an ISDN phone to be doubled at the connected party. We are using the following 2 options of misdn.conf 1) astdtmf=yes 2) senddtmf=yes Option one is necessary because the asterisk DSP DTMF detection is better than mISDN's internal DSP. Not as many false positives. Option two is necessary to transmit DTMF tones end to end when mISDN channels are connected to SIP channels with out of band DTMF for example. The symptom is that DTMF tones sent by an ISDN phone are doubled on the way through asterisk when two mISDN channels are connected with a Local channel in between or if it is bridged to an analog channel. The doubling of DTMF tones is because DTMF is passed inband to asterisk by the mISDN channel and passed out of band once again after the release of the DTMF tone. Passing it inband is wrong. Neither an analog channel nor SIP channel passes DTMF inband if configured to inband DTMF. Analog and SIP channels filter out the DTMF tones because they use the voice frames returned by ast_dsp_process. But chan_misdn passes the unfiltered input voice frames instead. To overcome one aspect of the problem, the doubling of DTMF tones when two mISDN channels are directly bridged, someone made an 'optimization', where in that case the DTMF tone passed out-of-band to the peer channel is not translated to an inband tone at the transmit side. This optimization is bad because it does not work in general. For example, analog channels or mISDN channels when bridged through an intermediary local channel will generate DTMF tones from out-of-band information. Also, of course, it must not be done when there is no inband DTMF available. This patch fixes the issue. Now chan_misdn will filter the received inband DTMF signal the same as other channel types. Another change included: No need to build an extra translation path because ast_process_dsp does it if required. Patches: misdn-dtmf.patch JIRA ABE-2080 git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@247910 f38db490-d61c-443f-a65b-d21fe96a405b
2010-02-09Fixes iaxs and iaxsl size off by one issue.dvossel1-3/+3
2^15 = 32768 which is the maximum allowed iax2 callnumber. Creating the iaxs and iaxsl array of size 32768 means the maximum callnumber is actually out of bounds. This causes a nasty crash. (closes issue #15997) Reported by: exarv Patches: iax_fix.diff uploaded by dvossel (license 671) git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@245792 f38db490-d61c-443f-a65b-d21fe96a405b
2010-02-04Change channel state on local channels for busy,answer,ring.jpeeler1-0/+32
Previously local channels channel state never changed. This became problematic when the state of the other side of the local channel was lost, for example during a masquerade. Changing the state of the local channel allows for the scenario to be detected when the channel state is set to ringing, but the peer isn't ringing. The specific problem scenario is described in 164201. Although this was noted on one of the issues, here is the tested dialplan verified to work: exten => 9700,1,Dial(Local/*9700@default&Local/#9700@default) exten => *9700,1,Set(GLOBAL(TESTCHAN)=${CHANNEL:0:${MATH(${LEN(${CHANNEL})}-1):0:2}}1) exten => *9700,n,wait(3) ;3 works, 1 did not exten => *9700,n,Dial(SIP/5001) exten => #9700,1,Wait(1) ;1 works, 3 did not exten => #9700,n,ChannelRedirect(${TESTCHAN},parkedcalls,701,1) (closes issue #14992) Reported by: davidw git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@244785 f38db490-d61c-443f-a65b-d21fe96a405b
2010-02-01Revert previous chan_local fix (r236981) and fix instead by destroying ↵tilghman1-3/+1
expired frames in the queue. (closes issue #16525) Reported by: kobaz Patches: 20100126__issue16525.diff.txt uploaded by tilghman (license 14) 20100129__issue16525__1.6.0.diff.txt uploaded by tilghman (license 14) Tested by: kobaz, atis (closes issue #16581) Reported by: ZX81 (closes issue #16681) Reported by: alexr1 git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@244070 f38db490-d61c-443f-a65b-d21fe96a405b
generated by cgit v1.2.3 (git 2.25.1) at 2024-09-22 12:09:46 +0000