This should fix talk call progress on analog lines.
(closes issue #12178)
Reported by: michael-fig
Patches:
20080717__bug12178.diff.txt uploaded by Corydon76 (license 14)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@131790 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Sept 12 last year). It was moved then to prevent a memory leak.
Since then, the same memory leak recurred and was fixed in a
better way.
Now it has been found that the placement of this init_queue
call can cause problems if a realtime queue has values changed
to an empty string. The problem is that the default value
for that queue parameter would not be set.
(closes issue #13084)
Reported by: elbriga
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@131369 65c4cc65-6c06-0410-ace0-fbb531ad65f3
is removed from the calling channel once the caller
is finished in the queue. This could have weird con-
sequences when dialing local queue members when multiple
transfers occur on a single call.
Also fixed a memory leak that would occur when an
attended transfer occurred from a queue member.
(closes issue #13047)
Reported by: festr
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@131299 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Reported by: murf
The problem was that, esoteric as it is, because the hangerupper
context immediately preceded the std-priv-extent macro, that
the checking code accidentally would fall from traversing hangerupper
into the std-priv-exten macro, where it would hit the hangerupper
in the 'includes', and proceed into an infinite recursion.
A small fix to traverse into the statements of the context instead
of the context solves this issue.
I also added some commented out printfs for debug, which were pretty
handy in the face of a dorky gdb.
This was a problem around since the package was first written;
but evidently pretty rare in turning up in the field.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@131242 65c4cc65-6c06-0410-ace0-fbb531ad65f3
just when a remote callerid is set. Also, if not set in the user, allow the
remote CallerID to pass through.
(closes issue #12875)
Reported by: dimas
Patches:
20080714__bug12875.diff.txt uploaded by Corydon76 (license 14)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@130889 65c4cc65-6c06-0410-ace0-fbb531ad65f3
be sure there are no audiohooks present on the channels
involved. This fixed a one-way audio situation I had in
my test setup. I couldn't find any open issues that suggested
one-way audio with regards to mixmonitor (or other audiohook)
usage, though.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@130792 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This should make the Agent always report the correct device state, even when
the underlying channel is used for other purposes.
(closes issue #12773)
Reported by: davidw
Patches:
20080710__bug12773.diff.txt uploaded by Corydon76 (license 14)
Tested by: davidw
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@130102 65c4cc65-6c06-0410-ace0-fbb531ad65f3
added a very obvious runtime warning if this condition reoccurs, so the developer who broke it can be chastised into fixing it :-)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@129966 65c4cc65-6c06-0410-ace0-fbb531ad65f3
the destination call number matching to be more strict and reliable.
(closes issue #12963)
Reported by: jpgrayson
Patches:
chan_iax2_dup_new_fix3.patch uploaded by jpgrayson (license 492)
Tested by: jpgrayson, Corydon76
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@129803 65c4cc65-6c06-0410-ace0-fbb531ad65f3
core instead of being P2P bridged. When the core regenerated
the rfc2833 packet for the outbound leg, the SSRC would be different
than the RTP audio on the call leg causing DTMF detection issues on
the far end.
(closes issue #12955)
Reported by: tonyredstone
Patches:
dynamic_rtp.patch uploaded by tsearle (license 373)
Tested by: tonyredstone
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@129436 65c4cc65-6c06-0410-ace0-fbb531ad65f3
since it should solve bugs people are experiencing. Specifically,
there are times where communication with the IMAP server causes
system calls to block forever. If this should happen when querying
the mailbox so that chan_sip's do_monitor thread can send MWI to
a phone, it means that SIP calls cannot be processed any more.
The timeout options are outlined in doc/imapstorage.txt. Defaults
for the timeouts are sixty seconds.
(closes issue #12987)
Reported by: mthomasslo
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@129158 65c4cc65-6c06-0410-ace0-fbb531ad65f3
route set for the call.
----
This comment was added a while ago and today it hit me badly.
/* OEJ: Possible issue that may need a check:
If we have a proxy route between us and the device,
should we care about resolving the contact
or should we just send it?
*/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@128950 65c4cc65-6c06-0410-ace0-fbb531ad65f3
and don't hold the pvt lock while destroying the ast_channel.
(closes issue #13014)
Reported by: jpgrayson
Patches:
chan_iax2_ast_iax2_new2.patch uploaded by jpgrayson (license 492)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@128795 65c4cc65-6c06-0410-ace0-fbb531ad65f3
for thread identifiers to be duplicated. By using a globally-unique monotonically-
increasing integer, this is now avoided.
(closes issue #13009)
Reported by: jpgrayson
Patches:
chan_iax2_dyn_threadnum.patch uploaded by jpgrayson (license 492)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@128639 65c4cc65-6c06-0410-ace0-fbb531ad65f3
and b) completes contexts correctly when the extension is ambiguous.
(closes issue #12980)
Reported by: licedey
Patches:
20080703__bug12980.diff.txt uploaded by Corydon76 (license 14)
Tested by: Corydon76
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@127973 65c4cc65-6c06-0410-ace0-fbb531ad65f3
