https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r205804 | dvossel | 2009-07-10 11:23:59 -0500 (Fri, 10 Jul 2009) | 31 lines
SIP registration auth loop caused by stale nonce
If an endpoint sends two registration requests in a very short
period of time with the same nonce, both receive 401 responses
from Asterisk, each with a different nonce (the second 401
containing the current nonce and the first one being stale).
If the endpoint responds to the first 401, it does not match
the current nonce so Asterisk sends a third 401 with a newly
generated nonce (which updates the current nonce)... Now if
the endpoint responds to the second 401, it does not match the
current nonce either and Asterisk sends a fourth 401 with a
newly generated nonce... This loop goes on and on.
There appears to be a simple fix for this. If the nonce from
the request does not match our nonce, but is a good response
to a previous nonce, instead of sending a 401 with a newly
generated nonce, use the current one instead. This breaks
the loop as the nonce is not updated until a response is
received. Additional logic has been added to make sure no
nonce can be responded to twice though.
(closes issue #15102)
Reported by: Jamuel
Patches:
patch-bug_0015102 uploaded by Jamuel (license 809)
nonce_sip.diff uploaded by dvossel (license 671)
Tested by: Jamuel
Review: https://reviewboard.asterisk.org/r/289/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@205840 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The transmit_audio() and transmit_t38() functions in app_fax have processing
loops that are supposed to wait for frames to arrive on the channel and then
handle them, but they also have short timeouts so that the loops can have
watchdog timers and do other required processing. This commit changes the loops
to not actually call ast_read() and attempt to process the returned frame
unless a frame actually arrived, eliminating hundreds of LOG_DEBUG messages
and slightly improving performance.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@205780 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r205775 | mmichelson | 2009-07-10 10:51:36 -0500 (Fri, 10 Jul 2009) | 10 lines
Ensure that outbound NOTIFY requests are properly routed through stateful proxies.
With this change, we make note of Record-Route headers present in any SUBSCRIBE
request that we receive so that our outbound NOTIFY requests will have the proper
Route headers in them.
(closes issue #14725)
Reported by: ibc
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@205776 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Revision 205696 did not quite fix all the issues with the T.38 negotiation
changes and app_fax; this patch corrects them, along with a couple of other
minor issues.
(closes issue #15480)
Reported by: dimas
Patches:
test2-15480.patch uploaded by dimas (license 88)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@205770 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Recent changes in T.38 negotiation in Asterisk caused these applications to
not respond when the other endpoint initiated a switchover to T.38; this
resulted in the T.38 switchover failing, and the FAX attempt to be made
using an audio connection, instead of T.38 (which would usually cause the
FAX to fail completely).
This patch corrects this problem, and the applications will now correctly
respond to the T.38 switchover request. In addition, the response will include
the appopriate T.38 session parameters based on what the other end offered
and what our end is capable of.
(closes issue #14849)
Reported by: afosorio
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@205696 65c4cc65-6c06-0410-ace0-fbb531ad65f3
pthread implementations. Casting it to an unsigned int fixes compiler warnings.
Tested on OpenBSD and Linux both 32 and 64 bit
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@205532 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r205349 | mmichelson | 2009-07-08 14:26:13 -0500 (Wed, 08 Jul 2009) | 14 lines
Prevent phantom calls to queue members.
If a caller were to hang up while a periodic announcement or position
were being said, the return value for those functions would incorrectly
indicate that the caller was still in the queue. With these changes,
the problem does not occur.
(closes issue #14631)
Reported by: latinsud
Patches:
queue_announce_ghost_call2.diff uploaded by latinsud (license 745)
(with small modification from me)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@205350 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Park() was not respecting the arguments passed to it. Any extension/context/priority
given to it was being ignored. This patch remedies this.
(closes issue #15380)
Reported by: DLNoah
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@205254 65c4cc65-6c06-0410-ace0-fbb531ad65f3
........
r205149 | russell | 2009-07-08 10:54:21 -0500 (Wed, 08 Jul 2009) | 8 lines
Make OpenSSL usage thread-safe.
OpenSSL is not thread-safe by default. However, making it thread safe is
very easy. We just have to provide a couple of callbacks. One callback
returns a thread ID. The other handles locking. For more information,
start with the "Is OpenSSL thread-safe?" question on the FAQ page of
openssl.org.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@205150 65c4cc65-6c06-0410-ace0-fbb531ad65f3
While doing some reading about OpenSSL, I noticed a couple of things that
needed to be improved with our usage of OpenSSL.
1) We had initialization of the library done in multiple modules. This has now
been moved to a core function that gets executed during Asterisk startup.
We already link OpenSSL into the core for TCP/TLS functionality, so this
was the most logical place to do it.
2) OpenSSL is not thread-safe by default. However, making it thread safe is
very easy. We just have to provide a couple of callbacks. One callback
returns a thread ID. The other handles locking. For more information,
start with the "Is OpenSSL thread-safe?" question on the FAQ page of
openssl.org.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@205120 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This change allows applications that request T.38 negotiation on a channel that
does not support it to get the proper indication that it is not supported, rather
than thinking that negotiation was started when it was not.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@204948 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Also go back and wrap all of the places that use the specific reverse charge
APIs with preprocessor conditionals.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@204919 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r204834 | rmudgett | 2009-07-02 16:59:43 -0500 (Thu, 02 Jul 2009) | 10 lines
Removed confusing warning message "Got Busy in Connected State"
If an incoming mISDN call is answered with the Answer application and a
subsequent Dial gets a busy endpoint then it is valid for that already
connected channel to get the busy indication. Asterisk will play the busy
tones until the dialplan plays something else or hangs up the call.
(closes issue #11974)
Reported by: fvdb
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@204835 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This is a continuation of revision 885 to LibPRI (Capture and expose the Reverse
Charging Indication IE on ISDN PRI) which added the ability to get/set Reverse
Charging Indication in LibPRI. This patch adds the ability to specify RCI on
the outbound leg of a PRI call from within Asterisk, by prefixing the dialed
number with a capital 'C' like:
...,Dial(DAHDI/g1/C4445556666)
And to read it off an inbound channel:
exten => s,1,Set(RCI=${CHANNEL(reversecharge)})
Thanks again to rmudgett for the thorough review.
(closes issue #13760)
Reported by: mrgabu
Review: https://reviewboard.asterisk.org/r/303/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@204749 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r204681 | dvossel | 2009-07-02 10:05:57 -0500 (Thu, 02 Jul 2009) | 14 lines
Improved mapping of extension states from combined device states.
This fixes a few issues with incorrect extension states and adds
a cli command, core show device2extenstate, to display all possible
state mappings.
(closes issue #15413)
Reported by: legart
Patches:
exten_helper.diff uploaded by dvossel (license 671)
Tested by: dvossel, legart, amilcar
Review: https://reviewboard.asterisk.org/r/301/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@204710 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r204556 | tilghman | 2009-06-30 15:23:51 -0500 (Tue, 30 Jun 2009) | 6 lines
More incorrect language codes, plus ensuring that regionalizations use the specified language, and not English for grammar.
(closes issue #15022)
Reported by: greenfieldtech
Patches:
20090519__issue15022.diff.txt uploaded by tilghman (license 14)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@204563 65c4cc65-6c06-0410-ace0-fbb531ad65f3
First of all, the code was unnecessary. The goal was to lock a channel
which was already locked. Second, the assumption of the deadlock avoidance
loop was that the sip_pvt was already locked and we were trying to get the
channel lock. The problem is that the sip_pvt was unlocked a few lines above.
Basically, I'm removing 5 lines of no-op.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@204530 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Kevin P. Fleming
Mark Michelson
David Vossel
Matthew Nicholson
Michiel van Baak
Jason Parker
David Brooks
Tilghman Lesher
Sean Bright
Russell Bryant
Luigi Rizzo
Richard Mudgett
Ryan Brindley