<html>
<head>
<base href="https://wiki.asterisk.org/wiki">
<link rel="stylesheet" href="/wiki/s/2030/1/7/_/styles/combined.css?spaceKey=TOP&forWysiwyg=true" type="text/css">
</head>
<body style="background: white;" bgcolor="white" class="email-body">
<div id="pageContent">
<div id="notificationFormat">
<div class="wiki-content">
<div class="email">
<h2><a href="https://wiki.asterisk.org/wiki/display/TOP/Asterisk+SCF+1.0+Use+Case+Discussion+-+Integrics">Asterisk SCF 1.0 Use Case Discussion - Integrics</a></h2>
<h4>Page <b>added</b> by <a href="https://wiki.asterisk.org/wiki/display/~bmj">Bryan M. Johns</a>
</h4>
<br/>
<div class="notificationGreySide">
<p><b>On November 16, 2010 Representatives from Digium held a requirements gathering discussion with Alistair Cunningham of Entegrics for the purpose of determining potential Asterisk SCF 1.0 features and functionality from the ITSP software / switching market. The information below is a summary of the attendees, their individual input / opinions and takeaway items from these discussions:</b></p>
<p>Attendees</p>
<p>Alistair Cunningham - Integrics<br/>
Ken Hunt - Digium<br/>
Brent Eagles - Digium (via phone)<br/>
Darren Sessions - Digium<br/>
David Lee - Digium<br/>
Joshua Colp - Digium (via phone)<br/>
Kevin P. Fleming - Digium<br/>
Mark Michelson - Digium<br/>
Bryan M. Johns - Digium</p>
<p>> Draft agenda: (as provided in advance of the meeting)<br/>
> - 09:00 Tour of Digium<br/>
> - 09:30 Introduce Alistair to Asterisk SCF eng team + Bryan, Malcolm<br/>
> - 09:40 Alistair: Enswitch overview <Asterisk SCF team dialed in><br/>
> - 10:00 Alistair: Asterisk SCF 1.0 needs <Asterisk SCF team dialed in><br/>
> - 11:30 <Lunch out> (Bryan, David Deaton, Kevin, Ken, Russell, others)<br/>
> - 13:00 Russell / Alistair discuss Asterisk 1.X<br/>
> - 13:30 Brainstorming on Enswitch / Asterisk SCF <Asterisk SCF team dialed in><br/>
> - 15:00 Alistair meet w/ Deaton? (or business dev / marketing???)</p>
<p><b>DISCUSSION OF INTEGRICS / ENSWITCH</b></p>
<p>Enswitch, value of SCF to it<br/>
Founder of Integrics, creators of Enswitch, soft switch.<br/>
Asterisk, OpenSIP, MySQL, Apache, cluster architecture</p>
<p>all config is in the MySQL database; not in Asterisk config files<br/>
web page updates config consistently across the cluster<br/>
scale up to 20k to 50k concurrent calls (arch. limit)<br/>
thousands of concurrent calls in production<br/>
doesn't use Asterisk for everything<br/>
queues (b/c it doesn't know about calls on other machines)<br/>
expectations for scf: take Asterisk features, make it fully cluster aware, distributed state, some form of failover (< important; they already do it), lower level access to things like SIP, codec negotiation</p>
<p><b>Failover that keeps calls up:</b> been asked by customers, has never been a deal breaker. ability would be competitive advantage, but not a huge one.</p>
<p><b>PRIMARY FEATURES DISCUSSION</b></p>
<p>May not actually improve availability, since most failures are admin error, database disk filling up, last mile DSL, etc.<br/>
competitors: Broadsoft, people rolling their own</p>
<p><b>kpfleming:</b> the world of reliability has changed. folks are using less reliable hardware (PC's instead of purpose built PBX) and less reliable networks (Internet instead of PSTN). This is lower cost, but increases risk. What can they do to mitigate that risk?</p>
<p><b>alistair:</b> offering live failover of calls may raise the bar. but b/c the vendor doesn't have control over all the links in the chain, it's mostly a marketing pitch.</p>
<p><b>call flow and logging should reflect billing realities</b></p>
<p>current ast call flow reflects human perception; fine for a pbx system. from a billing point of view, there's still a call in/out of a telephone that drops out of a conference/transfer. some way of building (synthetically?) a view that reflects the call flow from a billing point of view.</p>
<p><b>busy lamps need to work differently from billing</b></p>
<p>call flow for presence is different for call flow for billing. platform needs to support both flows simultaneously. three views of call flow: billing, person, phone. for two of those, that logically translates into logic that we don't want to dictate, but people want to take the underlying data to determine state by their own rules.</p>
<p><b>having detailed logging for individual call legs is valuable</b></p>
<p><b>kpfleming:</b> support gets call "I'm not getting voicemails", support can look at call logs for that leg to see someone dialing in, getting shifted to voice mail, then the playing of a blank unavailable greeting. without detailed call logs, you're just shooting in the dark</p>
<p><b>prefer facilities over policy</b></p>
<p>we want to allows users to specify their policy, rather than baking it in</p>
<p><b>digium provided replacement for extensions.conf</b></p>
<p>ast config file for call routing. provide simplified language for establishing call plans.</p>
<p><b>lightweight SIP proxy (OpenSIPS) distribute calls, registrations, subscribes</b></p>
<p>something in front of hundreds of ast boxes to distribute calls. the frontend has impact on NAT handling. RTP (media) bypasses the SIP proxy.</p>
<p>pjsip has some NAT handling built in (pjnath.h). we may need integrate it into our code<br/>
b/c we've decoupled the SipSessionManager from the rest of the system, so you can run that on an individual machine. so it's unlikely to hit the load where you hit the limits of the machine. but there are still situations where you want a SIP proxy in front of it.</p>
<p><b>ability to inject custom SIP packets to handsets</b></p>
<p>higher level code to send SIP notifies to handsets</p>
<p><b>kpfleming:</b> intricacies of protocol makes this difficult, and still be available/reliable (sequence numbers, retransmissions, etc.) should focus on what we're trying to do (problem domain) instead of how we're trying to do it (solution domain).</p>
<p><b>periodic callbacks during session</b></p>
<p>when a call comes in, ice component to say "while the call is running, invoke me every six seconds". then it can deduct from customer pre-paid balance. when balance reaches zero, hang up the call.</p>
<p><b>kpfleming:</b> should be able to extend system to have something listening to sessions, which tells session start and stop. won't have 6-second polls, but this could be internally to the listener.</p>
<p><b>enswitch 4 (next major rev) minimum feature list for scf</b></p>
<ul>
<li>really solid API for ICE level developers</li>
<li>some optional components on top of it</li>
<li>something like ast's extensions.conf</li>
<li>ability to put together a quick demo</li>
<li>routing engine eq. of app dial</li>
<li>comprehensive sip stack</li>
<li>current ast sip functionality</li>
<li>back to back user agent, nat, access to sip codec, notify for busy lamps, message waiting indicator, ...</li>
<li>basic ivr func. answer, stream file, collect dtmf, record audio until # is pressed</li>
<li>example api decorators</li>
</ul>
<p>once we have an api like the subscription thing, there are lots of cases where people want to wrap that (decorator pattern, i.e. sits in from on SipSessionManager). going off and building an example of how you would decorate an existing API.</p>
<p><b>fun idea:</b> AOP for ICE. makes building decorators really easy.</p>
<p><b>brainstorming</b></p>
<ul>
<li>skeleton app - shows you how to manipulate audio</li>
<li>presence stack - defining what presence concepts that can be communicated through the stack</li>
<li>building interfaces to whatever protocols we're going to support communicating presence</li>
<li>ICE level API for subscription request notifications</li>
<li>massive amount of media related work</li>
<li>replication of transaction state</li>
<li>how vital is that? great increase in traffic;</li>
<li>how would that affect failover?</li>
<li>we send message; we die; backup service receives response, but has no idea why</li>
<li>what other components need replication? all of them.</li>
<li>state replication to durable storage</li>
<li>configuration component instead of ice config file</li>
<li>basic configuration of the component (address, ports, ...) - may continue on in ice config files</li>
<li>system components (sip, logger, ...)</li>
<li>security of the Ice interfaces</li>
<li>gets into the area of the policy</li>
<li>IPv6</li>
<li>UTF-8</li>
<li>encrypted transport (SIP over TLS)</li>
<li>import pjproject into our repo</li>
<li>distributed queue</li>
<li>queue delivery policy engine so implementors can get access to which calls are in which queue, and which agents are available. available is defined by higher level developer in the presence engine.</li>
<li>maybe just an implementation of the routing engine</li>
<li>one very simple example of how to do it with scf</li>
<li>enhance session router ifc so we can hand off the session from one service to another</li>
<li>state replicator example in other languages</li>
<li>clear usage document; something that's easily digestible by someone of intermediate technical ability</li>
<li>conferencing - conferences across multiple machines; mixing RTP across multiple machines</li>
<li>would be nice if scf could do bridging of conferences across machines; would greatly increase scalability of a conference (1 or 2 talkers; 3k listeners)</li>
</ul>
<p><b>PRIMARY TAKEAWAYS</b></p>
<p><b>Must have:</b></p>
<ul>
<li>*Routing</li>
<li>*APP_DIAL replacement & opts</li>
<li>*Multiple dial</li>
<li>*create/hangup a call via ice</li>
<li>*send fax & receive fax (nice to have)</li>
<li>*SIP</li>
<li>*Basic Calls</li>
<li>*NAT</li>
<li>*Subscribe + Notify</li>
</ul>
<p>IVR Platform</p>
<ul>
<li>*play audio files (incl. music)</li>
<li>*record audio</li>
<li>*for call recording</li>
<li>*voice mail, ivr's</li>
<li>*collect DTMF (for ivr's)</li>
<li>answer and hangup</li>
<li>early media</li>
</ul>
<p>PBX features</p>
<ul>
<li>*xfer</li>
<li>*hold</li>
<li>*inject media into bridge (nice to have)</li>
</ul>
<p><b>Nice to have:</b></p>
<p>*Component management - this machine is running a sip listener; this machine is running a storage engine<br/>
conferencing between machines</p>
</div>
<div id="commentsSection" class="wiki-content pageSection">
<div style="float: right;">
<a href="https://wiki.asterisk.org/wiki/users/viewnotifications.action" class="grey">Change Notification Preferences</a>
</div>
<a href="https://wiki.asterisk.org/wiki/display/TOP/Asterisk+SCF+1.0+Use+Case+Discussion+-+Integrics">View Online</a>
|
<a href="https://wiki.asterisk.org/wiki/display/TOP/Asterisk+SCF+1.0+Use+Case+Discussion+-+Integrics?showComments=true&showCommentArea=true#addcomment">Add Comment</a>
</div>
</div>
</div>
</div>
</div>
</body>
</html>