|Summary:||ASTERISK-04533: Limit fails to hangup call when no RTP|
|Date Opened:||2005-07-07 05:43:30||Date Closed:||2008-01-15 15:44:06.000-0600|
|Description:||Occurs on SIP to SIP local phones and more seriously SIP to IAX (PSTN etc) connections. We are using prepaid callingcard application which used the dial..L()limit command. Worst case is when a user calls an expensive international destination and puts call on hold or silence occurs. The call will continue forever with huge bill for the VOIP reseller, negative credit for the user where the user would have no liablilty to pay for the extended call.|
We have found when using the CLI command softhangup informs us that the request will be actioned on next rtp read, but if we have silence/on hold or speakerphone with no microphone, the call will last forever.
|Comments:||By: Michael Jerris (mikej) 2005-07-12 19:43:59|
Can you please test this and report if it is also an issue on cvs head?
By: howard (howard) 2005-07-13 04:39:10
OK, Will test with latest
By: howard (howard) 2005-07-14 06:39:31
We confirm that this fault exists in CVS HEAD. Its repeatable every time. To simulate just make call, you hear voice countdowns then if you make no sound or put phone on speaker monitor then the call lasts forever.
If you then make sound to the handset ( we are using Cisco 7912G) the call clears immediately and debug shows the Limit reached and call clearing. This could in fact be hours after the max time specified in the Limit command.
This is a significant issue and we are hoping it can be rectified soon.
If there is anything we can do to help, please contact us (email@example.com)
By: Brian West (bkw918) 2005-07-14 10:50:59
Its not something you can fix easily. Asterisk times off the RTP stream.. it gets nothing.. it does nothing.. Now if you want to fund DTX and VAD support into asterisk then it could do this.
By: Russell Bryant (russell) 2005-07-18 14:08:14
This appears to only be an issue with silence suppression, which currently, we do not support in Asterisk. Can you turn off silence suppression on your phone and verify that it works as expected?
By: Olle Johansson (oej) 2005-07-18 14:25:55
Well, if the call is on hold no phone will send RTP regardless of silence suppression. We need to look into how app_dial handles limits, if it's using the scheduler or something else...
By: howard (howard) 2005-07-19 03:17:21
Thanks for the information about silence suppression. We figured this out ourselves but did not respond to the earlier message about wanting money as we though it was a bit OTT
By: Anthony Minessale (anthm) 2005-07-20 12:34:18
You are pretty much bound to running the call through the ast_generic_bridge function for this to work the L option is supposed to cancel the possibility of a native bridge and run that code which has a timed read on the 2 channels involved in the call. This ensures that the code is looped as the call is in a bridge even when there is no audio being read. (see line 2907 of channel.c)
I'm not suggesting it's not broken just pointing out the code that handles the job and what it's supposed to do.
There was an issue with the call limit that I recently fixed in bug 4760
http://bugs.digium.com/view.php?id=4760 you may want to see if it was related.
By: howard (howard) 2005-07-20 13:45:43
Many thanks for the advice on bridging. We also confirm that Limit clears call when no sound occuring (2 local phones in monitor mode with no mic) BUT silence suppression has been turned off. It also clears call to fwd echo service
Will take a look at the recent bug fix
By: Michael Jerris (mikej) 2005-07-28 16:30:22
where does this stand? Is it still an issue?
By: howard (howard) 2005-08-05 02:05:50
We are hoping to retest this soon when we complete a rebuild on dual xeon system
By: Mark Spencer (markster) 2005-08-08 02:51:16
Fixed in CVS head (should be anyhow), feel free to reopen if you still have trouble after updating.
By: Digium Subversion (svnbot) 2008-01-15 15:44:06.000-0600
r6309 | markster | 2008-01-15 15:44:06 -0600 (Tue, 15 Jan 2008) | 2 lines
Don't wait longer than our timeout for something to happen (bug ASTERISK-4533)