| Summary: | ASTERISK-10487: [patch] Create a Dial option that switches from Ringing to Early Media | ||||
| Reporter: | Gaspar Zoltan (gasparz) | Labels: | |||
| Date Opened: | 2007-10-10 07:22:16 | Date Closed: | 2013-10-22 10:18:48 | ||
| Priority: | Major | Regression? | No | ||
| Status: | Closed/Complete | Components: | Applications/app_dial Applications/NewFeature | ||
| Versions: | Frequency of Occurrence | ||||
| Related Issues: |
| ||||
| Environment: | Attachments: | ( 0) 10487.patch ( 1) 10934.patch ( 2) app_dial_1.diff ( 3) play_early_sounds_1.4.18.diff | |||
| Description: | I was asked to develop a feature thar switches between the ringing tone and early media. So when you dial asterisk starts generating ringing tone, but when the called channels starts sendig RTP (like mobile carriers: "The person you are trying to reach is unavailable") with or without answering the channel, the asterisk would have to end generating the ringing tone and send the media it receives. The patch does this. | ||||
| Comments: | By: Joshua C. Colp (jcolp) 2007-10-10 08:12:40 Please provide your patch in unified format. Thanks! By: Gaspar Zoltan (gasparz) 2007-10-10 11:22:36 app_dial_1.diff is in unified format By: Jason Parker (jparker) 2007-11-08 16:40:18.000-0600 So, after reviewing this, I'm not sure I entirely understand why this is actually needed. Let me explain... If I'm reading this right, with this dialplan variable set, you will play the ringing to the user until you start getting early media, at which point the ringing stops, and the user hears the audio. I don't see why you would ever want any different behavior - for either ringing or MOH. I would propose simply removing the ast_test entirely. Does that make sense? By: Gaspar Zoltan (gasparz) 2007-11-19 09:04:01.000-0600 Sorry for the delayed response, I was away. Yes, that is the feature we want to achive. The dialplan variable concept is introduced for the default behaviour of asterisk not to change. If you feel that this behaviour is the correct one and should be the default one with no possibility to fall back to the current behaviour it is more than ok to remove the additional variable. Let me know how you feel about this so that we can modify the code if needed. By: Olle Johansson (oej) 2007-12-15 03:43:16.000-0600 I think early media should always break asterisk-generated ringing tones ("r" in dial). Not doing that is a bug. By: Jason Parker (jparker) 2007-12-17 12:50:57.000-0600 oej, do you think we should implement this patch in 1.4 then, minus the config option? I think the moh case would be the same as the ringing case. By: Olle Johansson (oej) 2007-12-17 13:04:05.000-0600 Yes, I would agree with that. By: Jason Parker (jparker) 2007-12-18 17:58:58.000-0600 This fix can't be right. We wouldn't even have attempted to get a frame of audio by this point. By: Gaspar Zoltan (gasparz) 2008-02-26 07:09:19.000-0600 This fix is simple, let me explain what we tried to do: if we receive a RTP frame we deactivate any generators and make the 2 channels compatible For this we removed the ast_test_flag(outgoing, OPT_RINGBACK|OPT_MUSICBACK) condition. What do you think of it? By: Jason Parker (jparker) 2008-03-04 16:57:40.000-0600 After looking at this again, I have a question.. Why would you ever use the 'r' option, and also want to hear early media? Several people I've talked to say that they use the 'r' option specifically to mask out early media. "you want to force ringback when dialing cell phones, for example, if you want to mask the 'the cellular customer you have dialed is either out of the area or their phone is off'" For what purpose are you using 'r'? By: Gaspar Zoltan (gasparz) 2008-03-09 00:35:41.000-0600 Good question qwell, here is the answer. We run a prepaid system and when we try to connect an outbound call we have several trunks that can connect the call. The real life shows us that calls are getting refused, and sometimes the time til first early media is quite long. If we don't use the -r option in that setup time the customer will hear silence, if you use it he won't hear the early media. Now if the silence period if quite large > 10-30 seconds the customer gets annoyed, he thinks we are not trying to connect the call and reports a dead air issue. Ex. Time point A invite trunk1 503 Service unavailable from trunk 1 ... invite trunk n 183 Session Progress/200 ok Time point B Dead Air time = Time point B- Time point A With this patch he will receive feedback from the first second (our ringing tone). When a carrier sends back 183 he will receive: - maybe another ringing tone - early sounds As a lot of carriers use slightly diferent ringing tones this process usually gives feedback to the customer about the call compleation process, assuring him that the call is connected meanwhile. By this the customer experience is better and he is more likely willing to wait more for the call compleation on a ringing tone than on dead air (silence). By: Joshua C. Colp (jcolp) 2008-03-10 09:18:19 We can't change behavior of the 'r' option like this... we are going to have to make it be set via another option or method. By: Gaspar Zoltan (gasparz) 2008-03-10 11:19:08 I agree with oej that "early media should always break asterisk-generated ringing tones", but as long as you can select the functionality you need I'm happy. So we have 3 options: - make this the default functionality - create a channel variable that controls this (like in the original diff) - create a new option for dial By: Joshua C. Colp (jcolp) 2008-06-04 08:56:04 I vote for another option to Dial. Any other thoughts? By: klaus3000 (klaus3000) 2008-06-06 05:31:56 @qwell: Hi! I often have similar problems when interconnecting PBXs using Asterisk, e.g: site1: PSTN----->Asterisk1<----ISDN------>PBX1 ^ | SIP or | IAX site2: V PSTN----->Asterisk2<----ISDN------>PBX2 Now an extension of PBX1 calls an extension of PBX2 with PSTN bypass using SIP or IAX. The PBX2 sends CALL PROCEEDING and ALERTING to Asterisk2 without any Progress Indicator. But strangly Asterisk1 sends CALL PROCEEDING and ALERTING to PBX1 with Progress Indicator and "inband information available". Thus, the user1 das not get ringback as PBX2 does not generate inband audio. Probably this is a bug somewhere else in Asterisks code, but could be manually fixed with 'r' option too, except that real inband audio is not anymore possible. By: Mark Michelson (mmichelson) 2008-08-26 16:44:08 I have uploaded 10934.patch. This adds an option 'R' which will cause ringback to play like with the 'r' option. However, when using 'R' we do not block other indications from being received (e.g. "progress" and "proceeding"). If this option does what is asked for, then I think this can go in. Please test to be sure that this offers the correct behavior. Since this is a new feature, the patch was made against Asterisk trunk, specifically against revision 139771. By: Mark Michelson (mmichelson) 2008-10-10 09:59:31 I uploaded a patch here over a month and a half ago and have heard no feedback. If I hear nothing before the end of next week, this issue will be closed. By: klaus3000 (klaus3000) 2008-10-12 15:15:11 I did not test the patch as with my problems I think is the wrong solution. In all the problems I have, Asterisk starts forwarding inband audio although there is no indication that inband audio is available. Thus, even if the R option is set, if the channel indicates that inband audio is available although there is no inband audio, I still have silence. Nevertheless it can solve gasparz's problems. By: Leif Madsen (lmadsen) 2008-10-22 10:36:16 We're hoping you can test out this patch to determine if it resolves if your issue. If not, we're going to have to close this issue as suspended at the end of this week. If that happens, you can re-open the issue when you have some information to report. Thanks! By: Leif Madsen (lmadsen) 2008-11-20 16:18:24.000-0600 I'm suspending this issue because the original reporter is not responding. He can have the issue reopened when he has tested the patch and has something to report back. By: robert tang (rtang) 2011-07-15 15:45:21.821-0500 I would like to have this issue reopened. If the someone can update the patch for asterisk 1.6.2 I would be happy to test it out. By: robert tang (rtang) 2011-07-18 15:36:01.159-0500 Can someone please reopen this issue ticket? By: robert tang (rtang) 2011-07-21 11:14:48.775-0500 If no one is going to re-open this issue then I guess Freeswitch it is then. Freeswitch is much more flexible in handling these early media problems that Asterisk just can't do currently. By: Leif Madsen (lmadsen) 2011-08-30 13:34:10.433-0500 Reopening issue as requested. Please ask on the Asterisk-dev mailing list for someone to update this patch. It may not be trivial. This patch is really old. By: Matt Jordan (mjordan) 2012-04-10 14:12:19.796-0500 And I'm re-suspending it. If any one from the developer community would like to pick this up, I'll reopen it (again). If there is a genuine need for this feature, discussion on the asterisk-dev mailing list would be appreciated. By: JoshE (n8ideas) 2013-04-09 18:34:23.493-0500 Proposed patch against trunk attached. | ||||