[Home]

Summary:ASTERISK-13615: [patch]Timeout settings in features.conf don't work as intended
Reporter:Sven Hirschmueller (sodom)Labels:
Date Opened:2009-02-20 04:59:10.000-0600Date Closed:2009-03-11 07:07:28
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Resources/res_features
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) 14515.patch
( 1) Logfil1.log
Description:It seems that some of the feature.conf settings didn't work as intendet, at least for the misdn channel.

a) I changed the code for disconnect from "*0" to "*0#" but asterisk still disconnects with the code *0 (feature show, shows me that it is successfuly changed to *0#)
b) I changed the timeout for featuresdigits from 500ms to 1000ms but as it seem the timeout is not on a didgit base it's for the complete command. If i did't finish the complete feature dial string in this time, the feature isn't activated. (All fetures were changed to three digit numbers on our side.)
c) I changed the timeout for transferdigit from 3 secs to 15sec as it has the same issue as b) if i don't complete the number in the configured time, the transfer is interrupted.

****** ADDITIONAL INFORMATION ******

I checked the bahaviour with a debug 2 state and it simply seems that the feature didgit timer and the transfer digit timer are not resettet after on digit is dialed.

Asterisk 1.4.23.1
Comments:By: Steve Murphy (murf) 2009-02-25 16:56:27.000-0600

sodom-- I uploaded the 14515.patch; I was able to see that the channel_bridge returns twice when a digit is entered; once for DTMF_START, once for DTMF_END.
These both subtract the time passed from the feature_timeout, and thus cut the timeout in half.

The patch just fixes the featuredigittimeout; I'll start looking at the transferdigittimeout stuff now... but it will be good to know that this patch at least solves that problem, so please test it out.
By: Steve Murphy (murf) 2009-02-25 17:13:55.000-0600

sodom-- OK, I have not been able to repeat the problem where *0 can activate a feature when *0# is set. Just *0 times out.

And, my preliminary tests on the transferdigittimeout show that they seem to be working as advertised for 2 and 3 key patterns. I set the timeout for 5 sec, and
counted to 4 before hitting the next key, and the transfer went OK.

Please give me more detail on how to reproduce your problems.
By: Sven Hirschmueller (sodom) 2009-02-26 03:14:28.000-0600

Hi,

i attach a session log with my unpatched system to show you the *0, disconnect problem.

In the session i simply dial from one misdn phone to another put it on hold via *1# (atf) and then tried to disconnect my new unconnected channel immeadiatly with *0# again but as always the unhold happens after *0 even though my feature conf show *0# for disconnect. I tried to spread the cli log via empty commands, so you can read it. The disconnect event is marked by a "kkkkkkkkkkkkkkkkk" command :)

I hope i don't run into a simple pebcac (problem exists between computer and chair) :)

If you need my configuration files..say so, because i need to anonomeise them first.
By: Steve Murphy (murf) 2009-02-26 10:33:25.000-0600

Hmmm, you are in the middle of an attended transfer, and are trying to use feature sequences; that won't work. When you enter attended transfer, the code will say "transfer", and then it calls the ast_app_dtget() routine, which is fairly restricted in what it does. And, most certainly, recognizing feature codes is not on the list. Most likely, it determined that *0 is not a possible available extension, and terminated immediately.

Right now, the feature codes can only be recognized while a bridge is active (two channels connected and trading audio). There is a bug open with a patch that will allow the disconnect feature to be detected outside a bridge, and it's targeted to be used in dial to allow disconnects while you are dialing. Perhaps in at some future time this could also be done here, but that patch has some pretty big problems, and will be going on reviewboard, so it will be a few weeks before it makes into trunk (1.4 is not even a possibility for that enhancement).


So, your (a) in the original bug problem description can't be done;
(b) I provide a patch for
(c) I can't reproduce-- any more details? I increased the transferdigittimeout to 15 also, and got into attended transfer, and waited about 13 seconds before hitting each of the next digits, and the transfer finished just fine.
By: Sven Hirschmueller (sodom) 2009-02-26 10:58:21.000-0600

Hmm,

so it's not possible to stop a transfer other then dialing a wrong number to come back to your initial connected partner?

I will test your patch on monday first, sorry but then i'am back at my office and have access to my test environment again.
By: Digium Subversion (svnbot) 2009-02-26 11:09:04.000-0600

Repository: asterisk
Revision: 178804

U   branches/1.4/res/res_features.c

------------------------------------------------------------------------
r178804 | murf | 2009-02-26 11:09:04 -0600 (Thu, 26 Feb 2009) | 28 lines

This patch prevents the feature detection timeout from being cut in half.

Because the ast_channel_bridge() call will return 0 and pass
a frame pointer for both DTMF_BEGIN and DTMF_END, the feature_timer
field in hte config struct is getting decremented twice, which
effectively cuts the digittimeout in half. I added conditions
to the if statement to only let DTMF_END frames to flow thru,
which solved the problem. Also, when the frame pointer is null,
let control flow thru-- this usually happens on timeouts. I added
a comment to the code to explain what's going on and why.

Many thanks to sodom for reporting this problem. Personnally, it always seemed
like something was wrong with the featuredigittimeout, but I never
could quite decide what... and was too busy to investigate.
This bug forced the issue, and now we know.

Sodom had other issues in 14515, but I couldn't reproduce them. If
he still has problems, and wants to get them solved, he is welcome
to reopen 14515.


(closes issue ASTERISK-13615)
Reported by: sodom
Patches:
     14515.patch uploaded by murf (license 17)
Tested by: murf, sodom


------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=178804
By: Digium Subversion (svnbot) 2009-02-26 11:22:26.000-0600

