<html>
<head>
<base href="https://wiki.asterisk.org/wiki">
<link rel="stylesheet" href="/wiki/s/en/2171/18/9/_/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/AstriDevCon+-+October+28%2C+2011">AstriDevCon - October 28, 2011</a></h2>
<h4>Page <b>edited</b> by <a href="https://wiki.asterisk.org/wiki/display/~mdavenport">Malcolm Davenport</a>
</h4>
<br/>
<h4>Changes (2)</h4>
<div id="page-diffs">
<table class="diff" cellpadding="0" cellspacing="0">
<tr><td class="diff-unchanged" >h3. Overview <br></td></tr>
<tr><td class="diff-changed-lines" >A group of around <span class="diff-deleted-words"style="color:#999;background-color:#fdd;text-decoration:line-through;">??</span> <span class="diff-added-words"style="background-color: #dfd;">20</span> Asterisk SCF developers met after AstriCon 2011 for AstriDevCon at Denver, Colorado. Here is an overview of the topics discussed specific to Asterisk SCF. <br></td></tr>
<tr><td class="diff-unchanged" > <br>h3. Discussion Topics <br></td></tr>
<tr><td class="diff-added-lines" style="background-color: #dfd;"> <br> <br>h3. What are we doing to improve the user experience of getting, building, and installing Asterisk SCF? <br>* It's easier than it was, but still needs improvement <br>** Basic configuration files/scripts and startup scripts are now available <br>** Plans are to have binary packages for RPM and DEB distributions <br>** We're still limited by having to use a custom version of Ice; custom changes are nearly in shape to be submitted to ZeroC for integration, so that should solve this barrier. ZeroC hopes to have a release early next year. <br>*** This *may* be a gating factor to the 1.0 release, as it's an inhibitor to others simple installations <br> <br> <br>* Will Digium get recognition for the Ice contributions? <br>** Trying to make some amount of hay / publicity around the improvements to the Ice platform as a means for improving realtime communications (yay open source). <br> <br>* We've dropped installation support / instructions for CentOS 5.X, in favor of CentOS 6, as 5.X required external package repositories that have since disappeared. <br> <br>* Building the Java bindings is still complicated. <br>** Work will be done in order to simplify this, e.g. simple commands to install into a Maven repository. <br> <br>h3. What modules are in 1.0? <br> <br>* SIP for INVITE sessions <br>* SIP registrar <br>* RTP Endpoint <br>* UDPTL Endpoint <br>* Basic Routing Engine <br>* Two and Two+More Channel Bridging <br>* Transcoding for G.711 ulaw/alaw and G.722 to/from SLIN <br>* Transrating module for slin for 8/16kHz <br>* Jitterbuffer <br>* Energy-level measurement <br>* File-backed session gateway (record/playback of files) using Matroska containers <br>* Inband telephony event (DTMF, CNG) detector, generator is in progress <br>** Not currently focused on arbitrary tones, it *would be nice* to allow/expose this. <br> <br>h3. How basic is routing? <br> <br>It uses an endpoint lookup facility provided by the registrar. <br>If you've defined one in the registrar and we receive a contact URI that matches, we proceed. <br> <br>h3. How do components find the Service Locator? <br> <br>The sample config files demonstrate this. <br> <br>There are two levels of configuration: the bits necessary to start components and to find things like the Service Locator and its interfaces, and what gets pushed after the component is started. <br> <br>Nothing is compiled in. <br> <br>Multicast DNS support to find the Service Locator is still in progress. <br> <br>h3. Is there a best practices document for where to put a Service Locator? <br> <br>Not yet. <br> <br>h3. How do you avoid the double-fail, e.g. one component trips a core fault that flips to a second component where a request is already in progress that itself then suffers the same fault? <br> <br>...you don't want to tickle the same code the same way. Instead, large switches send back deny in order to not suffer the same fault twice. <br> <br>One way to address this is with differently written components, using the same replicator, that serve the same function, e.g. mainline SIP is PJSIP, one could also create a Java-based SIP component as the failed-to component. <br> <br>We believe this problem needs more research in order to solve. If we're secondary, how do we know that a bad call caused a fault on the primary, which is no longer up. <br> <br>It may be that the best solution is to put a component in front that sends the call along, and if what it sends it to dies, the component doesn't pass along subsequent calls like the one that caused the failure. <br> <br>h3. Is there a rational concern that because of the replicators that QA will face a much larger challenge? <br> <br>Yes. One needs to think of things affecting the primary and how they're going to traverse themselves into standby components. <br> <br>h3. What happens if someone tries to exploit the replicator itself? <br> <br>It's not the replicator that's the worry, but the standby machines you'd worry about. <br> <br>h3. Is the replicator diff based? <br> <br>No. It's state change-based, and the state is forwarded. <br> <br>h3. Is load-sharing possible with the current components and replicators? <br> <br>No. With today's components, you'd need to build a load-balancer in front of them, but the replicator is still one-way. <br> <br>h3. Most customers who think they need active-active decide they don't need it when the costs are explained. <br> <br>Much conversation is given to this topic but isn't rewarded by the underlying economics. <br> <br>h3. We should be able to recover a failure faster than the network can keep up (changing ARP tables, etc). <br> <br>500ms is our goal. What is 0ms worth (maybe not that much)? <br> <br>It's the media failover that is everyone's holy grail, but we can do that now, faster than the network can keep up. There *is* an unavoidable audio disturbance. <br> <br>h3. If I want one dialog server and 50 media gateways, what is needed? <br> <br>Right now, you'd have to write another component to do the partitioning. In the future (not 1.0), some basic level of that should be achievable automatically. <br>This isn't as scary as it sounds, because it could be something written simply out of javascript or ruby. <br> <br>h3. Is Digium intending to have a DAHDI hardware component? <br> <br>It's been on Digium's list, but it didn't make it in this release. <br> <br>h3. There's a fine line to walk in producing "canonical" components where if they're not the greatest, most feature-rich thing every conceived, then users of the platform will consider things the canonical version doesn't do as platform limitations, instead of limitations merely of the component. <br> <br>It's also dangerous in that if the canonical implementation is written in one language, e.g. Python, developers who write in other languages, e.g. Java, might feel locked out. <br> <br>h3. What happened to the OSX Build instructions? <br> <br>The current XCode can't build it. CLANG can't build Ice. If that changes, they'll come back. ZeroC's answer is that they're waiting on a commercial customer that justifies the investment. <br> <br>h3. Will Solaris be supported? <br> <br>Yes. <br> <br>h3. What about openindiana? <br> <br>Nothing to prevent it, but it's not on Digium's list of platforms. <br> <br>h3. The Wiki is not particularly clear about cloning git-all. Do I have to still go get each of the components? <br> <br>No. Cloning git-all gets a script that when run, goes and gets everything else. <br> <br>h3. Is it reasonable right now to use the Ice bindings for Android? <br> <br>Currently, it's such a large package that it's not practical for running on today's mobile handsets. As Tim said, it's "stupidly big." <br> <br>h3. Will it be security safe to run Ice on a client and trust it not to do something bad, back into the cluster? <br> <br>As far as the transport goes, it uses Glacier, which creates an SSL connection between the client and the cluster, add your own certificates. As far as what they're allowed to do, that's entirely different. Glacier has facilities for limiting this. At the moment, none of what's been built has authentication or authentication mechanisms; it's not the job of the SIP Session Gateway to determine who can talk to it, it's the job of something else to make those decisions. <br> <br>h3. All Ice related traffic will be over a single TCP connection. <br> <br>Glacier serves as the ALG, it's a stateful proxy, that supports replication. Ice isn't to be run bare across a NAT. <br> <br>h2. Items not discussed during the Tuesday "Intro to Asterisk SCF Development" session: <br> <br>Cookies <br>Un-slicable classes <br></td></tr>
</table>
</div> <h4>Full Content</h4>
<div class="notificationGreySide">
<h3><a name="AstriDevCon-October28%2C2011-Overview"></a>Overview </h3>
<p>A group of around 20 Asterisk SCF developers met after AstriCon 2011 for AstriDevCon at Denver, Colorado. Here is an overview of the topics discussed specific to Asterisk SCF. </p>
<h3><a name="AstriDevCon-October28%2C2011-DiscussionTopics"></a>Discussion Topics</h3>
<h3><a name="AstriDevCon-October28%2C2011-Whatarewedoingtoimprovetheuserexperienceofgetting%2Cbuilding%2CandinstallingAsteriskSCF%3F"></a>What are we doing to improve the user experience of getting, building, and installing Asterisk SCF?</h3>
<ul>
<li>It's easier than it was, but still needs improvement
<ul>
<li>Basic configuration files/scripts and startup scripts are now available</li>
<li>Plans are to have binary packages for RPM and DEB distributions</li>
<li>We're still limited by having to use a custom version of Ice; custom changes are nearly in shape to be submitted to ZeroC for integration, so that should solve this barrier. ZeroC hopes to have a release early next year.
<ul>
<li>This <b>may</b> be a gating factor to the 1.0 release, as it's an inhibitor to others simple installations</li>
</ul>
</li>
</ul>
</li>
</ul>
<ul>
<li>Will Digium get recognition for the Ice contributions?
<ul>
<li>Trying to make some amount of hay / publicity around the improvements to the Ice platform as a means for improving realtime communications (yay open source).</li>
</ul>
</li>
</ul>
<ul>
<li>We've dropped installation support / instructions for CentOS 5.X, in favor of CentOS 6, as 5.X required external package repositories that have since disappeared.</li>
</ul>
<ul>
<li>Building the Java bindings is still complicated.
<ul>
<li>Work will be done in order to simplify this, e.g. simple commands to install into a Maven repository.</li>
</ul>
</li>
</ul>
<h3><a name="AstriDevCon-October28%2C2011-Whatmodulesarein1.0%3F"></a>What modules are in 1.0?</h3>
<ul>
<li>SIP for INVITE sessions</li>
<li>SIP registrar</li>
<li>RTP Endpoint</li>
<li>UDPTL Endpoint</li>
<li>Basic Routing Engine</li>
<li>Two and Two+More Channel Bridging</li>
<li>Transcoding for G.711 ulaw/alaw and G.722 to/from SLIN</li>
<li>Transrating module for slin for 8/16kHz</li>
<li>Jitterbuffer</li>
<li>Energy-level measurement</li>
<li>File-backed session gateway (record/playback of files) using Matroska containers</li>
<li>Inband telephony event (DTMF, CNG) detector, generator is in progress
<ul>
<li>Not currently focused on arbitrary tones, it <b>would be nice</b> to allow/expose this.</li>
</ul>
</li>
</ul>
<h3><a name="AstriDevCon-October28%2C2011-Howbasicisrouting%3F"></a>How basic is routing?</h3>
<p>It uses an endpoint lookup facility provided by the registrar.<br/>
If you've defined one in the registrar and we receive a contact URI that matches, we proceed.</p>
<h3><a name="AstriDevCon-October28%2C2011-HowdocomponentsfindtheServiceLocator%3F"></a>How do components find the Service Locator?</h3>
<p>The sample config files demonstrate this.</p>
<p>There are two levels of configuration: the bits necessary to start components and to find things like the Service Locator and its interfaces, and what gets pushed after the component is started.</p>
<p>Nothing is compiled in.</p>
<p>Multicast DNS support to find the Service Locator is still in progress.</p>
<h3><a name="AstriDevCon-October28%2C2011-IsthereabestpracticesdocumentforwheretoputaServiceLocator%3F"></a>Is there a best practices document for where to put a Service Locator?</h3>
<p>Not yet.</p>
<h3><a name="AstriDevCon-October28%2C2011-Howdoyouavoidthedoublefail%2Ce.g.onecomponenttripsacorefaultthatflipstoasecondcomponentwherearequestisalreadyinprogressthatitselfthensuffersthesamefault%3F"></a>How do you avoid the double-fail, e.g. one component trips a core fault that flips to a second component where a request is already in progress that itself then suffers the same fault?</h3>
<p>...you don't want to tickle the same code the same way. Instead, large switches send back deny in order to not suffer the same fault twice.</p>
<p>One way to address this is with differently written components, using the same replicator, that serve the same function, e.g. mainline SIP is PJSIP, one could also create a Java-based SIP component as the failed-to component.</p>
<p>We believe this problem needs more research in order to solve. If we're secondary, how do we know that a bad call caused a fault on the primary, which is no longer up.</p>
<p>It may be that the best solution is to put a component in front that sends the call along, and if what it sends it to dies, the component doesn't pass along subsequent calls like the one that caused the failure.</p>
<h3><a name="AstriDevCon-October28%2C2011-IstherearationalconcernthatbecauseofthereplicatorsthatQAwillfaceamuchlargerchallenge%3F"></a>Is there a rational concern that because of the replicators that QA will face a much larger challenge?</h3>
<p>Yes. One needs to think of things affecting the primary and how they're going to traverse themselves into standby components.</p>
<h3><a name="AstriDevCon-October28%2C2011-Whathappensifsomeonetriestoexploitthereplicatoritself%3F"></a>What happens if someone tries to exploit the replicator itself?</h3>
<p>It's not the replicator that's the worry, but the standby machines you'd worry about.</p>
<h3><a name="AstriDevCon-October28%2C2011-Isthereplicatordiffbased%3F"></a>Is the replicator diff based?</h3>
<p>No. It's state change-based, and the state is forwarded.</p>
<h3><a name="AstriDevCon-October28%2C2011-Isloadsharingpossiblewiththecurrentcomponentsandreplicators%3F"></a>Is load-sharing possible with the current components and replicators?</h3>
<p>No. With today's components, you'd need to build a load-balancer in front of them, but the replicator is still one-way.</p>
<h3><a name="AstriDevCon-October28%2C2011-Mostcustomerswhothinktheyneedactiveactivedecidetheydon%27tneeditwhenthecostsareexplained."></a>Most customers who think they need active-active decide they don't need it when the costs are explained.</h3>
<p>Much conversation is given to this topic but isn't rewarded by the underlying economics.</p>
<h3><a name="AstriDevCon-October28%2C2011-Weshouldbeabletorecoverafailurefasterthanthenetworkcankeepup%28changingARPtables%2Cetc%29."></a>We should be able to recover a failure faster than the network can keep up (changing ARP tables, etc).</h3>
<p>500ms is our goal. What is 0ms worth (maybe not that much)?</p>
<p>It's the media failover that is everyone's holy grail, but we can do that now, faster than the network can keep up. There <b>is</b> an unavoidable audio disturbance.</p>
<h3><a name="AstriDevCon-October28%2C2011-IfIwantonedialogserverand50mediagateways%2Cwhatisneeded%3F"></a>If I want one dialog server and 50 media gateways, what is needed?</h3>
<p>Right now, you'd have to write another component to do the partitioning. In the future (not 1.0), some basic level of that should be achievable automatically.<br/>
This isn't as scary as it sounds, because it could be something written simply out of javascript or ruby.</p>
<h3><a name="AstriDevCon-October28%2C2011-IsDigiumintendingtohaveaDAHDIhardwarecomponent%3F"></a>Is Digium intending to have a DAHDI hardware component?</h3>
<p>It's been on Digium's list, but it didn't make it in this release.</p>
<h3><a name="AstriDevCon-October28%2C2011-There%27safinelinetowalkinproducing%22canonical%22componentswhereifthey%27renotthegreatest%2Cmostfeaturerichthingeveryconceived%2Cthenusersoftheplatformwillconsiderthingsthecanonicalversiondoesn%27tdoasplatformlimitations%2C..."></a>There's a fine line to walk in producing "canonical" components where if they're not the greatest, most feature-rich thing every conceived, then users of the platform will consider things the canonical version doesn't do as platform limitations, instead of limitations merely of the component.</h3>
<p>It's also dangerous in that if the canonical implementation is written in one language, e.g. Python, developers who write in other languages, e.g. Java, might feel locked out.</p>
<h3><a name="AstriDevCon-October28%2C2011-WhathappenedtotheOSXBuildinstructions%3F"></a>What happened to the OSX Build instructions?</h3>
<p>The current XCode can't build it. CLANG can't build Ice. If that changes, they'll come back. ZeroC's answer is that they're waiting on a commercial customer that justifies the investment.</p>
<h3><a name="AstriDevCon-October28%2C2011-WillSolarisbesupported%3F"></a>Will Solaris be supported?</h3>
<p>Yes.</p>
<h3><a name="AstriDevCon-October28%2C2011-Whataboutopenindiana%3F"></a>What about openindiana?</h3>
<p>Nothing to prevent it, but it's not on Digium's list of platforms.</p>
<h3><a name="AstriDevCon-October28%2C2011-TheWikiisnotparticularlyclearaboutcloninggitall.DoIhavetostillgogeteachofthecomponents%3F"></a>The Wiki is not particularly clear about cloning git-all. Do I have to still go get each of the components?</h3>
<p>No. Cloning git-all gets a script that when run, goes and gets everything else.</p>
<h3><a name="AstriDevCon-October28%2C2011-IsitreasonablerightnowtousetheIcebindingsforAndroid%3F"></a>Is it reasonable right now to use the Ice bindings for Android?</h3>
<p>Currently, it's such a large package that it's not practical for running on today's mobile handsets. As Tim said, it's "stupidly big."</p>
<h3><a name="AstriDevCon-October28%2C2011-WillitbesecuritysafetorunIceonaclientandtrustitnottodosomethingbad%2Cbackintothecluster%3F"></a>Will it be security safe to run Ice on a client and trust it not to do something bad, back into the cluster?</h3>
<p>As far as the transport goes, it uses Glacier, which creates an SSL connection between the client and the cluster, add your own certificates. As far as what they're allowed to do, that's entirely different. Glacier has facilities for limiting this. At the moment, none of what's been built has authentication or authentication mechanisms; it's not the job of the SIP Session Gateway to determine who can talk to it, it's the job of something else to make those decisions.</p>
<h3><a name="AstriDevCon-October28%2C2011-AllIcerelatedtrafficwillbeoverasingleTCPconnection."></a>All Ice related traffic will be over a single TCP connection.</h3>
<p>Glacier serves as the ALG, it's a stateful proxy, that supports replication. Ice isn't to be run bare across a NAT.</p>
<h2><a name="AstriDevCon-October28%2C2011-ItemsnotdiscussedduringtheTuesday%22IntrotoAsteriskSCFDevelopment%22session%3A"></a>Items not discussed during the Tuesday "Intro to Asterisk SCF Development" session:</h2>
<p>Cookies<br/>
Un-slicable classes</p>
</div>
<div id="commentsSection" class="wiki-content pageSection">
<div style="float: right;" class="grey">
<a href="https://wiki.asterisk.org/wiki/users/removespacenotification.action?spaceKey=TOP">Stop watching space</a>
<span style="padding: 0px 5px;">|</span>
<a href="https://wiki.asterisk.org/wiki/users/editmyemailsettings.action">Change email notification preferences</a>
</div>
<a href="https://wiki.asterisk.org/wiki/display/TOP/AstriDevCon+-+October+28%2C+2011">View Online</a>
|
<a href="https://wiki.asterisk.org/wiki/pages/diffpagesbyversion.action?pageId=19006649&revisedVersion=2&originalVersion=1">View Changes</a>
|
<a href="https://wiki.asterisk.org/wiki/display/TOP/AstriDevCon+-+October+28%2C+2011?showComments=true&showCommentArea=true#addcomment">Add Comment</a>
</div>
</div>
</div>
</div>
</div>
</body>
</html>