[Home]

Summary:ASTERISK-20440: [patch] No ringback towards SLAstation on outbound trunk call.
Reporter:dkerr (dkerr)Labels:
Date Opened:2012-09-18 15:10:49Date Closed:2013-01-22 08:55:33.000-0600
Priority:MajorRegression?
Status:Closed/CompleteComponents:Applications/app_meetme Applications/SLA
Versions:1.8.15.0 Frequency of
Occurrence		Constant
Related
Issues:
Environment:AstlinuxAttachments:( 0) asterisk-11-bugid20440.patch
( 1) asterisk-11-bugid20440+20462.patch
( 2) Direct_Outbound.txt
( 3) DISA_outbound.txt
( 4) extensions.conf
( 5) Simulated_Inbound.txt
( 6) Simulated_Outbound_Direct.txt
( 7) Simulated_Outbound_DISA.txt
( 8) sip.conf
( 9) sla.conf
(10) SLAstation_log.txt
Description:This is similar to ASTERISK-11549 except that the problem is with calls in the other direction. If I make an outbound call from a SLA phone using the SLAStation then there is no ringtone audible to the phone that originates the call.  Both SLA stations and SLA trunks are SIP channels and for outbound I have tried both the DISA() method of connecting to a trunk (get dialtone from DISA and then enter a number to call) and directly connecting (using Dial() application instead of DISA()).

I have turned on debug and verbose in the asterisk CLI and can observe the SIP messages and dialplan execution.  A SIP RINGING message is received by asterisk from the trunk, but the message is not passed on to the SLA station.  I have set progressinband=yes in the sip.conf and this made no difference.

Comments:By: dkerr (dkerr) 2012-09-18 15:28:38.575-0500

Debug trace from Asterisk CLI in attached file.
By: Rusty Newton (rnewton) 2012-09-19 19:59:10.559-0500

Please attach full Asterisk logs with VERBOSE and DEBUG enabled at level 5 covering the same demonstration as you provided in the "SLAstation log.txt"

If possible provide a sanitized sip.conf and any config files relevant for the SLA configuration.

Thanks!

By: dkerr (dkerr) 2012-09-23 10:37:18.719-0500

Attached are the relevant configuration files. Simplified for the purpose of illustrating this bug.
By: dkerr (dkerr) 2012-09-23 11:01:21.741-0500

Attached are log files from asterisk console with debug and verbose at 5 and SIP debug on.  Four files here... two use the DISA() function to generate dialtone and receive number to dial.  Two have the number passed in directly.

Also, the two "simulated" are when I have a SLA extension (exten 111) call another asterisk extension that is not in the SLA group (exten 101). This may be easier to read as there is no authentication challenge from the trunk provider, but I provided those as well.

Through the course of testing I have found another SLA bug for which I will open another issue.

By: dkerr (dkerr) 2012-09-23 11:07:07.664-0500

For completeness I have attached a simulated inbound call. In this instance the caller does hear a ringtone.  To test this I have a non SLA extension (101) dial 105 which in my dialplan (extensions.conf attached) simulates what would happen on an inbound trunk call... it called SLAtrunk().  This caused the two phones in the SLA group (extensions 111 and 112) to ring and ringtone is sent back to caller (101).

David
By: dkerr (dkerr) 2012-09-25 14:26:58.651-0500

See attached comments and files.
By: dkerr (dkerr) 2012-11-09 07:40:28.034-0600

What is status of this please?  I have provided all requested debug info.
David
By: dkerr (dkerr) 2012-11-09 07:41:09.111-0600

What is the status of this please?
By: Joshua C. Colp (jcolp) 2012-11-09 07:44:36.501-0600

There is no status update at this time as the issue has not yet been handled by a developer. Any updates will be posted to this issue.
By: dkerr (dkerr) 2012-11-09 07:48:53.106-0600

Has it been assigned to a developer?  How high up in the priority queue is it.  Any estimate when it will be looked at?  This is holding up me deploying asterisk to replace an aging analog phone system.

David
By: Joshua C. Colp (jcolp) 2012-11-09 07:52:57.494-0600

It has not been assigned and will probably take quite awhile to get to, unless a community member decides to work on it sooner. If you want to try to speed things up you can try to find a developer who is interested to take this on or post a bounty on the asterisk-biz mailing list.
By: dkerr (dkerr) 2012-11-10 21:16:54.714-0600

Okay, challenge accepted. See attached patch file for a one-line fix inside app_meetme.c.
The ast_dial functions would normally have sent the ringback to the originating channel, but because SLA requested an asynchronous dial the originating channel is lost inside the dial functions. Therefore it needs to be triggered by the SLA code.

Also please see bug ASTERISK-20462 for another critical fix.  And ASTERISK-20675 for a desirable feature.

Thanks !
By: Michael L. Young (elguero) 2012-11-10 22:03:47.467-0600

Same comment as in the other issue.  No need to include the issue number in the comment.

Thanks
By: dkerr (dkerr) 2012-11-11 11:00:52.573-0600

Here is an updated version. This is slightly different -- rather than always generating a ringback I wait until the trunk goes into ring/ringing state. This prevents a ringback tone being generated if the destination is busy/congested.  With the first version of the patch the caller would hear a brief ringtone followed by the congested tone.  This new version prevents that... caller hears congested.

Thanks
David
By: dkerr (dkerr) 2012-11-15 19:25:58.404-0600

An updated version that sends more accurate trunk line state back to the originating channel
By: Matt Jordan (mjordan) 2012-11-19 08:39:56.299-0600

A few comments on the patch:
# Asterisk coding guidelines [specify that variables should not be declared mid-block|https://wiki.asterisk.org/wiki/display/AST/Coding+Guidelines#CodingGuidelines-Declarationoffunctionsandvariables] - so your declaration of {{last_state}} and {{current_state}} should be moved up to the top of {{dial_trunk}}
# You need to introduce a 'break' after the assignment of done.  Previously, this would fall through to the 'break' statement of the {{AST_DIAL_RESULT_PROCEEDING}} case - now, it falls through into your state change in {{AST_DIAL_RESULT_TRYING}}.  This means you'll assign a state of {{AST_CONTROL_PROGRESS}} when a channel has hung up - there's even a chance it will attempt to indicate that to the channel when its hung up (which would be bad).  This leads to:
# Move the {{if (done) break;}} check before your indication.  That way, if something has hung up, you're guaranteed to bail out before you attempt to indicate to the channel.  That makes the code a bit more robust in the face of future changes.

By: dkerr (dkerr) 2012-11-19 19:22:51.395-0600

Thanks for the code review. You made some good points and I agree with all of them. I have updated the patch to reflect all three of your suggestions.

Thanks
David