https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r313001 | alecdavis | 2011-04-07 22:19:31 +1200 (Thu, 07 Apr 2011) | 13 lines
Fix ISDN calling subaddr User Specified Odd/Even Flag
Calculation of the Odd/Even flag was wrong.
Implement correct algo, and set odd/even=0 if data would be truncated.
Only allow automatic calculation of the O/E flag, don't let dialplan influence.
(closes issue #19062)
Reported by: festr
Patches:
bug19062.diff2.txt uploaded by alecdavis (license 585)
Tested by: festr, alecdavis, rmudgett
........
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@313005 f38db490-d61c-443f-a65b-d21fe96a405b
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r312949 | rmudgett | 2011-04-05 13:45:24 -0500 (Tue, 05 Apr 2011) | 6 lines
Crash if ISDN span layer 1 is down on initial load.
Regression from -r312575 B channel shifting during negotiation.
* Also combine updating the alarm flag with clearing the resetting flag.
........
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@312950 f38db490-d61c-443f-a65b-d21fe96a405b
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r312866 | rmudgett | 2011-04-05 10:38:14 -0500 (Tue, 05 Apr 2011) | 15 lines
Responding to OPTIONS packet with 404 because Asterisk not looking for "s" extension.
The get_destination() function was not using the "s" extension when the
request URI did not specify an extension. This is a regression caused
when the URI parsing code was extracted into parse_uri().
Made get_destination() substitute the "s" extension when the parsed URI
results in an empty string.
(closes issue #18348)
Reported by: shmaize
Patches:
issue18348_v1.8.patch uploaded by rmudgett (license 664)
Tested by: shmaize
........
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@312868 f38db490-d61c-443f-a65b-d21fe96a405b
If the user invokes 'dialplan add extension' into a non-existing context, the context will be created
and a message informing the user of the context being created will be issued in cli.
(closes issue #17431)
Reported by: leearcher
Patches:
context_auto_create.diff uploaded by kobaz (license 834)
Tested by: leearcher, kobaz, jrose
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@312678 f38db490-d61c-443f-a65b-d21fe96a405b
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r312575 | rmudgett | 2011-04-04 11:10:50 -0500 (Mon, 04 Apr 2011) | 52 lines
Merged revisions 312574 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r312574 | rmudgett | 2011-04-04 11:00:02 -0500 (Mon, 04 Apr 2011) | 45 lines
Merged revisions 312573 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r312573 | rmudgett | 2011-04-04 10:49:30 -0500 (Mon, 04 Apr 2011) | 38 lines
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.
(closes issue #18313)
Reported by: destiny6628
Tested by: rmudgett
JIRA SWP-2620
(closes issue #18231)
Reported by: destiny6628
Tested by: rmudgett
JIRA SWP-2924
(closes issue #18488)
Reported by: jpokorny
JIRA SWP-2929
JIRA AST-437 (The issues fixed here are most likely causing this JIRA issue.)
JIRA DAHDI-406
JIRA LIBPRI-33 (Stuck resetting flag likely fixed)
........
................
................
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@312579 f38db490-d61c-443f-a65b-d21fe96a405b
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r312509 | rmudgett | 2011-04-01 18:15:42 -0500 (Fri, 01 Apr 2011) | 22 lines
When a call going out an NT-PTMP port gets rejected, Asterisk crashes.
If a call is sent to an ISDN phone that rejects the call with
RELEASE_COMPLETE(cause: call reject(21), or busy(17)) Asterisk crashes.
I could not get my setup to crash. However, I could see the possibility
from a race condition between queuing an AST_CONTROL_BUSY to the core and
then queueing an AST_CONTROL_HANGUP. If the AST_CONTROL_BUSY is processed
before the AST_CONTROL_HANGUP is queued, the ast_channel could be
destroyed out from under chan_misdn.
Avoid this particular crash scenario by not queueing the
AST_CONTROL_HANGUP if the AST_CONTROL_BUSY was queued.
(closes issue #18408)
Reported by: wimpy
Patches:
issue18408_v1.8.patch uploaded by rmudgett (license 664)
Tested by: rmudgett, wimpy
JIRA SWP-2679
........
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@312510 f38db490-d61c-443f-a65b-d21fe96a405b
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r312461 | rmudgett | 2011-04-01 16:31:39 -0500 (Fri, 01 Apr 2011) | 25 lines
CallCompletionRequest()/CallCompletionCancel() exit non-zero if fail.
The CallCompletionRequest()/CallCompletionCancel() dialplan applications
exit nonzero on normal failure conditions. The nonzero exit causes the
dialplan to hangup immediately. The dialplan author has no opportunity to
report success/failure to the user.
* Made always return zero so the dialplan can continue.
* Made set CC_REQUEST_RESULT/CC_REQUEST_REASON and
CC_CANCEL_RESULT/CC_CANCEL_REASON channel variables respectively. Also
documented the values set.
* Reduced the warning about no core instance in CallCompletionCancel() to
a debug message. It is a normal event and should not be output at the
WARNING level.
(closes issue #18763)
Reported by: p_lindheimer
Patches:
ccss.patch uploaded by p lindheimer (license 558) Modified
Tested by: p_lindheimer, rmudgett
JIRA SWP-3042
........
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@312462 f38db490-d61c-443f-a65b-d21fe96a405b
In chan_dahdi.conf, the user can now use length 4 patterns in addition to the usual length 2 patterns. The s
ntax remains the same and the method used to track the pattern history will only change when using the length
4 patterns.
(closes issue SWP-3250)
Code:
jrose
rmudgett
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@312384 f38db490-d61c-443f-a65b-d21fe96a405b
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r312211 | alecdavis | 2011-04-01 22:03:11 +1300 (Fri, 01 Apr 2011) | 36 lines
Merged revisions 312210 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r312210 | alecdavis | 2011-04-01 21:47:29 +1300 (Fri, 01 Apr 2011) | 29 lines
Merged revisions 312174 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r312174 | alecdavis | 2011-04-01 21:29:49 +1300 (Fri, 01 Apr 2011) | 23 lines
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
Review: https://reviewboard.asterisk.org/r/1153/
........
................
................
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@312212 f38db490-d61c-443f-a65b-d21fe96a405b
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r312117 | alecdavis | 2011-04-01 20:32:12 +1300 (Fri, 01 Apr 2011) | 29 lines
Merged revisions 312103 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r312103 | alecdavis | 2011-04-01 20:25:54 +1300 (Fri, 01 Apr 2011) | 22 lines
Merged revisions 312070 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r312070 | alecdavis | 2011-04-01 19:46:56 +1300 (Fri, 01 Apr 2011) | 16 lines
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.
Happens on filebased or ODBC storage.
(issues #19032,#18582,#18692,#18998)
Reported by: alecdavis,tootai,afosorio
Review: https://reviewboard.asterisk.org/r/1153/
........
................
................
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@312118 f38db490-d61c-443f-a65b-d21fe96a405b
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r312022 | rmudgett | 2011-03-31 15:11:40 -0500 (Thu, 31 Mar 2011) | 14 lines
chan_misdn segfaults when DEBUG_THREADS is enabled.
The segfault happens because jb->mutexjb is uninitialized from the
ast_malloc(). The internals of ast_mutex_init() were assuming a nonzero
value meant mutex tracking initialization had already happened. Recent
changes to mutex tracking code to reduce excessive memory consumption
exposed this uninitialized value.
Converted misdn_jb_init() to use ast_calloc() instead of ast_malloc().
Also eliminated redundant zero initialization code in the routine.
(closes issue #18975)
Reported by: irroot
........
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@312023 f38db490-d61c-443f-a65b-d21fe96a405b
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r311612 | bbryant | 2011-03-23 17:45:46 -0400 (Wed, 23 Mar 2011) | 9 lines
Fix a possible crash in sip/reqresp_parser.c that is caused by a possible null
value.
(closes issue #18821)
Reported by: cmaj
Patches:
patch-reqresp_parser_sip_uri_domain_cmp_c_locale-crash-1.8.3-rc2.diff.tx
uploaded by cmaj (license 830)
........
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@311613 f38db490-d61c-443f-a65b-d21fe96a405b
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r311558 | twilson | 2011-03-22 19:24:53 -0700 (Tue, 22 Mar 2011) | 5 lines
Don't use static declared buf in parse_name_andor_addr
This function isn't used anywhere yet, but we definitely don't want
to keep the same value for buf between calls to the function.
........
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@311559 f38db490-d61c-443f-a65b-d21fe96a405b
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r311352 | jrose | 2011-03-18 11:19:05 -0500 (Fri, 18 Mar 2011) | 10 lines
Changes some print statements/events to use a blank string in place of NULL if the string in question is NULL.
This is supposed to improve Solaris compatibility since Solaris goes berserk when trying to output NULL strings.
(closes issue #18759)
Reported by: bklang
Patches:
null-strings.patch uploaded by bklang (license 919)
........
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@311373 f38db490-d61c-443f-a65b-d21fe96a405b
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r311297 | rmudgett | 2011-03-17 21:59:05 -0500 (Thu, 17 Mar 2011) | 12 lines
Race condition when ISDN CallRerouting/CallDeflection invoked.
The queued AST_CONTROL_BUSY could sometimes be processed before the
call_forward dial string is recognized.
* Moved setting the call_forwarding dial string after sending a response
to the initiator and just queue an empty frame to wake up the media thread
instead of an AST_CONTROL_BUSY.
* Added check for empty rerouting/deflection number and respond with an
error.
........
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@311298 f38db490-d61c-443f-a65b-d21fe96a405b
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r311295 | rmudgett | 2011-03-17 21:22:07 -0500 (Thu, 17 Mar 2011) | 35 lines
Merged revision 310986 from
https://origsvn.digium.com/svn/asterisk/be/branches/C.3-bier
..........
r310986 | rmudgett | 2011-03-16 13:56:28 -0500 (Wed, 16 Mar 2011) | 28 lines
Dial() o option broke when connected line feature added.
The patch restores the o option behavior and adds the ability to specify
the CallerID. The Dial o and f options are complementary to each other.
The o option stores the CallerID on the outgoing channel as the channel's
CallerID. The f option forces the CallerID sent by the outgoing channel.
o(x) - The argument 'x' is optional. If not present, then specify that
the CallerID that was present on the *calling* channel be stored as the
CallerID on the *called* channel. This was the behavior of Asterisk 1.0
and earlier. If present, then specify the CallerID stored on the *called*
channel. Note that o(${CALLERID(all)}) is similar to option o without
parameters.
f(x) - The argument 'x' is optional and its presence changes the behavior
of this option. If not present, then force the outgoing CallerID on a
call-forward or deflection to the dialplan extension for this Dial() using
a dialplan 'hint'. For example, some PSTNs do not allow CallerID to be
set to anything other than the numbers assigned to you. If present, then
force the outgoing CallerID to 'x'.
Patches:
jira_abe_2752_dial_fo_options.patch uploaded by rmudgett (license 664)
Tested by: rmudgett
JIRA ABE-2752
JIRA SWP-3096
..........
................
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@311296 f38db490-d61c-443f-a65b-d21fe96a405b
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r311197 | jrose | 2011-03-17 14:03:34 -0500 (Thu, 17 Mar 2011) | 11 lines
This fixes a nasty chanspy bug which was causing a channel leak every time a spied on channel made a call.
In addition to the above, it makes certain channel destruction occurs so that applications don't get stuck waiting for datastore destruction while monitored by chanspy.
(closes issue #18742)
Reported by: jkister
Tested by: jkister, jcovert, jrose
Review: http://reviewboard.digium.internal/r/106/
........
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@311198 f38db490-d61c-443f-a65b-d21fe96a405b
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r310902 | twilson | 2011-03-16 12:19:57 -0500 (Wed, 16 Mar 2011) | 43 lines
Merged revisions 310889 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r310889 | twilson | 2011-03-16 12:03:27 -0500 (Wed, 16 Mar 2011) | 36 lines
Merged revisions 310888 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r310888 | twilson | 2011-03-16 11:58:42 -0500 (Wed, 16 Mar 2011) | 29 lines
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
(closes issue #16625)
Reported by: sharvanek
Review: https://reviewboard.asterisk.org/r/1092/
Review: https://reviewboard.asterisk.org/r/1125/
........
................
................
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@310941 f38db490-d61c-443f-a65b-d21fe96a405b
https://origsvn.digium.com/svn/asterisk/branches/1.8
(closes issue #18693)
........
r310734 | may | 2011-03-15 00:45:53 +0300 (Tue, 15 Mar 2011) | 12 lines
Introduce t.38 parameters control functionality not full but enough for
Send/RcvFax support
Introduce t.38 controls between asterisk core and channel/proto layers.
Not all parameters are transferred from proto layers but *Fax apps
tested and work ok.
(issue #18693)
Reported by: benngard2
Patches:
issue-18693.patch uploaded by may213 (license 454)
........
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@310735 f38db490-d61c-443f-a65b-d21fe96a405b
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r310636 | rmudgett | 2011-03-14 11:50:59 -0500 (Mon, 14 Mar 2011) | 39 lines
Merged revisions 310635 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r310635 | rmudgett | 2011-03-14 11:47:54 -0500 (Mon, 14 Mar 2011) | 32 lines
Merged revisions 310633 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r310633 | rmudgett | 2011-03-14 11:38:24 -0500 (Mon, 14 Mar 2011) | 25 lines
"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.
(closes issue #18474)
Reported by: nivek
Patches:
callerid.c.1.patch uploaded by nivek (license 636) (with modifications)
Tested by: nivek
........
................
................
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@310637 f38db490-d61c-443f-a65b-d21fe96a405b
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r310462 | tilghman | 2011-03-12 14:27:54 -0600 (Sat, 12 Mar 2011) | 45 lines
Merged revisions 310448 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r310448 | tilghman | 2011-03-12 14:24:54 -0600 (Sat, 12 Mar 2011) | 38 lines
Recorded merge of revisions 310435 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r310435 | tilghman | 2011-03-12 14:22:07 -0600 (Sat, 12 Mar 2011) | 31 lines
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.
(closes issue #18910)
Reported by: alexandrekeller
Patches:
20110304__issue18919__1.6.2.diff.txt uploaded by tilghman (license 14)
20110304__issue18919__1.4.diff.txt uploaded by tilghman (license 14)
Tested by: alexandrekeller
........
................
................
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@310500 f38db490-d61c-443f-a65b-d21fe96a405b
rmudgett