Fri, 12 Apr 2013 00:58:21 +1200 Author: Matt Riddell
Mark Michelson is looking for feedback on MWI while he works on SIP subscribe and notify events:
Hi devs,
I'm in the process of defining an API in the new SIP work for SIP SUBSCRIBE/NOTIFY events. As a proof of concept, I'm implementing MWI support. I'm writing to the list right now because I'm interested in what expectations are with regards to MWI.
I'll begin by describing the behavior in chan_sip.
In chan_sip, a peer configures mailboxes using the "mailbox" option in configuration. The option is a comma-separated list of mailboxes defined in voicemail.conf. In addition, there is an option called "subscribemwi" that determines whether we send MWI unsolicited or whether we require a SUBSCRIBE to be sent from the peer before we start sending MWI NOTIFYs.
For unsolicited MWI, any time one of the configured mailboxes changes state, we create an MWI NOTIFY to send out. This MWI NOTIFY contains the combined number of new and old messages for all of the configured mailboxes for the SIP peer. What this means is that there is a many-to-one relationship between configured mailboxes and SIP MWI subscriptions.
If using solicited MWI, then we first require a SUBSCRIBE for the "message-summary" event to arrive from the peer. When such a SUBSCRIBE arrives, we then exhibit the same behavior as for unsolicited MWI. That is, we send a NOTIFY with combined mailbox state of all configured mailboxes when any of the configured mailboxes changes state. If we receive a subsequent SUBSCRIBE from the same peer intending to start a new dialog, then we end the old dialog and use the new SUBSCRIBE as the basis for sending MWI NOTIFYs to the peer.
This process works for many scenarios, but there are some limitations:
* It assumes that the peer in question is a phone with a single MWI indicator. Combining all mailboxes' states into a single MWI NOTIFY makes sense when communicating with such a device, but it may not make as much sense for other types of endpoints.
* If a SUBSCRIBE request arrives, there is no attempt to look at the request URI in order to try to determine if there is a specific resource that is desired. It is just assumed that configured mailboxes for the peer are what is wanted.
* If multiple SUBSCRIBEs arrive, then the subsequent ones replace the previous ones as opposed to allowing multiple subscriptions to be active.
For MWI in the new SIP work, I'd like to know what expectations are for its behavior. If the current chan_sip behavior is fine, then I can mirror its behavior. I suspect, though, that this is not what is desired, so I have a tentative idea for how MWI will function:
Like with peers in chan_sip, we will allow for endpoints to configure mailboxes. Any mailboxes listed on an endpoint will be assumed to be unsolicited MWI. The directive on whether to combine the mailbox states into a single NOTIFY will be determined by a configuration option (e.g. "aggregate_mwi"). Thus if you had an endpoint configured like so:
Then alice will be sent a NOTIFY with the aggregated voicemail state of alice@vmcontext and tech-support@vmcontext any time that either of the mailboxes changes state. If the aggregate_mwi option had been set to "no" then alice would be sent individual NOTIFYs with each individual mailbox's state when the mailbox in question changes state.
For solicited MWI, the request-URI of the SUBSCRIBE will determine what mailbox(es) to subscribe to. The request-URI will map to a configured address of record in res_sip.conf. Mailbox options on that AOR will determine what mailboxes' states are reported. If you had an aor configured like so:
Then if a SUBSCRIBE arrives that wishes to subscribe to "sales" then the result would be a subscription that relays the combined state of the three configured mailboxes in the "sales" aor. Unlike with endpoints, there is no need for an aggregate_mwi option since the mailboxes have been explicitly grouped under the banner of a single aor. If non-aggregated state were desired, then the mailboxes can be placed into separate aors, and individual subscriptions can be made to each aor in order to subscribe to the individual state of each mailbox.
With this method in place, it allows for an endpoint to use a combination of solicited and unsolicited MWI if desired, and it allows for multiple MWI subscriptions, which is currently missing from chan_sip. It also allows for central definitions of arbitrary groups of related mailboxes.
Let me know what you think. Is the current scheme used by chan_sip exactly what should be done for the new SIP work? Are my ideas for configuration in the new SIP work great/okay/awful or in need of further explanation? Are there any shortcomings of MWI support in chan_sip that I have not touched upon that should be addressed in the new SIP work?
Thanks in advance for your feedback,
Mark Michelson
Wed, 10 Apr 2013 07:25:12 +1200 Author: Matt Riddell
Olle has been doing some work in the RTP channel on Packet Loss Concealment:
Hi!
We see a lot of issues in the RTP streams when bridging two sip calls in Asterisk. If there's packet loss coming in, it's the same going out - but in this case the sequence numbers doesn't indicate packet loss. This causes issues with recordings sounding bad and possibly other issues since we have quite long phone calls.
Investigating the PLC in Asterisk, according to Malcolm's wiki article there has to be a core bridge with transcoding and a jitter buffer. That won't work for us.
Looking into the RTP channel, where I've spent some time recently, I notice that we don't bother checking that packets are sequential, so the RTP channel doesn't bother with packet loss much. That needed to change.
I created a very simple PLC in the RTP channel for the incoming stream, following these principles:
- If there is packet loss, resend the previous packet. We discover this at the next packet, so we introduce two frames at once. In most cases with small packet loss, the receiving end will sort this out in the jitter buffer.
- If there is packet reordering, a jitter causing a packet to arrive too late, we ignore that packet since we've already replaced it
with another one.
Normally PLC would work hand-in-hand with a jitter buffer so we first reorder incoming RTP packets, then add the missing ones. In this case, I can't afford introducing extra delay caused by a jitter buffer, so I needed a poor man's implementation. It will add a bit of CPU, copying frames that wasn't done previously, but it is not a massive amount of operations - unless you have a really poor connection. In that case, audio will be lost anyway and there's nothing much we can do to save the situation.
How does it work?
================
- If we receive packets 2,3,5 - we will send 2,3,3,5 into the bridge, making sure that we get no skew.
- If we receive 2,3,5,4 we will send 2,3,3,5 and throw away #4.
In both cases, the extra "3" will be sent at the same time as the "5" into the bridge.
Looking at wireshark on the other side of the call, the outbound stream now looks better. Of course, there's jitter but no packet loss in the stream, we still have all expected frames - for Alaw 50 RTP frames per second. Without this PLC we could get 45 and the playback of a recording would sound "fast" - Donald Duckish... :-)
It is a small hack compared with other RTP hacks I've worked with recently- the DTMF length, Comfort Noise and others. But it does make the audio better in case of bad incoming streams.
Wed, 10 Apr 2013 04:35:42 +1200 Author: Matt Riddell
Asterisk Project Security Advisory - AST-2013-003
Product Asterisk
Summary Username disclosure in SIP
channel driver
Nature of Advisory Unauthorized data disclosure
Susceptibility Remote Unauthenticated Sessions
Severity Moderate
Exploits Known No
Reported On January 30, 2013
Reported By Walter Doekes, OSSO B.V.
Posted On February 21, 2013
Last Updated On March 27, 2013
Advisory Contact Kinsey Moore
CVE Name CVE-2013-2264
Description When authenticating via SIP with alwaysauthreject enabled,
allowguest disabled, and autocreatepeer disabled, Asterisk
discloses whether a user exists for INVITE, SUBSCRIBE, and
REGISTER transactions in multiple ways.
This information was disclosed:
* when a "407 Proxy Authentication Required" response was
sent instead of "401 Unauthorized" response.
* due to the presence or absence of additional tags at the
end of "403 Forbidden" such as "(Bad auth)".
* when a "401 Unauthorized" response was sent instead of
"403 Forbidden" response after a retransmission.
* when retransmissions were sent when a matching peer did
not exist, but were not when a matching peer did exist.
Resolution This issue can only be mitigated by upgrading to versions of
Asterisk that contain the patch or applying the patch.
Affected Versions
Product Release Series
Asterisk Open Source 1.8.x All Versions
Asterisk Open Source 10.x All Versions
Asterisk Open Source 11.x All Versions
Certified Asterisk 1.8.15 All Versions
Asterisk Business Edition C.3.x All Versions
Asterisk Digiumphones 10.x-digiumphones All Versions
Corrected In
Product Release
Asterisk Open Source 1.8.20.2, 10.12.2, 11.2.2
Asterisk Digiumphones 10.12.2-digiumphones
Certified Asterisk 1.8.15-cert2
Asterisk Business Edition C.3.8.1
Patches
SVN URL Revision
http://downloads.asterisk.org/pub/security/AST-2013-003-1.8.diff Asterisk
1.8
http://downloads.asterisk.org/pub/security/AST-2013-003-10.diff Asterisk
10
http://downloads.asterisk.org/pub/security/AST-2013-003-11.diff Asterisk
11
http://downloads.asterisk.org/pub/security/AST-2013-003-1.8.15-cert.diff Certified
Asterisk
1.8.15
http://downloads.asterisk.org/pub/security/AST-2013-003-C.3.diff Asterisk
BE C.3
Links ASTERISK-21013
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-2013-003.pdf and
http://downloads.digium.com/pub/security/AST-2013-003.html
Revision History
Date Editor Revisions Made
2013-02-20 Kinsey Moore Initial revision.
2013-02-27 Kinsey Moore Added Asterisk BE patch information.
2013-02-27 Kinsey Moore Corrected open source Asterisk versions.
Asterisk Project Security Advisory - AST-2013-003
Copyright (c) 2013 Digium, Inc. All Rights Reserved.
Permission is hereby granted to distribute and publish this advisory in its
original, unaltered form.
Wed, 10 Apr 2013 04:30:10 +1200 Author: Matt Riddell
Asterisk Project Security Advisory - AST-2013-002
Product Asterisk
Summary Denial of Service in HTTP server
Nature of Advisory Denial of Service
Susceptibility Remote Unauthenticated Sessions
Severity Major
Exploits Known None
Reported On January 21, 2013
Reported By Christoph Hebeisen, TELUS Security Labs
Posted On March 27, 2013
Last Updated On March 27, 2013
Advisory Contact Mark Michelson
CVE Name CVE-2013-2686
Description AST-2012-014, fixed in January of this year, contained a
fix for Asterisk's HTTP server since it was susceptible to a
remotely-triggered crash.
The fix put in place fixed the possibility for the crash to be
triggered, but a possible denial of service still exists if an
attacker sends one or more HTTP POST requests with very large
Content-Length values.
Resolution Content-Length is now capped at a maximum value of 1024
bytes. Any attempt to send an HTTP POST with content-length
greater than this cap will not result in any memory
allocated. The POST will be responded to with an HTTP 413
"Request Entity Too Large" response.
Affected Versions
Product Release Series
Asterisk Open Source 1.8.x 1.8.19.1, 1.8.20.0, 1.8.20.1
Asterisk Open Source 10.x 10.11.1, 10.12.0, 10.12.1
Asterisk Open Source 11.x 11.1.2, 11.2.0, 11.2.1
Certified Asterisk 1.8.15 1.8.15-cert1
Asterisk Digiumphones 10.x-digiumphones 10.11.1-digiumphones,
10.12.0-digiumphones,
10.12.1-digiumphones
Corrected In
Product Release
Asterisk Open Source 1.8.20.2, 10.12.2, 11.2.2
Certified Asterisk 1.8.15-cert2
Asterisk Digiumphones 10.12.2-digiumphones
Patches
SVN URL Revision
http://downloads.asterisk.org/pub/security/AST-2012-014-1.8.diff Asterisk
1.8
http://downloads.asterisk.org/pub/security/AST-2012-014-10.diff Asterisk
10
http://downloads.asterisk.org/pub/security/AST-2012-014-11.diff Asterisk
11
http://downloads.asterisk.org/pub/security/AST-2012-014-1.8.15-cert.diff Certified
Asterisk
1.8.15
+------------------------------------------------------------------------+
| Links | ASTERISK-20967 |
| | http://telussecuritylabs.com/threats/show/TSL20130327-01 |
+------------------------------------------------------------------------+
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-2013-002.pdf and
http://downloads.digium.com/pub/security/AST-2013-002.html
Revision History
Date Editor Revisions Made
February 12, 2013 Mark Michelson Initial Draft
March 27, 2013 Matt Jordan Updated CVE
Asterisk Project Security Advisory - AST-2013-002
Copyright (c) 2013 Digium, Inc. All Rights Reserved.
Permission is hereby granted to distribute and publish this advisory in its
original, unaltered form.
Wed, 10 Apr 2013 04:04:40 +1200 Author: Matt Riddell
Asterisk Project Security Advisory - AST-2013-001
Product Asterisk
Summary Buffer Overflow Exploit Through
SIP SDP Header
Nature of Advisory Exploitable Stack Buffer
Overflow
Susceptibility Remote Unauthenticated Sessions
Severity Major
Exploits Known No
Reported On 6 January, 2013
Reported By Ulf Ha:rnhammar
Posted On 27 March, 2013
Last Updated On March 27, 2013
Advisory Contact Jonathan Rose
CVE Name CVE-2013-2685
Description The format attribute resource for h264 video performs an
unsafe read against a media attribute when parsing the SDP.
The vulnerable parameter can be received as strings of an
arbitrary length and Asterisk attempts to read them into
limited buffer spaces without applying a limit to the
number of characters read. If a message is formed
improperly, this could lead to an attacker being able to
execute arbitrary code remotely.
Resolution Attempts to read string data into the buffers noted are now
explicitly limited by the size of the buffers.
Affected Versions
Product Release Series
Asterisk Open Source 11.x All Versions
Corrected In
Product Release
Asterisk Open Source 11.2.2
Patches
SVN URL Revision
Http://downloads.asterisk.org/pub/security/AST-2013-001-11.diff Asterisk
11
Links ASTERISK-20901
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-2013-001.pdf and
http://downloads.digium.com/pub/security/AST-2013-001.html
Revision History
Date Editor Revisions Made
February 11, 2013 Jonathan Rose Initial Draft
March 27, 2013 Matt Jordan CVE Added
Asterisk Project Security Advisory - AST-2013-001
Copyright (c) 2013 Digium, Inc. All Rights Reserved.
Permission is hereby granted to distribute and publish this advisory in its
original, unaltered form.
Asterisk 11.0.0-beta1 Now Available August 11, 2012 Average Vote: 10
The Asterisk Development Team is pleased to announce the first beta release of Asterisk 11.0.0 (the first Long Term Support release since 1.8).
Hello World from the new guy June 21, 2012 Average Vote: 10
David Duffett has written his first post as Asterisk Community Director.
oFono 1.0 has been released November 10, 2011 Average Vote: 10
Steve Totaro has forwarded details of the latest release of a project called oFono.
Discount for Astricon 2012 August 31, 2012 Average Vote: 10
Astricon 2012 is rapidly approaching and will be held in Atlanta between October 23 and 25. The Daily Asterisk News has secured a 20% discount on all tickets if you use the discount code.
Asterisk 10.0.0-rc1 Now Available November 11, 2011 Average Vote: 10
The Asterisk Development Team is pleased to announce the first release candidate of Asterisk 10.0.0.
AstLinux Custom Build Engine Now Available March 13, 2012 Average Vote: 10
Kristian Kielhofner has posted details of some work that has been completed in the AstLinux project to provide a custom build engine.
Asterisk 1.10 branch created July 14, 2011 Average Vote: 10
At 8:34am New Zealand time this morning a branch named 1.10 was created.
Asterisk Trunk moves from Berkley DB to SQLite 3. July 7, 2011 Average Vote: 10
While reading through the commit logs this morning I noticed that the planned change to SQLite 3 as the backend database has taken place.
Chapter on Asterisk Architecture May 27, 2011 Average Vote: 10
Russell Bryant has posted a note about a chapter on Asterisk Architecture.
New SIP channel driver project page November 23, 2012 Average Vote: 10
Mark Michelson has posted details of a wiki page that has been created to guide the development of a new SIP channel driver for Asterisk.
Asterisk and Google August 26, 2011 Average Vote: 10
Malcolm Davenport has posted a request on behalf of Digium for someone to help maintain the Google channel driver when Google makes changes.
espeak module for Asterisk August 22, 2011 Average Vote: 10
Lefteris Zafiris has posted details of a new version of the app_espeak application for Asterisk - another speech synthesizer.
CEL Logging to MySQL - Please Test April 12, 2011 Average Vote: 10
Jonathan Penny has been working on a MySQL module for the new Call Event Logging system in Asterisk and now needs it to be tested.
