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

[David Kerr]

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.

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.

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?

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.


I would like to see these added into the mainline code and would be
interested in comments from the dev community.

Thank you
David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20121115/982ac796/attachment.htm>