<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><span style="font-family: arial, sans-serif; font-size: 13px; ">Matthew,</span><div style="font-family: arial, sans-serif; font-size: 13px; "> Thank you for reviewing and commenting, greatly appreciated. I'll take a look at each of your comments and respond in the issue comments.</div><div style="font-family: arial, sans-serif; font-size: 13px; "><br></div><div style="font-family: arial, sans-serif; font-size: 13px; ">On your question of SLATrunk() results codes that I added to both halves of the local channel the answer is yes I needed to do both. I don't remember the exact specifics (I'd have to put a bunch of debug statements back in). But the scenario is this.</div><div style="font-family: arial, sans-serif; font-size: 13px; "><br></div><div style="font-family: arial, sans-serif; font-size: 13px; ">[TestInbound]</div><div style="font-family: arial, sans-serif; font-size: 13px; ">exten => 105,1,Dial(local/s@InboundSLA,${RINGTIME},r(ring)tU(subroutine))</div><div style="font-family: arial, sans-serif; font-size: 13px; "><br></div><div style="font-family: arial, sans-serif; font-size: 13px; ">[InboundSLA]</div><div style="font-family: arial, sans-serif; font-size: 13px; ">exten => s,1,SLATrunk(SLAtrunk1)</div><div style="font-family: arial, sans-serif; font-size: 13px; "> same => n,Set(ANSWERED_EXTEN=${CUT(CUT(SLATRUNK_ANSWEREDCHANNEL,"-",1),"/",2)})<br></div><div style="font-family: arial, sans-serif; font-size: 13px; "><br></div><div style="font-family: arial, sans-serif; font-size: 13px; ">[subroutine]</div><div style="font-family: arial, sans-serif; font-size: 13px; ">exten => s,1,Set(ANSWERED_EXTEN=${CUT(CUT(SLATRUNK_ANSWEREDCHANNEL,"-",1),"/",2)})</div><div style="font-family: arial, sans-serif; font-size: 13px; "><br></div><div style="font-family: arial, sans-serif; font-size: 13px; ">I found that in [subroutine] I got one half of the local channel while in [InboundSLA] I got the other half. Therefore to have access to the variables in both places I needed them in both halves. In my specific scenario I need to make some settings based on exactly which extension picked up before the call is connected, hence why I have the U(subroutine).</div><div style="font-family: arial, sans-serif; font-size: 13px; "><br></div><div style="font-family: arial, sans-serif; font-size: 13px; ">David</div><div><br></div><div><div>On Nov 19, 2012, at 10:14 AM, Matthew Jordan <<a href="mailto:mjordan@digium.com">mjordan@digium.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">On 11/15/2012 09:42 PM, David Kerr wrote:<br><blockquote type="cite">A few months ago I tried to get Shared Line Appearance (SLA) features of<br>Asterisk to work for me in an entirely SIP environment. While I could<br>get incoming calls to work, I ran into a couple of pretty severe<br>problems with outbound calls. I opened bugs 20440 and 20462 to document<br>them.<br><br>As these received no attention from any developer after a couple of<br>months I took it upon myself to fix them. I have uploaded patches that<br>I would like the Asterisk dev community to review and consider<br>incorporating into the mainline code, asterisk 1.8 and up.<br></blockquote><br>So first of all, thanks a lot for writing these patches! Issues with<br>patches typically receive more attention and move through the process<br>faster than those without - so hopefully this will help get these issues<br>resolved.<br><br><blockquote type="cite">20440<br>No ringback towards SLA Station that originated an outbound call.<br>I traced the problem to be because the SLA code triggers ast_dial() as<br>an asynchronous request. Doing this prevents the normal indication of<br>ringing being passed back to the originating channel in the dial<br>functions in dial.c (an asynchronous request NULL's out the pointer to<br>originating channel in the dial structure).<br>The solution is to have the ringing indication sent back to originating<br>channel in the SLA trunk dial code in app_meetme.c.<br>After some testing I determined that it is necessary to send<br>progress/ringing signals back to more accurately reflect status of the<br>outbound trunk channel, else you get a dial tone when it is already<br>attempting to connect, or a ringing tone when it hasn't really started<br>to ring yet.<br></blockquote><br>Fairly straight forward, and while I'm not intimately familiar with the<br>SLA code, your analysis makes sense. I've put some comments on the<br>issue regarding the implementation of your patch.<br><br><blockquote type="cite">20462<br>Trunk not hungup if SLA Station hangs up before answer<br>Again because ast_dial() is called asynchronously, if the originating<br>extension hangs up there is nothing to tell the trunk being dialed to<br>hang up.... it continues to ring and if someone answers attempts to make<br>a connection, which fails.<br>The solution is to check status of the originating channel in the same<br>loop that is looking for state changes on the trunk channel / waiting<br>for an answer. If the originating channel is no longer active (has hung<br>up) then you can abandon waiting for the trunk to answer and shut down<br>that dial.<br>In course of testing this I found that this part of the code in<br>app_meetme.c is a tight loop... for ( ; ; ) that spins as fast as the<br>CPU will let it. This is an unnecessary CPU hog and so I also inserted<br>a 100ms sleep into the loop before checking for active originating<br>channel. This seems like a reasonable sleep.... testing 10 times a<br>second for the trunk to answer seems fast enough. However maybe the<br>original developer had a good reason for the tight loop? Comments?<br></blockquote><br>Issue commented as well.<br><br><blockquote type="cite">20675<br>Add return codes to SLATrunk()<br>I found a need in my dialplan to know exactly which extension (SLA<br>Station) actually answered the call. There is no way to determine this<br>using dialplan functions so I added return codes to SLATrunk() that<br>would provide both the channel and SLA Station name that actually<br>answered the call. This is not a bug fix but an enhancement to the<br>SLATrunk() function.<br><br></blockquote><br>Do you need to put the return codes on both halves of the Local channel?<br> If so, in what scenario is that needed?<br><br><blockquote type="cite">I would like to see these added into the mainline code and would be<br>interested in comments from the dev community.<br><br>Thank you<br>David<br><br><br>--<br>_____________________________________________________________________<br>-- Bandwidth and Colocation Provided by <a href="http://www.api-digital.com">http://www.api-digital.com</a> --<br><br>asterisk-dev mailing list<br>To UNSUBSCRIBE or update options visit:<br> <a href="http://lists.digium.com/mailman/listinfo/asterisk-dev">http://lists.digium.com/mailman/listinfo/asterisk-dev</a><br><br></blockquote><br><br>-- <br>Matthew Jordan<br>Digium, Inc. | Engineering Manager<br>445 Jan Davis Drive NW - Huntsville, AL 35806 - USA<br>Check us out at: <a href="http://digium.com">http://digium.com</a> & <a href="http://asterisk.org">http://asterisk.org</a><br><br><br><br>--<br>_____________________________________________________________________<br>-- Bandwidth and Colocation Provided by <a href="http://www.api-digital.com">http://www.api-digital.com</a> --<br><br>asterisk-dev mailing list<br>To UNSUBSCRIBE or update options visit:<br> <a href="http://lists.digium.com/mailman/listinfo/asterisk-dev">http://lists.digium.com/mailman/listinfo/asterisk-dev</a><br></blockquote></div><br></body></html>