<html>
<head>
<meta name="viewport" content="width=device-width" />
<base href="https://wiki.asterisk.org/wiki" />
<style type="text/css">
body, #email-content, #email-content-inner { font-family: Arial,FreeSans,Helvetica,sans-serif; }
body, p, blockquote, pre, code, td, th, li, dt, dd { font-size: 13px; }
small { font-size: 11px; }
body { width:100% !important; -webkit-font-smoothing: antialiased; }
body,
#email-wrapper { background-color: #f0f0f0; }
#email-wrapper-inner { padding: 20px; text-align: center; }
#email-content-inner { background-color: #fff; border: 1px solid #bbb; color: $menuTxtColour; padding:20px; text-align:left; }
#email-wrapper-inner > table { width: 100%; }
#email-wrapper-inner.thin > table { margin: 0 auto; width: 50%; }
#email-footer { padding: 0 16px 32px 16px; margin: 0; }
.email-indent { margin: 8px 0 16px 0; }
.email-comment { margin: 0 0 0 56px; }
.email-comment.removed { background-color: #ffe7e7; border: 1px solid #df9898; padding: 0 8px;}
#email-title-avatar { text-align: left; vertical-align: top; width: 48px; padding-right: 8px; }
#email-title-flavor { margin: 0; padding: 0 0 4px 0; }
#email-title-heading { font-size: 16px; line-height: 20px; min-height: 20px; margin: 0; padding: 0; }
#email-title .icon { border: 0; padding: 0 5px 0 0; text-align: left; vertical-align: middle; }
#email-actions { border-top: 1px solid #bbb; color: #505050; margin: 8px 0 0 0; padding: 0; }
#email-actions td { padding-top: 8px; }
#email-actions .left { max-width: 45%; text-align: left; }
#email-actions .right { text-align: right; }
.email-reply-divider { border-top: 1px solid #bbb; color: #505050; margin: 32px 0 8px 0; padding: 8px 0; }
.email-section-title { border-bottom: 1px solid #bbb; margin: 8px 0; padding: 8px 0 0 0; }
.email-metadata { color: #505050; }
a { color: #326ca6; text-decoration: none; }
a:hover { color: #336ca6; text-decoration: underline; }
a:active {color: #326ca6; }
a.email-footer-link { color: #505050; font-size: 11px; }
.email-item-list { list-style: none; margin: 4px 0; padding-left: 0; }
.email-item-list li { list-style: none; margin: 0; padding: 4px 0; }
.email-list-divider { color: #505050; padding: 0 0.35em; }
.email-operation-icon { padding-right: 5px; }
.avatar { -ms-interpolation-mode: bicubic; border-radius: 3px;}
.avatar-link { margin: 2px; }
.tableview th { border-bottom: 1px solid #69C; font-weight: bold; text-align: left; }
.tableview td { border-bottom: 1px solid #bbbbbb; text-align: left; padding: 4px 16px 4px 0; }
.aui-message { margin: 1em 0; padding: 8px; }
.aui-message.info { background-color: #e0f0ff; border: 1px solid #9eb6d4; }
.aui-message.success { background-color: #ddfade; border: 1px solid #93c49f; }
.aui-message.error,
.aui-message.removed { background-color: #ffe7e7; border: 1px solid #df9898; color: #000; }
.call-to-action-table { margin: 10px 1px 1px 1px;}
.call-to-cancel-container, .call-to-action-container { padding: 5px 20px; }
.call-to-cancel-container { border: 1px solid #aaa; background-color: #eee; border-radius: 3px; }
.call-to-cancel-container a.call-to-cancel-button { background-color: #eee; font-size: 14px; line-height: 1; padding: 0; margin: 0; color: #666; font-family: sans-serif;}
.call-to-action-container { border: 1px solid #486582; background-color: #3068A2; border-radius: 3px; padding: 4px 10px; }
.call-to-action-container a.call-to-action-button { background-color: #3068A2; font-size: 14px; line-height: 1; padding: 0; margin: 0; color: #fff; font-weight: bold; font-family: sans-serif; }
/** The span around the inline task checkbox image */
.diff-inline-task-overlay {
display: inline-block;
text-align: center;
height: 1.5em;
padding: 5px 0px 1px 5px;
margin-right: 5px;
/** Unfortunately, the negative margin-left is stripped out in gmail */
margin-left: -5px;
}
@media handheld, only screen and (max-device-width: 480px) {
div, a, p, td, th, li, dt, dd { -webkit-text-size-adjust: auto; }
small, small a { -webkit-text-size-adjust: 90%; }
td[id=email-wrapper-inner] { padding: 2px !important; }
td[id=email-content-inner] { padding: 8px !important; }
td[id="email-wrapper-inner"][class="thin"] > table { text-align: left !important; width: 100% !important; }
td[id=email-footer] { padding: 8px 12px !important; }
div[class=email-indent] { margin: 8px 0px !important; }
div[class=email-comment] { margin: 0 !important; }
p[id=email-title-flavor] a { display: block; } /* puts the username and the action on separate lines */
p[id=email-permalink] { padding: 4px 0 0 0 !important; }
table[id=email-actions] td { padding-top: 0 !important; }
table[id=email-actions] td.right { text-align: right !important; }
table[id=email-actions] .email-list-item { display: block; margin: 1em 0 !important; word-wrap: normal !important; }
span[class=email-list-divider] { display: none; }
}
</style>
</head>
<body style="font-family: Arial, FreeSans, Helvetica, sans-serif; font-size: 13px; width: 100%; -webkit-font-smoothing: antialiased; background-color: #f0f0f0">
<table id="email-wrapper" width="100%" cellspacing="0" cellpadding="0" border="0" style="background-color: #f0f0f0">
<tbody>
<tr valign="middle">
<td id="email-wrapper-inner" style="font-size: 13px; padding: 20px; text-align: center">
<table id="email-content" cellspacing="0" cellpadding="0" border="0" style="font-family: Arial, FreeSans, Helvetica, sans-serif; width: 100%">
<tbody>
<tr valign="top">
<td id="email-content-inner" align="left" style="font-family: Arial, FreeSans, Helvetica, sans-serif; font-size: 13px; background-color: #fff; border: 1px solid #bbb; padding: 20px; text-align: left">
<table id="email-title" cellpadding="0" cellspacing="0" border="0" width="100%">
<tbody>
<tr>
<td id="email-title-avatar" rowspan="2" style="font-size: 13px; text-align: left; vertical-align: top; width: 48px; padding-right: 8px"> <img class="avatar" src="cid:avatar_16181e6326f183784f186951c83d98b8" border="0" height="48" width="48" style="-ms-interpolation-mode: bicubic; border-radius: 3px" /> </td>
<td valign="top" style="font-size: 13px">
<div id="email-title-flavor" class="email-metadata" style="margin: 0; padding: 0 0 4px 0; color: #505050">
<a href=" https://wiki.asterisk.org/wiki/display/~dlee " style="color:#326ca6;text-decoration:none;; color: #326ca6; text-decoration: none">David M. Lee</a> edited the page:
</div> </td>
</tr>
<tr>
<td valign="top" style="font-size: 13px"> <h2 id="email-title-heading" style="font-size: 16px; line-height: 20px; min-height: 20px; margin: 0; padding: 0"> <a href="https://wiki.asterisk.org/wiki/display/AST/Asterisk+12+API+Improvements" style="color: #326ca6; text-decoration: none"> <img class="icon" src="cid:page-icon" alt="" style="border: 0; padding: 0 5px 0 0; text-align: left; vertical-align: middle" /> <strong style="font-size:16px;line-height:20px;vertical-align:top;">Asterisk 12 API Improvements</strong> </a> </h2> </td>
</tr>
</tbody>
</table>
<div class="email-indent" style="margin: 8px 0 16px 0">
<p class="aui-message info" style="font-size: 13px; margin: 1em 0; padding: 8px; background-color: #e0f0ff; border: 1px solid #9eb6d4"> <b>Comment:</b> No longer using swagger-codegen </p>
<div class="email-diff">
<div id="page-diffs" class="wiki-content">
<table class="diff-macro diff-block-target" style="background-color: #f0f0f0;border: 1px solid #dddddd;margin: 10px 1px;padding: 0 2px 2px;width: 100%;">
<thead>
<tr>
<th class="diff-macro-title" style="background-color: transparent; text-align: left; font-weight: normal;padding: 5px;; font-size: 13px"><span class="icon macro-placeholder-icon" style="background-color: ;line-height: 20px;"><img src="https://wiki.asterisk.org/wiki/s/en_GB-1988229788/4109/76e0dbb30bc8580e459c201f3535d84f9283a9ac.25/_/images/icons/macrobrowser/macro-placeholder-default.png" style="padding-right: 5px; vertical-align: text-bottom;" /> </span>Wiki Markup</th>
</tr>
</thead>
<tbody>
<tr>
<td class="diff-macro-body" style="background-color: #fff;border: 1px solid #dddddd;padding: 10px;; font-size: 13px"> <pre style="font-size: 13px">{numberedheadings}
{note}
This page is under development; expect missing and incomplete information. Still, feel free to discuss on [asterisk-dev|http://lists.digium.com/mailman/listinfo/asterisk-dev].
{note}
{toc:style=none|maxlevel=3}
h1. Project Overview
While Asterisk has a number of interfaces one could use for building telephony applications, they suffer from several significant problems.
* Channels identifiers are not stable. Some operations (like [masquerades|AST:Asterisk 11 ManagerEvent_Masquerade]) will change the id out from under you.
* The protocols (AMI and AGI) are non-standard and poorly documented, making them difficult to work with.
* AMI's message format is restricted to simple name/value pairs. Commands that need to pass back lists or structured data are very hackish.
* AMI event filtering is very course grained, and established in configuration instead of at runtime. This has lead to some creative solutions to dealing with the flood of events (most of which are not of interest).
* AGI is a synchronous interface, which really hinders making truly interactive applications.
** While AsyncAGI attempts to address this issue, it is an asynchronous wrapper around a synchronous implementation. Commands queue up after one another, and are not interruptible, leading to many of the same problems with AGI or FastAGI.
* Internally, AMI events are formatted into strings at the time they are created. This makes it very difficult to do anything with the events, except send them out AMI connections. This also makes using different protocol formats difficult.
* Different interfaces tend to implement the same logical command in different ways.
We're going to start with fixing one of the most glaring problems with the current APIs: [add a stable identifier to channels|https://issues.asterisk.org/jira/browse/ASTERISK-20725], and use that identifier consistently throughout AMI. This solves a big problem for current AMI+AGI based applications.
Unfortunately, solving some of the larger problems would be very intrusive with the current API's, and introduce a host of breaking changes. Some are so fundamental, we would essentially be rewriting the interface. That's not acceptable; the current API's aren't going anywhere anytime soon.
This leads us down the path of adding a new interface to Asterisk. We've got some time to put some though into this, so let's do it right. Since things are easier to talk about when they have a name, the new API work has the working title [Stasis|#bad-name].
We want the API to be familiar and approachable to developers. We don't want to force them to use C. In fact, we don't want to force them to use any particular programming language; the API should be accessible from the language and platform of their choice.
The API should be relatively high level, and not get stuck down in the details of what's happening inside of Asterisk. Asterisk may go through all sorts of shenanigans to do what it needs to do, but the API should provide a nice, clean abstraction.
In building out the new API, we don't want to repeat past mistakes by re-implement the same functionality several times in slightly different ways. There should be a single core implementation, that all of the API's use. This would improve consistency between the API's and reduce code duplication.
To accomplish this, Stasis will be a set of new modules for providing control and management interfaces into Asterisk. While Stasis will initially be focused on third party call control and monitoring, it should be extensible enough to provide configuration and provisioning API's in the future.
Internally to Asterisk, {{stasis-core}} will provide a message bus for interfacing with Asterisk objects. The {{stasis-http}} component will be built upon this message bus to expose a RESTful API, also utilizing WebSockets for asynchronous communication to the external applications.
The split between {{stasis-core}} and {{stasis-http}} should allow for other protocol bindings to be added in the future. This could even go so far as replacing the existing API's with Stasis implementations.
The selection of HTTP as the first binding for Stasis allows for very broad appeal, ease of use, and simplicity for writing client libraries to make it easier to write applications to the API.
h1. Requirements and Specification
h2. Stasis Requirements
* *Asynchronous Everything* \- Most applications need to be able to interrupt activities, and receive events as they happen. Blocking operations are the devil.
* *Version Stability* \- This is important. Like, really important. The current mechanisms may change dramatically between releases, which causes developers/integrators/etc. to keep running on older versions of Asterisk than anyone would like.
* *Interoperability* \- Stasis must work in a variety of environments, detailed below.
** *Programming Language* \- Stasis applications should be able to be easily written in a variety of languages.
* *Security* \- Reasonable security measures should be taken.
** Encryption: Since the API should not be accessible on a public network, encryption is not high in the priority list.
*** Even if connections are plain text, reasonable precautions should be taken with sensitive information (e.g. use challenge handshakes for authentication instead of passing plaintext passwords over the wire).
*** If a binding protocol (say, HTTP) supports encryption (say, HTTPS), then it should be supported for Stasis as well.
Not needed immediately, and way down on the priority list.
** Authentication: Client only authentication is sufficient. Should not be any more complicated than passwords/pre-shared secrets.
** Authorization: See [below|#Stasis Authorization Requirements].
h3. Authorization Requirements
Unfortunately, authorization is a tricky subject.
There are many different schemes for implementing authorization, and we've learned that if you're not careful you can end up with a scheme that doesn't provide the value that you hoped for, and is more costly than you expected. And this cost shows up in the complexity of both the implementation and the API.
It's also important to understand who you are authorizing. In the case of the API, we are authorizing applications for API access; not (necessarily) the end users of the phone system. It's somewhat similar to the three tier client/application/database relationship. The database authenticates the application, and determines what data the application can access. The application authenticates the client, and determines what subset of that data it exposes to the client. It's not a perfect comparison, but you get the idea.
Possible use cases to consider:
* *Host multiple companies in one PBX* \- "which channels are one particular user (or group) allowed to follow, manipulate and originate".
* *Read only applications* \- A monitoring application should not be able to affect the state of the system.
h2. Internal Improvements
* *Stable channel identifier* \- this is necessary for a reasonable Stasis API. Since so much of the world still depends on AMI, it should be updated to allow the stable id to be used in place of the current channel id
* *AMI Event Structure* \- AMI events should be generated into a key/value object pair instead of the {{printf}}\-style string formatting currently used. This would allow Stasis to reuse the existing events.
* *Improved implementation consistency* \- While not something we would address in the initial Stasis work, existing disparate implementations could be reworked to use a single, consistent {{stasis-core}} implementation.
* *Fix AMI Bridge Events*
** Current event precludes multi-party bridges (Only has {{Channel1}} and {{Channel2}})
** Some events in the system result in spurious Bridge events (such as [DTMF|https://issues.asterisk.org/jira/browse/ASTERISK-18639])
h2. Use Cases
Note that at this point this it the list of _candidate_ use cases. Which ones we get to, and in what priority, have not been determined yet.
h3. Summary Level
Highest level use cases; more or less applications that could be build on top of Stasis.
* *Standard two party call* \- Very standard use case for Asterisk.
* *Conference* \- Multi-participant calls, in which media from one endpoint may be sent to two or more endpoints.
** Some participants may control the conference via DTMF key presses
** Some participants may be muted
** Indicate who is speaking
* *IVR* \- Interactive Voice Response.
** Plays media to caller
** Detects DTMF key presses from caller
** Record media from caller
* *Queue* \- Call dispatch queue.
** Get presence information from queue agents
** Originate calls to agents as needed
** When agent answers, bridge to most appropriate call from queue
** May add supervisor to agent/caller conversation
* *Voicemail*
** Record audio from caller
** Playback recorded audio
** Detect DTMF for media control (fast forward, skip, delete)
h3. User Level
* *Answer*&nbsp;\- An application may answer a ringing channel.
* *Hangup/Reject* \- An application may hangup an active channel, or reject a ringing channel.
* *Return to dialplan* \- An application may send a channel back to the dialplan to continue processing.
* *Originate* \- An application may originate a new channel.
* *DTMF Detection* \- DTMF, and other channel events.
* *Bridge* \- Two or more channels may be bridged together, so that media from any channel may be mixed and sent to the others
** *Speaker Events* \- Events indicating which channel(s) on the bridge are speaking.
* *Play* \- An application may specify media to be played on a channel.
* *Presence* \- An application may query the presence state of endpoints, and subscribe to presence updates.
* *Record* \- An application may record the media from a channel/bridge.
* *BLF* \- The application may light up the BLF on an endpoint.
h3. Sub-function Level
* *Media Control* \- During the playback of media, the application may issue fine-grained media control commands. (fast forward, pause, stop, etc.)
* *Mute participant* \- Within a bridge, an application may (un)mute individual channels, controlling which media streams are mixed and sent to other participants.
h2. Guidelines
h3. PBX vs. Toolkit