variable to the block where it is used. This allows one
less #ifdef HAVE_PRI to clutter things up.
Thanks to Tzafrir for pointing this out on #asterisk-dev
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@133038 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Prior to this change, a spiraled INVITE would cause a 482
Loop Detected to be sent to the caller. With this change,
if a potential loop is detected, the Request-URI is inspected
to see if it has changed from what was originally received. If
pedantic mode is on, then this inspection is fully RFC 3261
compliant. If pedantic mode is not on, then a string comparison
is used to test the equality of the two R-URIs.
This has been tested by using OpenSER to rewrite the R-URI
and send the INVITE back to Asterisk.
(closes issue #7403)
Reported by: stephen_dredge
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@132790 65c4cc65-6c06-0410-ace0-fbb531ad65f3
correct registration of AMI actions in chan_dahdi; in zap-only mode, only register the Zap flavors of the actions (and use Zap prefixes for headers and acks), but in dahdi+zap mode, register both Zap and DAHDI flavors of actions
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@132787 65c4cc65-6c06-0410-ace0-fbb531ad65f3
seems to be in regards to an error message when retransmit fails. This
is frequently misunderstood as a failure of Asterisk, not a failure of
the network to reach the other party.
This document tries to assist the Asterisk user in sorting out these
issues by explaining the logic and pointing at some possible
causes. Hopefully, we will get other questions now :-)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@132645 65c4cc65-6c06-0410-ace0-fbb531ad65f3
registration). Related to revisions 132466 in trunk, and 132467 in 1.6.0. Earlier I had accidently tested 1.4 with a backport from those revisions,
so I didn't see this problem (oops).
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@132506 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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
