https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r218401 | jpeeler | 2009-09-14 16:47:11 -0500 (Mon, 14 Sep 2009) | 11 lines
Fix handling of DAHDI_EVENT_REMOVED event to prevent crash in do_monitor.
After talking to rmudgett about some of his recent iflist locking changes, it
was determined that the only place that would destroy a channel without being
explicitly to do so was in handle_init_event. The loop to walk the interface
list has been modified to wait to destroy the channel until the dahdi_pvt of
the channel to be destroyed is no longer needed.
(closes issue #15378)
Reported by: samy
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@218430 65c4cc65-6c06-0410-ace0-fbb531ad65f3
In the course of this, I also found that the results of ast_gethostbyname
were being used incorrectly in both chan_iax2 and chan_sip, so both have
been fixed.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@217916 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* Fixed walking the iflist so it is always done with the iflock locked.
* Simplified iflist walking routines.
* Created chan_dahdi iflist insertion and extraction routines.
* Fixed duplicate_pseudo() malloc fail handling.
* Fixed infinite loop in action_dahdishowchannels() when showing a single channel.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@217912 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r217806 | dvossel | 2009-09-10 16:06:07 -0500 (Thu, 10 Sep 2009) | 22 lines
IAX2 encryption regression
The IAX2 Call Token security patch inadvertently broke the use of
encryption due to the reorganization of code in the socket_process()
function. When encryption is used, an incoming full frame must first
be decrypted before the information elements can be parsed. The
security release mistakenly moved IE parsing before decryption in
order to process the new Call Token IE. To resolve this, decryption
of full frames is once again done before looking into the frame. This
involves searching for an existing callno, checking the pvt to see if
encryption is turned on, and decrypting the packet before the internal
fields of the full frame are accessed.
(closes issue #15834)
Reported by: karesmakro
Patches:
iax2_encryption_fix_1.4.diff uploaded by dvossel (license 671)
Tested by: dvossel, karesmakro
Review: https://reviewboard.asterisk.org/r/355/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@217807 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This fixes the problem that would occur if an analog phone was picked up while
the caller id was being sent. The caller id before sent the whole spill even
after pickup and is now corrected.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@217744 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Related to #12713
Patch by oej
A big thank you to file for finally fixing the transfer() dialplan application.
I've been waiting for years for this. Great work!
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@217482 65c4cc65-6c06-0410-ace0-fbb531ad65f3
parse_uri was not being given the correct scheme's, as
a result, uri parsing did not parse the username correctly.
One of the side effects of this is an empty caller id.
(closes issue #15839)
Reported by: ebroad
Patches:
blank_cidv2.patch uploaded by ebroad (license 878)
parse_uri_fix.diff uploaded by dvossel (license 671)
Tested by: ebroad, dvossel
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@216993 65c4cc65-6c06-0410-ace0-fbb531ad65f3
- Remove unused string in sip_registry -- "random"
- Someone added a function in the middle of all forward declarations... Weird. Moved it out of that
section.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@216905 65c4cc65-6c06-0410-ace0-fbb531ad65f3
- Add variable for number of known media streams instead of hardcoding in definition of sip_pvt
- Rename "text" to "codecs" - beacuse it's what it is
- Add documentation for future developers so that we make sure that we define new sdp media types
for SRTP-variants
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@216883 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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/trunk@216438 65c4cc65-6c06-0410-ace0-fbb531ad65f3
There was a problem in the function responsible for doing peer matching by
IP address and port number such that during the second pass for checking for
a peer configured with insecure=port, it would end up treating every peer as
if it had been configured that way. These changes fix the logic in the peer
IP and port comparison callback to handle insecure=port checking properly.
This problem was introduced when SIP peers were converted to astobj2. Many
thanks to dvossel for noticing this while working on another peer matching
issue.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@216368 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Added detection of DTMF tone energy levels on FXO channels in chan_dahdi
monitoring loop so DTMF CID can be detected without the need of a polarity
change precursor.
(closes issue #9096)
Reported by: fleed
Patches:
9096-chan_dahdi-trunk.diff uploaded by dbailey (license 819)
Tested by: cyberplant, sum, maturs
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@216094 65c4cc65-6c06-0410-ace0-fbb531ad65f3
