aboutsummaryrefslogtreecommitdiffstats
path: root/channels
AgeCommit message (Collapse)AuthorFilesLines
2010-05-28Merged revisions 266292 via svnmerge from dvossel1-11/+25
https://origsvn.digium.com/svn/asterisk/trunk ........ r266292 | dvossel | 2010-05-28 12:55:38 -0500 (Fri, 28 May 2010) | 9 lines fixes crash when creation of UDPTL fails (closes issue #17264) Reported by: falves11 Patches: issue_17264_reviewboard_fix.diff uploaded by dvossel (license 671) issue_17264_1.6.2_reviewboard_fix.diff uploaded by dvossel (license 671) Tested by: falves11 ........ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@266293 f38db490-d61c-443f-a65b-d21fe96a405b
2010-05-26Merged revisions 266006 via svnmerge from dvossel1-0/+1
https://origsvn.digium.com/svn/asterisk/trunk ........ r266006 | dvossel | 2010-05-26 13:32:51 -0500 (Wed, 26 May 2010) | 8 lines fixes failed SIP Directed pickup resulting in dead channel (closes issue #17339) Reported by: one47 Patches: sip_magic_pickup2 uploaded by one47 (license 23) Tested by: one47, dvossel ........ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@266007 f38db490-d61c-443f-a65b-d21fe96a405b
2010-05-26Recorded merge of revisions 265842 via svnmerge from mmichelson1-2/+3
https://origsvn.digium.com/svn/asterisk/trunk ........ r265842 | mmichelson | 2010-05-26 09:41:55 -0500 (Wed, 26 May 2010) | 9 lines Re-enable "always" option for videosupport option in sip.conf. (closes issue #17016) Reported by: twilson Patches: 17016.patch uploaded by mmichelson (license 60) Tested by: devmod ........ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@265890 f38db490-d61c-443f-a65b-d21fe96a405b
2010-05-25Merged revisions 265698 via svnmerge from mmichelson1-16/+5
https://origsvn.digium.com/svn/asterisk/trunk ........ r265698 | mmichelson | 2010-05-25 15:59:04 -0500 (Tue, 25 May 2010) | 12 lines Properly use peer's outboundproxy for outbound REGISTERs. The logic used in transmit_register to get the outboundproxy for a peer was flawed since this value would be overridden shortly afterwards when create_addr was called. In addition, this also fixes some logic used when parsing users.conf so that the peer name is placed in the internally-generated register string so that an outboundproxy set in the Asterisk GUI will be used for outbound REGISTERs. ........ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@265699 f38db490-d61c-443f-a65b-d21fe96a405b
2010-05-25fixes build issue with zapteldvossel1-0/+2
(closes issue 0017394) 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.6.2@265615 f38db490-d61c-443f-a65b-d21fe96a405b
2010-05-24Merged revisions 265451 via svnmerge from mmichelson1-0/+2
https://origsvn.digium.com/svn/asterisk/trunk ........ r265451 | mmichelson | 2010-05-24 17:05:15 -0500 (Mon, 24 May 2010) | 8 lines Print openh323 log to the Asterisk console. (closes issue #17109) Reported by: under Patches: logstream.diff uploaded by under (license 914) ........ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@265452 f38db490-d61c-443f-a65b-d21fe96a405b
2010-05-24Merged revisions 265449 via svnmerge from mmichelson1-11/+19
https://origsvn.digium.com/svn/asterisk/trunk ........ r265449 | mmichelson | 2010-05-24 16:44:30 -0500 (Mon, 24 May 2010) | 11 lines Allow type=user SIP endpoints to be loaded properly from realtime. (closes issue #16021) Reported by: Guggemand Patches: realtime-type-fix.patch uploaded by Guggemand (license 897) (altered by me slightly to avoid ref leaks) Tested by: Guggemand ........ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@265450 f38db490-d61c-443f-a65b-d21fe96a405b
2010-05-21Merged revisions 265087 via svnmerge from mmichelson1-0/+1
https://origsvn.digium.com/svn/asterisk/trunk ........ r265087 | mmichelson | 2010-05-21 15:38:14 -0500 (Fri, 21 May 2010) | 7 lines Be sure to set the sin_family on the proxy when allocating. (closes issue #17157) Reported by: stuarth ........ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@265088 f38db490-d61c-443f-a65b-d21fe96a405b
2010-05-19Merged revisions 264452 via svnmerge from mmichelson1-1/+1
https://origsvn.digium.com/svn/asterisk/trunk ........ r264452 | mmichelson | 2010-05-19 16:29:08 -0500 (Wed, 19 May 2010) | 86 lines Fix transcode_via_sln option with SIP calls and improve PLC usage. From reviewboard: The problem here is a bit complex, so try to bear with me... It was noticed by a Digium customer that generic PLC (as configured in codecs.conf) did not appear to actually be having any sort of benefit when packet loss was introduced on an RTP stream. I reproduced this issue myself by streaming a file across an RTP stream and dropping approx. 5% of the RTP packets. I saw no real difference between when PLC was enabled or disabled when using wireshark to analyze the RTP streams. After analyzing what was going on, it became clear that one of the problems faced was that when running my tests, the translation paths were being set up in such a way that PLC could not possibly work as expected. To illustrate, if packets are lost on channel A's read stream, then we expect that PLC will be applied to channel B's write stream. The problem is that generic PLC can only be done when there is a translation path that moves from some codec to SLINEAR. When I would run my tests, I found that every single time, read and write translation paths would be set up on channel A instead of channel B. There appeared to be no real way to predict which channel the translation paths would be set up on. This is where Kevin swooped in to let me know about the transcode_via_sln option in asterisk.conf. It is supposed to work by placing a read translation path on both channels from the channel's rawreadformat to SLINEAR. It also will place a write translation path on both channels from SLINEAR to the channel's rawwriteformat. Using this option allows one to predictably set up translation paths on all channels. There are two problems with this, though. First and foremost, the transcode_via_sln option did not appear to be working properly when I was placing a SIP call between two endpoints which did not share any common formats. Second, even if this option were to work, for PLC to be applied, there had to be a write translation path that would go from some format to SLINEAR. It would not work properly if the starting format of translation was SLINEAR. The one-line change presented in this review request in chan_sip.c fixed the first issue for me. The problem was that in sip_request_call, the jointcapability of the outbound channel was being set to the format passed to sip_request_call. This is nativeformats of the inbound channel. Because of this, when ast_channel_make_compatible was called by app_dial, both channels already had compatibly read and write formats. Thus, no translation path was set up at the time. My change is to set the jointcapability of the sip_pvt created during sip_request_call to the intersection of the inbound channel's nativeformats and the configured peer capability that we determined during the earlier call to create_addr. Doing this got the translation paths set up as expected when using transcode_via_sln. The changes presented in channel.c fixed the second issue for me. First and foremost, when Asterisk is started, we'll read codecs.conf to see the value of the genericplc option. If this option is set, and ast_write is called for a frame with no data, then we will attempt to fill in the missing samples for the frame. The implementation uses a channel datastore for maintaining the PLC state and for creating a buffer to store PLC samples in. Even when we receive a frame with data, we'll call plc_rx so that the PLC state will have knowledge of the previous voice frame, which it can use as a basis for when it comes time to actually do a PLC fill-in. So, reviewers, now I ask for your help. First off, there's the one line change in chan_sip that I have put in. Is it right? By my logic it seems correct, but I'm sure someone can tell me why it is not going to work. This is probably the change I'm least concerned about, though. What concerns me much more is the set of changes in channel.c. First off, am I even doing it right? When I run tests, I can clearly see that when PLC is activated, I see a significant increase in RTP traffic where I would expect it to be. However, in my humble opinion, the audio sounds kind of crappy whenever the PLC fill-in is done. It sounds worse to me than when no PLC is used at all. I need someone to review the logic I have used to be sure that I'm not misusing anything. As far as I can see my pointer arithmetic is correct, and my use of AST_FRIENDLY_OFFSET should be correct as well, but I'm sure someone can point out somewhere where I've done something incorrectly. As I was writing this review request up, I decided to give the code a test run under valgrind, and I find that for some reason, calls to plc_rx are causing some invalid reads. Apparently I'm reading past the end of a buffer somehow. I'll have to dig around a bit to see why that is the case. If it's obvious to someone reviewing, speak up! Finally, I have one other proposal that is not reflected in my code review. Since without transcode_via_sln set, one cannot predict or control where a translation path will be up, it seems to me that the current practice of using PLC only when transcoding to SLINEAR is not useful. I recommend that once it has been determined that the method used in this code review is correct and works as expected, then the code in translate.c that invokes PLC should be removed. Review: https://reviewboard.asterisk.org/r/622/ ........ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@264453 f38db490-d61c-443f-a65b-d21fe96a405b
2010-05-19Merged revisions 264331 via svnmerge from dvossel1-0/+3
https://origsvn.digium.com/svn/asterisk/trunk ........ r264331 | dvossel | 2010-05-19 14:21:04 -0500 (Wed, 19 May 2010) | 13 lines fixes crash in check_rtp_timeout During deadlock avoidance the sip dialog pvt is locked and unlocked. When this occurs we have no guarantee the pvt's owner is still valid. We were trying to access the pvt's owner after this without checking to see if it still existed first. (closes issue #17271) Reported by: under Patches: check_rtp_timeout.diff uploaded by under (license 914) Tested by: dvossel ........ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@264332 f38db490-d61c-443f-a65b-d21fe96a405b
2010-05-17backport of DAHDI dynamic buffer policy dialstring optiondvossel1-44/+75
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@263293 f38db490-d61c-443f-a65b-d21fe96a405b
2010-05-13Merged revisions 263069 via svnmerge from rmudgett1-1/+1
https://origsvn.digium.com/svn/asterisk/trunk ........ r263069 | rmudgett | 2010-05-13 17:01:36 -0500 (Thu, 13 May 2010) | 1 line Fix inverted logic in cli command: ss7 set debug on/off ........ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@263070 f38db490-d61c-443f-a65b-d21fe96a405b
2010-05-13Merged revisions 262897 via svnmerge from russell1-1/+1
https://origsvn.digium.com/svn/asterisk/trunk ........ r262897 | russell | 2010-05-13 10:36:12 -0500 (Thu, 13 May 2010) | 4 lines Fix an off by one error that causes a crash. Thanks to Raymond Burke for pointing it out. ........ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@262898 f38db490-d61c-443f-a65b-d21fe96a405b
2010-05-11Merged revisions 262414 via svnmerge from pabelanger1-2/+2
https://origsvn.digium.com/svn/asterisk/trunk ........ r262414 | pabelanger | 2010-05-11 15:26:17 -0400 (Tue, 11 May 2010) | 8 lines Improve logging information for misconfigured contexts (closes issue #17238) Reported by: pprindeville Patches: chan_sip-bug17238.patch uploaded by pprindeville (license 347) Tested by: pprindeville ........ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@262415 f38db490-d61c-443f-a65b-d21fe96a405b
2010-05-10Merged revisions 262236 via svnmerge from dvossel1-1/+8
https://origsvn.digium.com/svn/asterisk/trunk ........ r262236 | dvossel | 2010-05-10 13:36:10 -0500 (Mon, 10 May 2010) | 11 lines fixes crash in chan_console There is a race condition between console_hangup() and start_stream(). It is possible for console_hangup() to be called and then the stream thread to begin after the hangup. To avoid this a check in start_stream() to make sure the pvt-owner still exists while the pvt lock is held is made. If the owner is gone that means the channel hung up and start_stream should be aborted. ........ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@262237 f38db490-d61c-443f-a65b-d21fe96a405b
2010-05-06Merged revisions 261560 via svnmerge from tilghman1-1/+1
https://origsvn.digium.com/svn/asterisk/trunk ........ r261560 | tilghman | 2010-05-06 10:39:10 -0500 (Thu, 06 May 2010) | 8 lines Permit more lines within a SIP body to be parsed. The example given within the related issue showed 120 lines, which was mostly a result of the body being XML. (closes issue #17179) Reported by: khw ........ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@261563 f38db490-d61c-443f-a65b-d21fe96a405b
2010-05-06Merged revisions 261451 via svnmerge from tzafrir1-1/+1
https://origsvn.digium.com/svn/asterisk/trunk ........ r261451 | tzafrir | 2010-05-06 10:27:31 +0300 (ה', 06 מאי 2010) | 4 lines When failing to configure, don't destroy 'cfg' twice Fixes a crash when some config section had an incorrect channel config. ........ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@261453 f38db490-d61c-443f-a65b-d21fe96a405b
2010-05-05Merged revisions 261314 via svnmerge from pabelanger1-3/+7
https://origsvn.digium.com/svn/asterisk/trunk ................ r261314 | pabelanger | 2010-05-05 14:43:03 -0400 (Wed, 05 May 2010) | 19 lines Merged revisions 261274 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r261274 | pabelanger | 2010-05-05 12:42:22 -0400 (Wed, 05 May 2010) | 12 lines Registration fix for SIP realtime. 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.6.2@261315 f38db490-d61c-443f-a65b-d21fe96a405b
2010-05-04Merged revisions 254450 via svnmerge from mnicholson1-19/+94
https://origsvn.digium.com/svn/asterisk/trunk ........ r254450 | kpfleming | 2010-03-25 10:27:31 -0500 (Thu, 25 Mar 2010) | 49 lines Improve handling of T.38 re-INVITEs that arrive before a T.38-capable 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: http://svn.digium.com/svn/asterisk/branches/1.6.2@260884 f38db490-d61c-443f-a65b-d21fe96a405b
2010-04-30Merged revisions 260437 via svnmerge from jpeeler1-0/+1
https://origsvn.digium.com/svn/asterisk/trunk ................ r260437 | jpeeler | 2010-04-30 17:36:49 -0500 (Fri, 30 Apr 2010) | 18 lines Merged revisions 260434 via svnmerge from 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: http://svn.digium.com/svn/asterisk/branches/1.6.2@260441 f38db490-d61c-443f-a65b-d21fe96a405b
2010-04-29Merged revisions 260231 via svnmerge from rmudgett1-12/+22
https://origsvn.digium.com/svn/asterisk/trunk ................ r260231 | rmudgett | 2010-04-29 17:44:14 -0500 (Thu, 29 Apr 2010) | 33 lines Merged revisions 260195 via svnmerge from 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: http://svn.digium.com/svn/asterisk/branches/1.6.2@260234 f38db490-d61c-443f-a65b-d21fe96a405b
2010-04-28Merged revisions 259957 via svnmerge from mmichelson1-3/+7
https://origsvn.digium.com/svn/asterisk/trunk ........ r259957 | mmichelson | 2010-04-28 17:34:15 -0500 (Wed, 28 Apr 2010) | 11 lines Don't override peer context with domain context. (closes issue #17040) Reported by: pprindeville Patches: asterisk-1.6-bugid17040.patch uploaded by pprindeville (license 347) Tested by: pprindeville Review: https://reviewboard.asterisk.org/r/565/ ........ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@259959 f38db490-d61c-443f-a65b-d21fe96a405b
2010-04-28Merged revisions 259870 via svnmerge from dvossel1-5/+14
https://origsvn.digium.com/svn/asterisk/trunk ................ r259870 | dvossel | 2010-04-28 16:20:03 -0500 (Wed, 28 Apr 2010) | 39 lines Merged revisions 259858 via svnmerge from 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: http://svn.digium.com/svn/asterisk/branches/1.6.2@259899 f38db490-d61c-443f-a65b-d21fe96a405b
2010-04-27Merged revisions 259538 via svnmerge from rmudgett1-4/+19
https://origsvn.digium.com/svn/asterisk/trunk ................ r259538 | rmudgett | 2010-04-27 17:18:09 -0500 (Tue, 27 Apr 2010) | 18 lines Merged revisions 259531 via svnmerge from 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: http://svn.digium.com/svn/asterisk/branches/1.6.2@259616 f38db490-d61c-443f-a65b-d21fe96a405b
2010-04-27Merged revisions 259307 via svnmerge from rmudgett1-0/+1
https://origsvn.digium.com/svn/asterisk/trunk ................ r259307 | rmudgett | 2010-04-27 13:29:33 -0500 (Tue, 27 Apr 2010) | 21 lines Merged revisions 259270 via svnmerge from 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: http://svn.digium.com/svn/asterisk/branches/1.6.2@259310 f38db490-d61c-443f-a65b-d21fe96a405b
2010-04-26Merged revisions 258934 via svnmerge from lmadsen1-2/+2
https://origsvn.digium.com/svn/asterisk/trunk ........ r258934 | lmadsen | 2010-04-26 10:59:34 -0500 (Mon, 26 Apr 2010) | 7 lines Small error in the T.140 RTP port verbose log. (closes issue #16988) Reported by: frawd Patches: chan_sip_sdp_verbose_fix.diff uploaded by frawd (license 610) Tested by: russell ........ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@258935 f38db490-d61c-443f-a65b-d21fe96a405b
2010-04-21Merged revisions 258305 via svnmerge from dvossel1-1/+1
https://origsvn.digium.com/svn/asterisk/trunk ........ r258305 | dvossel | 2010-04-21 13:13:36 -0500 (Wed, 21 Apr 2010) | 12 lines fixes issue with double "sip:" in header field 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: http://svn.digium.com/svn/asterisk/branches/1.6.2@258314 f38db490-d61c-443f-a65b-d21fe96a405b
2010-04-15Merged revisions 257493 via svnmerge from tilghman1-0/+15
https://origsvn.digium.com/svn/asterisk/trunk ................ r257493 | tilghman | 2010-04-15 15:30:15 -0500 (Thu, 15 Apr 2010) | 20 lines Merged revisions 257467 via svnmerge from 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: http://svn.digium.com/svn/asterisk/branches/1.6.2@257510 f38db490-d61c-443f-a65b-d21fe96a405b
2010-04-13Merged revisions 257191 via svnmerge from tilghman1-1/+1
https://origsvn.digium.com/svn/asterisk/trunk ........ r257191 | tilghman | 2010-04-13 14:17:48 -0500 (Tue, 13 Apr 2010) | 10 lines Also unref the pvt when we delete the provisional keepalive job. (closes issue #16774) Reported by: kowalma Patches: 20100315__issue16774.diff.txt uploaded by tilghman (license 14) Tested by: falves11, jamicque Review: https://reviewboard.asterisk.org/r/591/ ........ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@257210 f38db490-d61c-443f-a65b-d21fe96a405b
2010-04-06CallerID channel DAHDI port FXS are empty after the first call.rmudgett1-7/+21
The bug is exposed if MFC/R2 support is built into asterisk (i.e., openr2.h is present in the include path). Code that unconditionally clears the CallerID name and number is included. Also fixed a malformed if test in mkintf() added by issue 15883. Converted the if statement to a switch statement for clarity. Regression of the issue 15883 fix. (closes issue #16968) Reported by: grecco Patches: issue16968.patch uploaded by rmudgett (license 664) (closes issue #16747) Reported by: viniciusfontes git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@256368 f38db490-d61c-443f-a65b-d21fe96a405b
2010-04-06Merged revisions 256265 via svnmerge from rmudgett1-7/+8
https://origsvn.digium.com/svn/asterisk/trunk ................ r256265 | rmudgett | 2010-04-05 19:39:44 -0500 (Mon, 05 Apr 2010) | 12 lines Merged revisions 256225 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r256225 | rmudgett | 2010-04-05 19:10:16 -0500 (Mon, 05 Apr 2010) | 5 lines DAHDI/PRI call to pri_channel_bridge() not protected by PRI lock. SWP-1231 ABE-2163 ........ ................ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@256268 f38db490-d61c-443f-a65b-d21fe96a405b
2010-04-02Merged revisions 256015 via svnmerge from russell1-24/+8
https://origsvn.digium.com/svn/asterisk/trunk ................ r256015 | russell | 2010-04-02 18:46:45 -0500 (Fri, 02 Apr 2010) | 16 lines Merged revisions 256014 via svnmerge from 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: http://svn.digium.com/svn/asterisk/branches/1.6.2@256018 f38db490-d61c-443f-a65b-d21fe96a405b
2010-03-30Merged revisions 255410 via svnmerge from russell1-1/+1
https://origsvn.digium.com/svn/asterisk/trunk ................ r255410 | russell | 2010-03-30 15:56:26 -0500 (Tue, 30 Mar 2010) | 9 lines Merged revisions 255409 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r255409 | russell | 2010-03-30 15:56:00 -0500 (Tue, 30 Mar 2010) | 2 lines Don't kill Asterisk if the H323 listener does not start. ........ ................ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@255413 f38db490-d61c-443f-a65b-d21fe96a405b
2010-03-25Merged revisions 254718 via svnmerge from russell1-0/+1
https://origsvn.digium.com/svn/asterisk/trunk ........ r254718 | russell | 2010-03-25 15:08:40 -0500 (Thu, 25 Mar 2010) | 2 lines chan_usbradio depends on alsa. ........ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@254721 f38db490-d61c-443f-a65b-d21fe96a405b
2010-03-25Initialize stream to avoid a compilation error.seanbright1-1/+1
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@254548 f38db490-d61c-443f-a65b-d21fe96a405b
2010-03-25Fix potential crashes from trying to reference nonexistent RTP streams.mmichelson1-7/+14
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@254542 f38db490-d61c-443f-a65b-d21fe96a405b
2010-03-20Merged revisions 253536 via svnmerge from russell1-1/+1
https://origsvn.digium.com/svn/asterisk/trunk ........ r253536 | russell | 2010-03-20 06:33:30 -0500 (Sat, 20 Mar 2010) | 4 lines Use SHRT_MAX instead of MAXSHORT. These changes fix build issues I had with this module on FreeBSD. ........ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@253595 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.6.2@253158 f38db490-d61c-443f-a65b-d21fe96a405b
2010-03-15Merged revisions 252442 via svnmerge from tilghman1-6/+22
https://origsvn.digium.com/svn/asterisk/trunk ........ r252442 | tilghman | 2010-03-14 23:25:35 -0500 (Sun, 14 Mar 2010) | 7 lines THIS IS NOT PYTHON. Indentation doesn't matter, only braces do. (closes issue #17025) Reported by: smurfix Patches: sip.patch uploaded by smurfix (license 547) ........ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@252444 f38db490-d61c-443f-a65b-d21fe96a405b
2010-03-13Merged revisions 252089 via svnmerge from twilson4-29/+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.6.2@252137 f38db490-d61c-443f-a65b-d21fe96a405b
2010-03-12Merged revisions 252088 via svnmerge from moy1-0/+2
https://origsvn.digium.com/svn/asterisk/trunk ........ r252088 | moy | 2010-03-12 16:57:40 -0500 (Fri, 12 Mar 2010) | 1 line add missing mfcr2_skip_category setting ........ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@252090 f38db490-d61c-443f-a65b-d21fe96a405b
2010-03-12Merged revisions 251946 via svnmerge from rmudgett1-1/+1
https://origsvn.digium.com/svn/asterisk/trunk ........ r251946 | rmudgett | 2010-03-12 13:05:40 -0600 (Fri, 12 Mar 2010) | 1 line Doxegen this chan_dahdi lock. ........ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@251991 f38db490-d61c-443f-a65b-d21fe96a405b
2010-03-03Merged revisions 250481 via svnmerge from jpeeler1-0/+12
https://origsvn.digium.com/svn/asterisk/trunk ................ r250481 | jpeeler | 2010-03-03 13:06:06 -0600 (Wed, 03 Mar 2010) | 22 lines Merged revisions 250480 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r250480 | jpeeler | 2010-03-03 13:04:11 -0600 (Wed, 03 Mar 2010) | 15 lines Make sure to clear red alarm after polarity reversal. 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.6.2@250484 f38db490-d61c-443f-a65b-d21fe96a405b
2010-03-03Merged revisions 250395 via svnmerge from dvossel1-3/+8
https://origsvn.digium.com/svn/asterisk/trunk ................ r250395 | dvossel | 2010-03-03 12:03:19 -0600 (Wed, 03 Mar 2010) | 22 lines Merged revisions 250394 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r250394 | dvossel | 2010-03-03 12:02:27 -0600 (Wed, 03 Mar 2010) | 16 lines fixes problem with duplicate TXREQ packets 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.6.2@250396 f38db490-d61c-443f-a65b-d21fe96a405b
2010-03-03Merged revisions 250246 via svnmerge from dvossel1-1/+1
https://origsvn.digium.com/svn/asterisk/trunk ........ r250246 | dvossel | 2010-03-02 18:18:28 -0600 (Tue, 02 Mar 2010) | 2 lines fixes signed to unsigned int comparision issue for FaxMaxDatagram value. ........ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@250253 f38db490-d61c-443f-a65b-d21fe96a405b
2010-03-02Merged revisions 249893 via svnmerge from dvossel14-11/+25
https://origsvn.digium.com/svn/asterisk/trunk ........ r249893 | dvossel | 2010-03-02 13:08:38 -0600 (Tue, 02 Mar 2010) | 11 lines fixes adaptive jitterbuffer configuration When configuring the adaptive jitterbuffer, the target_extra value not only could not be set from the configuration, but was not even being set to its proper default. This value is required in order for the adaptive jitterbuffer to work correctly. To resolve this a config option has been added to expose this value to the conf files, and a default value is provided when no config specific value is present. ........ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@249895 f38db490-d61c-443f-a65b-d21fe96a405b
2010-03-01Merged revisions 249538 via svnmerge from jpeeler1-35/+2
https://origsvn.digium.com/svn/asterisk/trunk ................ r249538 | jpeeler | 2010-03-01 11:11:31 -0600 (Mon, 01 Mar 2010) | 18 lines Merged revisions 249536 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r249536 | jpeeler | 2010-03-01 11:02:03 -0600 (Mon, 01 Mar 2010) | 11 lines Modify queued frames from local channels to not set the other side to up 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.6.2@249580 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: overlap_receiving_trunk.diff.txt uploaded by alecdavis (license 585) Tested by: alecdavis git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@249321 f38db490-d61c-443f-a65b-d21fe96a405b
2010-02-27Merged revisions 249235 via svnmerge from kpfleming1-0/+1
https://origsvn.digium.com/svn/asterisk/trunk ................ r249235 | kpfleming | 2010-02-27 09:08:35 -0500 (Sat, 27 Feb 2010) | 9 lines Merged revisions 249234 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r249234 | kpfleming | 2010-02-27 09:07:59 -0500 (Sat, 27 Feb 2010) | 1 line add a reference to the now-published IAX2 RFC ........ ................ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@249238 f38db490-d61c-443f-a65b-d21fe96a405b
2010-02-26Merged revisions 249101 via svnmerge from mmichelson1-0/+2
https://origsvn.digium.com/svn/asterisk/trunk ................ r249101 | mmichelson | 2010-02-26 11:04:58 -0600 (Fri, 26 Feb 2010) | 14 lines Merged revisions 249100 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r249100 | mmichelson | 2010-02-26 11:04:29 -0600 (Fri, 26 Feb 2010) | 8 lines For T.38 reINVITEs treat a 606 the same as a 488. (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.6.2@249104 f38db490-d61c-443f-a65b-d21fe96a405b
generated by cgit v1.2.3 (git 2.25.1) at 2024-04-20 02:49:29 +0000