|Summary:||ASTERISK-18586: When Dial() plays warning messages in the LIMIT options, it put the other party into complete silence|
|Reporter:||David O Reilly (trendboy)||Labels:|
|Date Opened:||2011-09-20 06:50:22||Date Closed:||2018-01-02 08:44:25.000-0600|
|Environment:||Linux and all||Attachments:|
|Description:||This may or may not be considered a bug but it is pretty nasty as it makes callers think the call has hungup.|
If you decide to use the L option in the Dial app and you say play to caller and callee, it will actually put one of the parties into silence while it plays the message and then it goes to the other party and puts the other into silence to play the message. Should it not play the message to both parties at the same time?
What it should do:
a) When the L option is used and LIMIT_PLAYAUDIO_CALLEE and LIMIT_PLAYAUDIO_CALLER is set to yes, then it should play to both of them at once (not one at a time while putting the other party into silence as it currently does).
b) if it is set that LIMIT_PLAYAUDIO_CALLER is yes and LIMIT_PLAYAUDIO_CALLEE is no - or the other way around - the party who is not to hear the sound should be either played a ringing sound or music on hold or a beep or something - silence makes it look like the call has hungup. At the moment you have to guess when the message has stopped being played which is terrible :)
c) A new option should exist - to be able to play different audio files to either the caller or callee - that way you can play different messages to each - so LIMIT_PLAYAUDIO_CALLER_FILE= and LIMIT_PLAYAUDIO_CALLEE_FILE= or something to that effect. When one finishes then it would either play music or put a beep or a ringing sound - just anything but silence, so maybe another option: LIMIT_PLAYAUDIO_WHEN_COMPLETE=MOH - but this is really not that important but a very nice to have. A and B are really important I reckon as the sound of silence is deafening :)
If there is anything I can do to explain this better let me know. It is related to a conversation I had at: http://forums.digium.com/viewtopic.php?p=161390
You are all awesome!!!
|Comments:||By: Leif Madsen (lmadsen) 2011-09-21 08:57:33.460-0500|
I'm acknowledging this issue because I feel that does make sense. However, this is technically a feature request without a patch, so the priority of it getting resolved is going to be quite low.
The quickest way to get this resolved is either to provide a patch, or to find a community developer (or hire a developer) who would be willing to provide a patch.
By: David O Reilly (trendboy) 2011-09-21 13:11:45.433-0500
I'll be happy to look into it and provide a fix myself when I get time. At the moment I'm mad busy on another dev contract with Asterisk.
By: SirLouen (sirlouen) 2014-08-10 13:20:12.206-0500
I've found this issue a real problem. If the warning audio is more than 0,5 sec is pretty obvious that this mechanism is faulty. If the warning audio stays short then both peers can't notice the "silence", but if the warning audio is for example 10 seconds, then happens that first the caller hears the warning file, and after the callee for a total of 20 secs (10caller+10callee)
This has remain untouched from version 1.8 to 11-cert4
Any possible solution to this issue?
By: Richard Mudgett (rmudgett) 2014-08-11 10:15:00.480-0500
You may want to try v12+ as the bridging framework would affect this behaviour. Otherwise, nothing has been done for this issue specifically.
By: Joshua C. Colp (jcolp) 2017-12-19 06:32:55.866-0600
Per the comment from Richard, has this improved at all with the new bridging work that has gone into the current supported versions of Asterisk?
By: Asterisk Team (asteriskteam) 2018-01-02 08:44:26.016-0600
Suspended due to lack of activity. This issue will be automatically re-opened if the reporter posts a comment. If you are not the reporter and would like this re-opened please create a new issue instead. If the new issue is related to this one a link will be created during the triage process. Further information on issue tracker usage can be found in the Asterisk Issue Guidlines .