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

Mon Nov 19 14:57:34 CST 2012

Matthew,
  Thank you for reviewing and commenting, greatly appreciated.  I'll take a look at each of your comments and respond in the issue comments.

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.

[TestInbound]
exten => 105,1,Dial(local/s at InboundSLA,${RINGTIME},r(ring)tU(subroutine))

[InboundSLA]
exten => s,1,SLATrunk(SLAtrunk1)
 same => n,Set(ANSWERED_EXTEN=${CUT(CUT(SLATRUNK_ANSWEREDCHANNEL,"-",1),"/",2)})

[subroutine]
exten => s,1,Set(ANSWERED_EXTEN=${CUT(CUT(SLATRUNK_ANSWEREDCHANNEL,"-",1),"/",2)})

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).

David

On Nov 19, 2012, at 10:14 AM, Matthew Jordan <mjordan at digium.com> wrote:

> 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
> 
> 
> 
> --
> _____________________________________________________________________
> -- 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20121119/80281acf/attachment.htm>