Repository: asterisk
Revision: 178828

_U  trunk/
U   trunk/main/features.c

------------------------------------------------------------------------
r178828 | murf | 2009-02-26 11:22:26 -0600 (Thu, 26 Feb 2009) | 34 lines

Merged revisions 178804 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
 r178804 | murf | 2009-02-26 10:09:03 -0700 (Thu, 26 Feb 2009) | 28 lines
 
 This patch prevents the feature detection timeout from being cut in half.
 
 Because the ast_channel_bridge() call will return 0 and pass
 a frame pointer for both DTMF_BEGIN and DTMF_END, the feature_timer
 field in hte config struct is getting decremented twice, which
 effectively cuts the digittimeout in half. I added conditions
 to the if statement to only let DTMF_END frames to flow thru,
 which solved the problem. Also, when the frame pointer is null,
 let control flow thru-- this usually happens on timeouts. I added
 a comment to the code to explain what's going on and why.
 
 Many thanks to sodom for reporting this problem. Personnally, it always seemed
 like something was wrong with the featuredigittimeout, but I never
 could quite decide what... and was too busy to investigate.
 This bug forced the issue, and now we know.
 
 Sodom had other issues in 14515, but I couldn't reproduce them. If
 he still has problems, and wants to get them solved, he is welcome
 to reopen 14515.
 
 
 (closes issue ASTERISK-13615)
 Reported by: sodom
 Patches:
       14515.patch uploaded by murf (license 17)
 Tested by: murf, sodom
........

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=178828
By: Digium Subversion (svnbot) 2009-02-26 11:30:12.000-0600

Repository: asterisk
Revision: 178866

_U  branches/1.6.0/
U   branches/1.6.0/main/features.c

------------------------------------------------------------------------
r178866 | murf | 2009-02-26 11:30:12 -0600 (Thu, 26 Feb 2009) | 41 lines

Merged revisions 178828 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk

................
 r178828 | murf | 2009-02-26 10:22:11 -0700 (Thu, 26 Feb 2009) | 34 lines
 
 Merged revisions 178804 via svnmerge from
 https://origsvn.digium.com/svn/asterisk/branches/1.4
 
 ........
   r178804 | murf | 2009-02-26 10:09:03 -0700 (Thu, 26 Feb 2009) | 28 lines
   
   This patch prevents the feature detection timeout from being cut in half.
   
   Because the ast_channel_bridge() call will return 0 and pass
   a frame pointer for both DTMF_BEGIN and DTMF_END, the feature_timer
   field in hte config struct is getting decremented twice, which
   effectively cuts the digittimeout in half. I added conditions
   to the if statement to only let DTMF_END frames to flow thru,
   which solved the problem. Also, when the frame pointer is null,
   let control flow thru-- this usually happens on timeouts. I added
   a comment to the code to explain what's going on and why.
   
   Many thanks to sodom for reporting this problem. Personnally, it always seemed
   like something was wrong with the featuredigittimeout, but I never
   could quite decide what... and was too busy to investigate.
   This bug forced the issue, and now we know.
   
   Sodom had other issues in 14515, but I couldn't reproduce them. If
   he still has problems, and wants to get them solved, he is welcome
   to reopen 14515.
   
   
   (closes issue ASTERISK-13615)
   Reported by: sodom
   Patches:
         14515.patch uploaded by murf (license 17)
   Tested by: murf, sodom
 ........
................

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=178866
By: Digium Subversion (svnbot) 2009-02-26 11:38:19.000-0600

Repository: asterisk
Revision: 178869

_U  branches/1.6.1/
U   branches/1.6.1/main/features.c

------------------------------------------------------------------------
r178869 | murf | 2009-02-26 11:38:19 -0600 (Thu, 26 Feb 2009) | 41 lines

Merged revisions 178828 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk

................
 r178828 | murf | 2009-02-26 10:22:11 -0700 (Thu, 26 Feb 2009) | 34 lines
 
 Merged revisions 178804 via svnmerge from
 https://origsvn.digium.com/svn/asterisk/branches/1.4
 
 ........
   r178804 | murf | 2009-02-26 10:09:03 -0700 (Thu, 26 Feb 2009) | 28 lines
   
   This patch prevents the feature detection timeout from being cut in half.
   
   Because the ast_channel_bridge() call will return 0 and pass
   a frame pointer for both DTMF_BEGIN and DTMF_END, the feature_timer
   field in hte config struct is getting decremented twice, which
   effectively cuts the digittimeout in half. I added conditions
   to the if statement to only let DTMF_END frames to flow thru,
   which solved the problem. Also, when the frame pointer is null,
   let control flow thru-- this usually happens on timeouts. I added
   a comment to the code to explain what's going on and why.
   
   Many thanks to sodom for reporting this problem. Personnally, it always seemed
   like something was wrong with the featuredigittimeout, but I never
   could quite decide what... and was too busy to investigate.
   This bug forced the issue, and now we know.
   
   Sodom had other issues in 14515, but I couldn't reproduce them. If
   he still has problems, and wants to get them solved, he is welcome
   to reopen 14515.
   
   
   (closes issue ASTERISK-13615)
   Reported by: sodom
   Patches:
         14515.patch uploaded by murf (license 17)
   Tested by: murf, sodom
 ........
................

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=178869
By: Steve Murphy (murf) 2009-02-26 11:57:35.000-0600

Sodom--

As to aborting a transfer:

well, there's hanging up, which would tend to end the currently bridged call; a call to the disconnect feature probably would be equivalent to this!

or letting the number time out and ending the transfer, but then you'd be still be bridged and could try again.