https://origsvn.digium.com/svn/asterisk/trunk
................
r226890 | file | 2009-11-02 14:08:54 -0400 (Mon, 02 Nov 2009) | 18 lines
Merged revisions 226889 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r226889 | file | 2009-11-02 14:08:11 -0400 (Mon, 02 Nov 2009) | 11 lines
Fix a bug where the recorded privacy introduction file would not get removed if the caller hung up
while the called party had not yet answered.
This was fixed by introducing an argument to the 'n' option which, when enabled, removes the introduction
file under all scenarios. This was done to preserve the behavior that has existed for quite some time.
(closes issue #14674)
Reported by: ulogic
Patches:
bug14674.patch uploaded by jpeeler (license 325)
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@226892 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This backport resolves some issues handling audio frames during FAX processing,
and ensures that the FAX application doesn't accidentally get notified of a T.38
switchover at the end of a successful FAX.
(issue #16127)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@225870 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r225445 | dvossel | 2009-10-22 14:55:51 -0500 (Thu, 22 Oct 2009) | 50 lines
SIP TCP/TLS: move client connection setup/write into tcp helper thread, various related locking/memory fixes.
What this patch fixes
1.Moves sip TCP/TLS connection setup into the TCP helper thread:
Connection setup takes awhile and before this it was being
done while holding the monitor lock.
2.Moves TCP/TLS writing to the TCP helper thread: Through the
use of a packet queue and an alert pipe, the TCP helper thread
can now be woken up to write data as well as read data.
3.Locking error: sip_xmit returned an XMIT_ERROR without giving
up the tcptls_session lock. This lock has been completely removed
from sip_xmit and placed in the new sip_tcptls_write() function.
4.Memory leak: When creating a tcptls_client the tls_cfg was alloced
but never freed unless the tcptls_session failed to start. Now the
session_args for a sip client are an ao2 object which frees the
tls_cfg on destruction.
5.Pointer to stack variable: During sip_prepare_socket the creation
of a client's ast_tcptls_session_args was done on the stack and
stored as a pointer in the newly created tcptls_session. Depending
on the events that followed, there was a slight possibility that
pointer could have been accessed after the stack returned. Given
the new changes, it is always accessed after the stack returns
which is why I found it.
Notable code changes
1.I broke tcptls.c's ast_tcptls_client_start() function into two
functions. One for creating and allocating the new tcptls_session,
and a separate one for starting and handling the new connection.
This allowed me to create the tcptls_session, launch the helper
thread, and then establish the connection within the helper thread.
2.Writes to a tcptls_session are now done within the helper thread.
This is done by using an alert pipe to wake up the thread if new
data needs to be sent. The thread's sip_threadinfo object contains
the alert pipe as well as the packet queue.
3.Since the threadinfo object contains the alert pipe, it must now be
accessed outside of the helper thread for every write (queuing of a
packet). For easy lookup, I moved the threadinfo objects from a
linked list to an ao2_container.
(closes issue #13136)
Reported by: pabelanger
Tested by: dvossel, whys
(closes issue #15894)
Reported by: dvossel
Tested by: dvossel
Review: https://reviewboard.asterisk.org/r/380/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@225490 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r223832 | jpeeler | 2009-10-12 18:48:09 -0500 (Mon, 12 Oct 2009) | 15 lines
Merged revisions 223804 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r223804 | jpeeler | 2009-10-12 18:12:50 -0500 (Mon, 12 Oct 2009) | 8 lines
Ensure ringing continues for branched calls after progress is received
While waiting for an answer, don't send progress for branched calls
for which ringing was sent.
(closes issue #15028)
Reported by: fnordian
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@223834 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r223652 | kpfleming | 2009-10-12 09:25:29 -0500 (Mon, 12 Oct 2009) | 13 lines
Remove automatic switching from T.38 to voice mode in chan_sip.
chan_sip has some code to automatically switch from T.38 mode to voice mode when
a voice frame is written to the channel while it is in T.38 mode; this was
intended to handle the situation when a FAX transmission has ended and the channel
is not yet hung up, but is causing problems at the beginning of FAX sessions as
well when there are still voice frames 'in flight' at the time the T.38 negotiation
completes. This patch removes the automatic switchover, and changes app_fax to
explicitly switch off T.38 mode when the FAX transmission process ends.
(closes issue #16025)
Reported by: jamicque
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@223654 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r223330 | kpfleming | 2009-10-09 15:58:44 -0500 (Fri, 09 Oct 2009) | 10 lines
Initiate T.38 switchover when acting as called party, regardless of FAX direction.
SendFAX() and ReceiveFAX() can be given options to indicate whether they should
act as the calling or called party; this mode should be used to decide whether
to initiate a switchover to T.38, not the direction that the FAX transfer will
take place.
(closes issue #16039)
Reported by: jamicque
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@223332 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r222176 | kpfleming | 2009-10-05 20:24:24 -0500 (Mon, 05 Oct 2009) | 27 lines
Recorded merge of revisions 222152 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r222152 | kpfleming | 2009-10-05 20:16:36 -0500 (Mon, 05 Oct 2009) | 20 lines
Fix ao2_iterator API to hold references to containers being iterated.
See Mantis issue for details of what prompted this change.
Additional notes:
This patch changes the ao2_iterator API in two ways: F_AO2I_DONTLOCK
has become an enum instead of a macro, with a name that fits our
naming policy; also, it is now necessary to call
ao2_iterator_destroy() on any iterator that has been
created. Currently this only releases the reference to the container
being iterated, but in the future this could also release other
resources used by the iterator, if the iterator implementation changes
to use additional resources.
(closes issue #15987)
Reported by: kpfleming
Review: https://reviewboard.asterisk.org/r/383/
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@222186 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r220833 | jpeeler | 2009-09-29 11:58:29 -0500 (Tue, 29 Sep 2009) | 12 lines
Make deletion of temporary greetings work properly with IMAP_STORAGE
When imapgreetings was set to yes, the message was being deleted but wasn't
actually being expunged. When imapgreetings was set to no, the file based
message was not being deleted at all. All good now!
(closes issue #14949)
Reported by: noahisaac
Patches:
vm_tempgreeting_removal.patch uploaded by noahisaac (license 748),
modified by me
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@220835 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r219818 | tilghman | 2009-09-22 16:43:22 -0500 (Tue, 22 Sep 2009) | 17 lines
Merged revisions 219816 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r219816 | tilghman | 2009-09-22 16:37:03 -0500 (Tue, 22 Sep 2009) | 10 lines
When IMAP variables were changed during a reload, Voicemail did not use the new values.
This change introduces a configuration version variable, which ensures that
connections with the old values are not reused but are allowed to expire
normally.
(closes issue #15934)
Reported by: viniciusfontes
Patches:
20090922__issue15934.diff.txt uploaded by tilghman (license 14)
Tested by: viniciusfontes
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@219820 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r216438 | oej | 2009-09-04 16:02:34 +0200 (Fre, 04 Sep 2009) | 35 lines
Merged revisions 216430 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r216430 | oej | 2009-09-04 15:45:48 +0200 (Fre, 04 Sep 2009) | 27 lines
Make apps send PROGRESS control frame for early media and fix too early media issue in SIP
The issue at hand is that some legacy (dying) PBX systems send empty media frames on PRI
links *before* any call progress. The SIP channel receives these frames and by default
signals 183 Session progress and starts sending media. This will cause phones to
play silence and ignore the later 180 ringing message. A bad user experience.
The fix is twofold:
- We discovered that asterisk apps that support early media ("noanswer") did not send
any PROGRESS frame to indicate early media. Fixed.
- We introduce a setting in chan_sip so that users can disable any relay of media frames
before the outbound channel actually indicates any sort of call progress.
In 1.4, 1.6.0 and 1.6.1, this will be disabled for backward compatibility. In later versions
of Asterisk, this will be enabled. We don't assume that it will change your Asterisk
phone experience - only for the better.
We encourage third-party application developers to make sure that if they have applications
that wants to send early media, add a PROGRESS control frame transmission to make sure that
all channel drivers actually will start sending early media. This has not been the default
in Asterisk previous to this patch, so if you got inspiration from our code, you need to
update accordingly. Sorry for the trouble and thanks for your support.
This code has been running for a few months in a large scale installation (over 250
servers with PRI and/or BRI links to old PBX systems).
That's no proof that this is an excellent patch, but, well, it's tested :-)
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@216646 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r215338 | dhubbard | 2009-09-01 20:16:59 -0500 (Tue, 01 Sep 2009) | 18 lines
Merged revisions 215270 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r215270 | dhubbard | 2009-09-01 18:04:52 -0500 (Tue, 01 Sep 2009) | 12 lines
Use strrchr() so SoftHangup will correctly truncate multi-hyphen channel names
In general channel names are in the form Foo/Bar-Z, but the channel name
could have multiple hyphens and look like Foo/B-a-r-Z. Use strrchr to
truncate the channel name at the last hyphen.
(closes issue #15810)
Reported by: dhubbard
Patches:
dw-softhangup-1.4.patch uploaded by dhubbard (license 733)
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@215375 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r213833 | jpeeler | 2009-08-24 11:43:57 -0500 (Mon, 24 Aug 2009) | 14 lines
Fix storage of greetings when using IMAP_STORAGE
The store macro was not getting called preventing storage of IMAP greetings
at all. This has been corrected along with fixing checking if the
imapgreetings option is turned on to store the greeting in IMAP. Lastly,
the attachment filename was incorrectly using the full path instead of just
the basename, which was causing problems with retrieval of the greeting.
(closes issue #14950)
Reported by: noahisaac
(closes issue #15729)
Reported by: lmadsen
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@213835 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r213697 | kpfleming | 2009-08-21 16:39:51 -0500 (Fri, 21 Aug 2009) | 12 lines
Ensure that realtime mailboxes properly report status on subscription.
This patch modifies app_voicemail's response to mailbox status subscriptions
(via the internal event system) to ensure that a subscription triggers an
explicit poll of the mailbox, so the subscriber can get an immediate cached
event with that status. Previously, the cache was only populated with the
status of non-realtime mailboxes.
(closes issue #15717)
Reported by: natmlt
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@213699 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r213404 | jpeeler | 2009-08-20 16:33:11 -0500 (Thu, 20 Aug 2009) | 12 lines
Fix greeting retrieval from IMAP
Properly check for the current voicemail state and if it doesn't exist,
create it.
(closes issue #14597)
Reported by: wtca
Patches:
14597_v2.patch uploaded by mmichelson (license 60)
Tested by: jpeeler
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@213412 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r211040 | tilghman | 2009-08-07 13:17:41 -0500 (Fri, 07 Aug 2009) | 21 lines
Merged revisions 211038 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r211038 | tilghman | 2009-08-07 13:16:28 -0500 (Fri, 07 Aug 2009) | 14 lines
QUEUE_MEMBER_LIST _really_ wants the interface name, not the membername.
This is a partial revert of revision 82590, which was an attempted cleanup,
but in reality, it broke QUEUE_MEMBER_LIST, which has always been intended
as a method by which component interfaces could be queried from the queue.
Membername isn't useful here, because that field cannot be used to obtain
further information about the member. See the documentation on
QUEUE_MEMBER_LIST, RemoveQueueMember, QUEUE_MEMBER_PENALTY, and the various
AMI commands which take a member argument for further justification.
(closes issue #15664)
Reported by: rain
Patches:
app_queue-queue_member_list.diff uploaded by rain (license 327)
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@211047 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r209839 | russell | 2009-08-01 06:02:07 -0500 (Sat, 01 Aug 2009) | 20 lines
Merged revisions 209838 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r209838 | russell | 2009-08-01 05:59:05 -0500 (Sat, 01 Aug 2009) | 13 lines
Modify how Playtones() is used in Milliwatt() to resolve gain issue.
When Milliwatt() was changed internally to use Playtones() so that the proper
tone was used, it introduced a drop in gain in the output signal. So, use
the playtones API directly and specify a volume argument such that the output
matches the gain of the original Milliwatt() code.
(closes issue #15386)
Reported by: rue_mohr
Patches:
issue_15386.rev2.diff uploaded by russell (license 2)
Tested by: rue_mohr
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@209841 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r209256 | kpfleming | 2009-07-27 16:21:43 -0500 (Mon, 27 Jul 2009) | 10 lines
Make T.38 switchover in ReceiveFAX synchronous.
In receive mode, if the channel that ReceiveFAX is running on supports T.38,
we should *always* attempt to switch T.38, rather than listening for an incoming
CNG tone and only triggering on that. The channel may be using a low-bitrate
codec that distorts the CNG tone, the sending FAX endpoint may not send CNG
at all, or there could be a variety of other reasons that we don't detect it,
but in all those cases if T.38 is available we certainly want to use it.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@209262 65c4cc65-6c06-0410-ace0-fbb531ad65f3
........
r208622 | mmichelson | 2009-07-24 14:24:28 -0500 (Fri, 24 Jul 2009) | 16 lines
Don't impose an arbitrary limit on member lines in queues.conf
I know what some of you are thinking: "UGH! Mark, why are you using
ast_strdup and ast_free for the string when you can just use ast_strdupa
and let the memory free itself?! Have the bats been chewing on your brain
again?"
Based on past experiences, I don't like using ast_strdupa inside a loop.
It's a good way to potentially exhaust stack space. Also, since this only
happens when reloading queues, I don't think that heap allocations and
frees are going to be a huge problem.
(closes issue #15559)
Reported by: amorsen
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@208661 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r208464 | kpfleming | 2009-07-23 16:57:24 -0500 (Thu, 23 Jul 2009) | 46 lines
Rework of T.38 negotiation and UDPTL API to address interoperability problems
Over the past couple of months, a number of issues with Asterisk
negotiating (and successfully completing) T.38 sessions with various
endpoints have been found. This patch attempts to address many of
them, primarily focused around ensuring that the endpoints'
MaxDatagram size is honored, and in addition by ensuring that T.38
session parameter negotiation is performed correctly according to the
ITU T.38 Recommendation.
The major changes here are:
1) T.38 applications in Asterisk (app_fax) only generate/receive IFP
packets, they do not ever work with UDPTL packets. As a result of
this, they cannot be allowed to generate packets that would overflow
the other endpoints' MaxDatagram size after the UDPTL stack adds any
error correction information. With this patch, the application is told
the maximum *IFP* size it can generate, based on a calculation using
the far end MaxDatagram size and the active error correction mode on
the T.38 session. The same is true for sending *our* MaxDatagram size
to the remote endpoint; it is computed from the value that the
application says it can accept (for a single IFP packet) combined with
the active error correction mode.
2) All treatment of T.38 session parameters as 'capabilities' in
chan_sip has been removed; these parameters are not at all like
audio/video stream capabilities. There are strict rules to follow for
computing an answer to a T.38 offer, and chan_sip now follows those
rules, using the desired parameters from the application (or channel)
that wants to accept the T.38 negotiation.
3) chan_sip now stores and forwards ast_control_t38_parameters
structures for tracking 'our' and 'their' T.38 session parameters;
this greatly simplifies negotiation, especially for pass-through
calls.
4) Since T.38 negotiation without specifying parameters or receiving
the final negotiated parameters is not very worthwhile, the
AST_CONTROL_T38 control frame has been removed. A note has been added
to UPGRADE.txt about this removal, since any out-of-tree applications
that use it will no longer function properly until they are upgraded
to use AST_CONTROL_T38_PARAMETERS.
Review: https://reviewboard.asterisk.org/r/310/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@208484 65c4cc65-6c06-0410-ace0-fbb531ad65f3
