Summary:	ASTERISK-06104: [branch] app_dial: Privacy option 2 returns dial-status ANSWER / option_priority_jumping not respected
Reporter:	Jan-Peter Koopmann (jkoopmann)	Labels:
Date Opened:	2006-01-17 01:03:05.000-0600	Date Closed:	2006-05-24 15:20:55
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Applications/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) patch_dial_noanswer.diff ( 1) patch_dial_optionj.diff
Description:	Hi, I just started using the new privacy options that have been added with http://bugs2.digium.com/view.php?id=0752 . I personally think two things are wrong here: 1. If the callee presses 2 (which means send the caller to voicemail etc.) the dial-status still is "ANSWER". Personally I think this should be NOANSWER in order to be able to capture this correctly in the dial plan. I will attach a patch for this in a moment (patch_dial_noanswer.diff) 2. I think the priority jump option is not used at all. This was fine in 1.0.9 but is not ok in 1.2 I suppose. I will try to produce a patch for this as well, but someone should definatly take a look at that patch then. :-)
Comments:	By: Jan-Peter Koopmann (jkoopmann) 2006-01-17 01:11:49.000-0600 Please someone have a look at patch_dial_optionj.diff. ATTENTION: I am not even sure this compiles, this is just a quick shot. I simply added the corresponding status (depending on the privacy db return) and only enabled priority jumping if option_priority_jumping || ast_test_flag(&opts, OPT_PRIORITY_JUMP) is true. I hope this suffices. By: Jan-Peter Koopmann (jkoopmann) 2006-01-17 01:13:39.000-0600 I nearly forgot to mention: Yes I signed and faxed the disclaimer. :-) By: Steve Murphy (murf) 2006-01-17 09:49:25.000-0600 very good jkoopmann!! Both patches look appropriate to me, and need to be done. I've not been testing the databased options since the privacy opts were introduced, or I'd have spotted the second patch's problem... And, my scripts don't differentiate ANSWER from NOANSWER, which is probably an oversight, or I'd have spotted the first patch's problem... Good detective work, and appropriate patches. I'll apply them to my source, and give them a test, and notify of my approval in a day or so. murf By: Jan-Peter Koopmann (jkoopmann) 2006-01-18 04:52:22.000-0600 Thanks. One more thing: After recording the introduction auth-thankyou is played. While this might suffice in many cases I would prefer having something like "Thank you. We are trying to connect you now!" played. If I interpred the code correctly, auth-thankyou is played by ast_play_and_record automatically so I suppose we would need to change that as well? Is this feasable? By: Steve Murphy (murf) 2006-01-19 22:35:19.000-0600 OK, finally, I've had a chance to build this code and test it out. I've built two copys in the svn team dir:  murf/bug_6264-trunk                                      and  murf/bug_6264-1.2 because the flag stuff isn't the same between the two. In both, after the play_and_record for the caller intro, I added a call to play "vm-dialout", which says something perfect, like "please hold, while I attempt to connect your call". This may unfortunately be construed as a new feature in the 1.2 stuff, but it's easy to find and hack out. Just look for vm-dialout. Two lines. Seems to work great for me. The NOANSWER is generated; the database mode works like it should. By: Serge Vecher (serge-v) 2006-05-01 14:18:19 murf: is this ready for trunk? Perhaps it could be brought up at the next developer's meeting? By: Steve Murphy (murf) 2006-05-09 10:25:14 Sorry about the delay-- yes, we can discuss at a developer meeting; I had it up to date in my 6264 branches, but the trunk version of app_dial had some big changes recently, and I haven't gotten around to updating it. Preliminary investigation says that the bug's still there... but I really need to do some footwork and check it out. How 'bout next week? I should be able to find some time and finish my investigation by then, and get the branch back up to date and operational. I'll report more later. By: Steve Murphy (murf) 2006-05-14 00:16:45 OK, I've done the footwork. I had severe problems updating the branches team/murf/bug_6264-trunk and team/murf/bug_6264-1.2 because they fell out of automerge sometime in february, and svnmerge just couldn't do it. It was taking several hours per attempt, so I did the "svn del" thing on those two branches, and started over. Created the branches team/murf/bug_6264-trunk2 and team/murf/bug_6264-1.2try2, and folded in the patch to both. They both compile, after updating libpri on the compiling host... I did not add the playing of vm-dialout to the 1.2 branch. It's not purely a bug fix. But I did add this to the trunk. By: Joshua C. Colp (jcolp) 2006-05-24 15:01:05 Merged into both 1.2 and trunk. murf - you can get rid of your branches. Thanks! By: Serge Vecher (serge-v) 2006-05-24 15:20:55 for reference, the revisions are 1.2 r30037 and trunk r30040 murf: you should probably get rid of AEL branch too :)