* You are viewing Posts Tagged ‘steve davies’

Asterisk 10.6.0 Now Available

The Asterisk Development Team has announced the release of Asterisk 10.6.0. This release is available for immediate download at http://downloads.asterisk.org/pub/telephony/asterisk

The release of Asterisk 10.6.0 resolves several issues reported by the community like:

  • format_mp3: Fix a possible crash in mp3_read(). (Closes issue ASTERISK-19761. Reported by Chris Maciejewsk)
  • Fix local channel chains optimizing themselves out of a call. (Closes issue ASTERISK-16711. Reported by Alec Davis)
  • Re-add LastMsgsSent value for SIP peers (Closes issue ASTERISK-17866. Reported by Steve Davies)
  • Prevent sip_pvt refleak when an ast_channel outlasts its corresponding sip_pvt. (Closes issue ASTERISK-19425. Reported by David Cunningham)
  • Send more accurate identification information in dialog-info SIP NOTIFYs. (Closes issue ASTERISK-16735. Reported by Maciej Krajewski)

For a full list of changes in this release, please see the ChangeLog:

http://downloads.asterisk.org/pub/telephony/asterisk/ChangeLog-10.6.0

Thank you for your continued support of Asterisk!

Asterisk 1.8.14.0 Now Available

The Asterisk Development Team has announced the release of Asterisk 1.8.14.0. This release is available for immediate download at  ttp://downloads.asterisk.org/pub/telephony/asterisk

The release of Asterisk 1.8.14.0 resolves several issues reported by the community and would have not been possible without your participation. Thank you!

The following is a sample of the issues resolved in this release:

* — format_mp3: Fix a possible crash in mp3_read(). (Closes issue ASTERISK-19761. Reported by Chris Maciejewsk)
* — Fix local channel chains optimizing themselves out of a call. (Closes issue ASTERISK-16711. Reported by Alec Davis)
* — Update a peer’s LastMsgsSent when the peer is notified of waiting messages (Closes issue ASTERISK-17866. Reported by Steve Davies)
* — Prevent sip_pvt refleak when an ast_channel outlasts its corresponding sip_pvt. (Closes issue ASTERISK-19425. Reported by David Cunningham)
* — Send more accurate identification information in dialog-info SIP NOTIFYs. (Closes issue ASTERISK-16735. Reported by Maciej Krajewski)

AST-2012-010: Possible Resource Leak On Uncompleted Re-invite Transactions

Asterisk Project Security Advisory – AST-2012-010

Product Asterisk
Summary Possible resource leak on uncompleted re-invite
transactions
Nature of Advisory Denial of Service
Susceptibility Remote authenticated sessions
Severity Minor
Exploits Known No
Reported On June 13, 2012
Reported By Steve Davies
Posted On July 5, 2012
Last Updated On July 5, 2012
Advisory Contact Terry Wilson
CVE Name TBD

Description If Asterisk sends a re-invite and an endpoint responds to
the re-invite with a provisional response but never sends a
final response, then the SIP dialog structure is never
freed and the RTP ports for the call are never released. If
an attacker has the ability to place a call, they could
create a denial of service by using all available RTP
ports.

Resolution A re-invite that receives a provisional response without a
final response is detected and properly cleaned up at
hangup.

Affected Versions
Product Release Series
Asterisk Open Source 1.8.x All versions
Asterisk Open Source 10.x All versions
Asterisk Business Edition C.3.x All versions
Certified Asterisk 1.8.11-certx All versions
Asterisk Digiumphones 10.x.x-digiumphones All versions

Corrected In
Product Release
Asterisk Open Source 1.8.13.1, 10.5.2
Asterisk Business Edition C.3.7.5
Certified Asterisk 1.8.11-cert4
Asterisk Digiumphones 10.5.2-digiumphones

Patches
URL Revision
http://downloads.asterisk.org/pub/security/AST-2012-010-1.8.diff Asterisk
1.8
http://downloads.asterisk.org/pub/security/AST-2012-010-10.diff Asterisk
10

Links https://issues.asterisk.org/jira/browse/ASTERISK-19992

Asterisk Project Security Advisories are posted at
http://www.asterisk.org/security

This document may be superseded by later versions; if so, the latest
version will be posted at
http://downloads.digium.com/pub/security/AST-2012-010.pdf and
http://downloads.digium.com/pub/security/AST-2012-010.html

Revision History
Date Editor Revisions Made
06/27/2012 Terry Wilson Initial Release

Asterisk Project Security Advisory – AST-2012-010
Copyright (c) 2012 Digium, Inc. All Rights Reserved.
Permission is hereby granted to distribute and publish this advisory in its
original, unaltered form.

IAX channel name incorrect – Found in 1.2 still happens in 1.6

*Bump* No takers? Perhaps no-one else thinks this is a bug?

Regards,
Steve

On 7 February 2011 16:45, Steve Davies wrote:
> Hi,
>
> The following IAX config (slightly edited) causes an issue for me in
> version 1.6.2.16.1, where my CDR data is unreliable.
>
> [user1]
> type=friend
> auth=md5
> accountcode=user1
> notransfer=yes
> context=context1
> host=10.0.0.250
> username=user1
> secret=secret1
> disallow=all
> allow=alaw
>
> [user2]
> type=friend
> auth=md5
> accountcode=user2
> notransfer=yes
> context=context2
> host=dynamic
> deny=0.0.0.0/0.0.0.0
> permit=10.0.0.0/24
> username=user2
> secret=
> disallow=all
> allow=alaw
>
> If a call comes in from 10.0.0.250, using username “user2″ and with no
> password, then it is correctly authenticated against the [user2]
> section.
>    Accountcode is set to user2
>    Context is set to context2
> and the call mostly proceeds correctly, BUT the source channel name is
> set to IAX2/user1-nnnn, which is then seen both in the dialplan debug
> output, and in the CDR. I would expect the channel name to reflect the
> section name that was used to authenticate the call ie.
> IAX2/user2-nnnn; I specifically put a password onto [user1] so there
> is no possibility that the call is authenticating there.
>
> Am I missing something? Or is this a bug?
>
> Thanks,
> Steve
>

Queue/Dial Recording – Capture answering channel name.

On 09/09/10 17:59, Steve Davies wrote:
> On 9 September 2010 17:52, Antonio Berrios
> wrote:
>
>> Steve Davies wrote:
>>
>>> Hi,
>>>
>>> I am using 1.6.2.11, and I need to be able to include the name of the
>>> channel that answered a call in the call-recording filename.
>>>
>>> At a guess we need to use the Queue(name,,,,,,macro) or
>>> Dial(chan1&chan2,,M(macro)) and use the macro to update the call
>>> recording filename. But, the macro runs on the calling channel, and I
>>> need the called channel – Is this accessible?
>>>
>>> Thanks,
>>> Steve
>>>
>> Where ever the MixMonitor recording is done add in the ${CHANNEL}
>> variable to the filename parameter. Or even add in the line below to the
>> context that contains Dial(QueueName).
>>
>> For example:
>>
>> exten =>
>> s,n,MixMonitor(*${CHANNEL}-${TIMESTAMP}-${UNIQUEID}-${CALLERID(num)}.wav49)
>>
>>
> I was under the impression from the documentation that the ${CHANNEL}
> variable held the _Calling_ channel, I need the _Called_ channel (the
> channel that eventually picks up the call)
>
> Am I mistaken? Perhaps I should give it a try :)
>
> Thanks,
> Steve
>
>
Why is it you require the answering channel in the recording filename?
There may be an easier way to get you what you need. And a quick copy
pasta of the dial plan you’re using could be handy.