[asterisk-dev] SLA Bugs... 20440, 20462 and 20675

Matthew Jordan mjordan at digium.com
Mon Nov 19 09:14:33 CST 2012


On 11/15/2012 09:42 PM, David Kerr wrote:
> 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.
> 
> 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.

So first of all, thanks a lot for writing these patches!  Issues with
patches typically receive  more attention and move through the process
faster than those without - so hopefully this will help get these issues
resolved.

> 20440
> No ringback towards SLA Station that originated an outbound call.
> 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's out the pointer to
> originating channel in the dial structure).
> The solution is to have the ringing indication sent back to originating
> channel in the SLA trunk dial code in app_meetme.c.
> 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't really started
> to ring yet.

Fairly straight forward, and while I'm not intimately familiar with the
SLA code, your analysis makes sense.  I've put some comments on the
issue regarding the implementation of your patch.

> 20462
> Trunk not hungup if SLA Station hangs up before answer
> 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.
> 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.
> 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?

Issue commented as well.

> 20675
> Add return codes to SLATrunk()
> 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.
> 

Do you need to put the return codes on both halves of the Local channel?
 If so, in what scenario is that needed?

> I would like to see these added into the mainline code and would be
> interested in comments from the dev community.
> 
> Thank you
> David
> 
> 
> --
> _____________________________________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
> 
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-dev
> 


-- 
Matthew Jordan
Digium, Inc. | Engineering Manager
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at: http://digium.com & http://asterisk.org





More information about the asterisk-dev mailing list