A few months ago I tried to get Shared Line Appearance (SLA) features of Asterisk to work for me in an entirely SIP environment.  While I could get incoming calls to work, I ran into a couple of pretty severe problems with outbound calls.  I opened bugs 20440 and 20462 to document them.<div>

<br></div><div>As these received no attention from any developer after a couple of months I took it upon myself to fix them.  I have uploaded patches that I would like the Asterisk dev community to review and consider incorporating into the mainline code, asterisk 1.8 and up.</div>

<div><br></div><div>20440</div><div>No ringback towards SLA Station that originated an outbound call.</div><div>I traced the problem to be because the SLA code triggers ast_dial() as an asynchronous request. Doing this prevents the normal indication of ringing being passed back to the originating channel in the dial functions in dial.c (an asynchronous request NULL&#39;s out the pointer to originating channel in the dial structure).</div>

<div>The solution is to have the ringing indication sent back to originating channel in the SLA trunk dial code in app_meetme.c.</div><div>After some testing I determined that it is necessary to send progress/ringing signals back to more accurately reflect status of the outbound trunk channel, else you get a dial tone when it is already attempting to connect, or a ringing tone when it hasn&#39;t really started to ring yet.</div>

<div><br></div><div>20462</div><div>Trunk not hungup if SLA Station hangs up before answer</div><div>Again because ast_dial() is called asynchronously, if the originating extension hangs up there is nothing to tell the trunk being dialed to hang up.... it continues to ring and if someone answers attempts to make a connection, which fails.</div>

<div>The solution is to check status of the originating channel in the same loop that is looking for state changes on the trunk channel / waiting for an answer.  If the originating channel is no longer active (has hung up) then you can abandon waiting for the trunk to answer and shut down that dial.</div>

<div>In course of testing this I found that this part of the code in app_meetme.c is a tight loop... for ( ; ; ) that spins as fast as the CPU will let it.  This is an unnecessary CPU hog and so I also inserted a 100ms sleep into the loop before checking for active originating channel.  This seems like a reasonable sleep.... testing 10 times a second for the trunk to answer seems fast enough. However maybe the original developer had a good reason for the tight loop?  Comments?</div>

<div><br></div><div>20675</div><div>Add return codes to SLATrunk()</div><div>I found a need in my dialplan to know exactly which extension (SLA Station) actually answered the call. There is no way to determine this using dialplan functions so I added return codes to SLATrunk() that would provide both the channel and SLA Station name that actually answered the call.  This is not a bug fix but an enhancement to the SLATrunk() function.</div>

<div><br></div><div><br></div><div>I would like to see these added into the mainline code and would be interested in comments from the dev community.</div><div><br></div><div>Thank you</div><div>David</div>