Implement extension/device specific dial options

I'm not 100% sure I understand here but...

I'm fairly sure the 'dial' box on the devices/extensions isn't really designed to also accept dial options. For a start, if you specific 'm' in both 'dial' and the global dial options in General Settings you'd be passing duplicate options wouldn't you? Does the wiki specifically say this will work?

Caribou7, we'll look at it but a suggestion please. Don't be so indignant in your opinion of a bug vs. feature request. I'll agree that one way or another it is a bug. It is either a bug in the code, or a bug in the MANUAL. Just becaue documetation says something doesn't mean the doucumentation is always right, the bug could be there.

but thank you for the detailed description of what you have observed.

p

wozto1s wrote:

I'm fairly sure the 'dial' box on the devices/extensions isn't really designed to also accept dial options. For a start, if you specific 'm' in both 'dial' and the global dial options in General Settings you'd be passing duplicate options wouldn't you? Does the wiki specifically say this will work?

My response: No, it doesn't. But, logically, one might think that an extension-specific setting would override the general default. In other works, if a string is specified in the dial string, it should override the general setting.

BUT, this is exactly the sort of distraction I was hoping to avoid. The point is, whether it SHOULD work or not, the reality is that it DOES work as long as you don't specify an argument to the m option. And the reason the argument won't work is because something is eating the right parenthesis. THAT is the bug I'm reporting - why should something in dialparties.agi be stripping out right parens but not left ones, for example?

p_lindheimer wrote:

Caribou7, we'll look at it but a suggestion please. Don't be so indignant in your opinion of a bug vs. feature request. I'll agree that one way or another it is a bug. It is either a bug in the code, or a bug in the MANUAL. Just becaue documetation says something doesn't mean the doucumentation is always right, the bug could be there.

My response: Sorry, it's just that nearly every time I report a bug, someone changes it to a feature request and as far as I can see that's like sending it to the Black Hole of Calcutta because it's never heard from or acted upon again. To me this seems like a bona fide bug - something is stripping right parens out of dial settings and unless that's intentional behavior for some unknown reason, it shouldn't be doing that. If the right parents weren't being stripped, the feature would work.

That's why I didn't title this "dial options don't work at extension level" or something like that - THAT would have been a feature request. And while I wish that dial options were specifically supported at the extension level, I know that would be considered a feature request and would likely take months to address, if ever. So that's why I focused on the narrow issue of dialparties.agi eating the right parenthesis - I assumed that was not intended behavior and if that were fixed, it would address the problem I've discovered here, and perhaps some other issues that haven't been discovered or reported yet.

Just tried this on mine and my dial string ends up as 'ZAP/3tmtr' which i think very bad to be honest.

I hate to say this but I really do feel the bug here is that the 'dial' box should NOT allow the use '|' and a feature request be raised to correctly combine a new 'dial options' specific to a device/extension that correct merged the global options with the device options. I think we need some kind of commuity view on this before we take any action.

Regarding your comments of Feature Requests going into a black hole and never being actioned, I spent 3 hours of my own time this morning, unpaid, pain stakingly going thru every single feature request logged that is still open and marked some for inclusion in version 2.2. You have to bear in mind here everybody involved with this project is doing so in their own time and although we'd love to implement every single feature request, we have to make some tuff decision over what goes into what version.

o great, wiki managled my example :)

{{

Just tried this on mine and my dial string ends up as Executing 'Dial("Zap/2-1", "ZAP/3tmtr") in new stack' which i think very bad to be honest. }}

if this doesn't work i'm giving up :)

Executing Dial("Zap/2-1", "ZAP/3||tm||tr") in new stack

I haven't yet even gone and looked at the documentation. However - I would be of the opinion that the 'dial' option in the device settings SHOULD be limitted to ONLY the TECHNOLOGY/EXTENSION and not overloaded to provide options to the dial command. So the bug is in the documentation and the fact that this field allow the incorrect answer. (and while we are at it, we should make most of these fields be pull down menus with the allowed options.

Dial options should be placed in the genral page for now, and then when we get per extension dial options (which isn't so simple since an extension can be dialed, can do the dialing, can be dialing internal or extenal numbers, and can have conflicts between the options of other extensions being dialed), we can address this. I also don't necessarily see this that far out, as I think we should be moving more functionality into astdb (or alternative) such that more of these things can be configured in extenal portals (such as ARI) like this, follow-me settings, etc.

wozto1s, I know what it does, it uses the user-specified options and pushes the defaults to the end. I agree that's not ideal; but in my opinion it's better than not being able to do it at all, and Asterisk just ignores the extra arguments.

The feeling I get is that you and p_lindheimer feel it would be better to prevent us from having even this limited functionality rather than address the real bug, which is that something is eating the right parenthesis. I'm sorry if I sound like a broken record but I feel like everyone's avoiding even the mention of the BUG that's being reported and instead tsk-tsking about my use of the dial field in an unanticipated manner.

Yes, I'd rather see this done properly, but I have no illusions that this will be a high priority project. In the mean time I would hope you would not take away the limited functionality we have simply because you don't want to fix the right paren bug, or because you don't approve of the way I'm using the dial field, or whatever.

By the way, may I suggest an alternative in the interim? Ring Groups can play audio BEFORE ringing commences, would it be difficult to make them play a particular category of on-hold music, or a particular audio file WHILE ringing is taking place? Some people might prefer that in any case, and I could always make a ring group with one extension in it for certain extensions.

But whether that is possible or not, I still think that the right parenthesis being eaten in dialparties.agi (or wherever it's happening) is a bug, and I wish someone would address that.

Oh, and I do appreciate the hard work you guys put in. And I know you have to make decisions about feature requests. And again, that's why I tried to focus on just the bug here - fix the right paren bug and I can happily use the kludge I've found (unless you purposely make that impossible), and then it would not matter (to me, anyway) if it takes months for you to do it right. I actually thought that fixing the bug would be the easiest way to address this in the short term, but never anticipated that I'd instead be catching flak for figuring out a novel way to use the dial field. As a user I very much would NOT like drop-down boxes that limit my options. And that is all I will say about that.

I do appreciate your responses, and thank you for at least giving this some consideration and not dismissing it out of hand.

caribou7:

first off, it is a bug because it doesn't work, doesn't appear to ever have been intended to work in this fashion, and as a result, creates more of a support headache by allowing it to partially work (as we are dealing with hear). It's not personal.

second - you are always free to do you own thing, modify your own code, or if really important to you, volunteer to do the modifications necessary to get user defined dial options, custom music on hold for ringgroups or follow-me settings, or what ever it is you need.

there were lots of things that weren't there that I wanted, some examples were follow-me, direct did routing at the extension level, alertinfo (distinctive rings), penalties on queues and many more. I wrote them myself and then submitted them onto freepbx to both give back as well as relieve me of porting them to new releases as they came out (as I had done all of this stuff on AMP, pre freepbx and had to port already once).

However - this bug report isn't a discussion forum. Right now no one is doing anything other than capturing our thoughts around this bug report as there are more useful bugs to fix that need attention.

OK...here's what I'll personally commit to do for version 2.2 unless there is a strong feeling that my idea is wrong....

* Restrict the 'dial' box to just the actual type/identifier for the dial command * Provide an extension/device specific 'dialoptions' box * Write a generic function to merge together global options with the a set of specific (could be used for devices/extensions/trunks/etc.) * Make changes to the 'dial' macro to use the above to merge together the global dial options with the specific options

X-Rob:

yes - but first, let's make sure it fits within the architecture (astdb if we go that route) that will allow it to be dynamically changed in a portal like I keep harping on elsewhere.

also - let's give it the appropriate priority, just because there is a lot of noise on this topic doesn't mean it is more (or less) important than other things we should do.

Lets discuss how the following scenarios will be handled:

1. User/Extension 100 calls User/Extension 200, both have conflicting dial options. (and there are probably scenarios where there would be appropriate options from both settings that apply.
2. User/Extension 100 calls an outside line, and wants different options for that scenario.
3. User/Extension receives calls from an outside line and wants different options than receiving internal calls.
4. User/Extension receives calls but uses follow-me settings or call-forwarding, and wants their receive options to be set according to their options on the original number called. (and this can be from outside or from internal calls)

As you can see, it needs some serious thought. (examples of options for a receiving party may be ability to transfer. examples of conflicting options may be who wins on ability to do call recording if one wants it and one does not? and so forth).

wozto1s - thank you, sounds like a plan to me (although I still have mixed feelings about you changing this from a bug to a feature request, because I really do feel that eating the right parens is a bug, and everybody here is addressing every peripheral issue except the bug I actually reported - still, if I'm able to accomplish what I really wanted to do in the first place, I'll be happy, and I think your plan will ultimately help many others also).

p_lindheimer - since, as you say, this isn't a discussion forum, I will just say that if I was able to modify the code myself I would have done it - please remember that not everyone who uses FreePBX has the ability to be a developer. However I will also just add that one thing that perhaps needs to happen is for some published documentation to be released explaining FreePBX modules, how they fit in with each other and how to make changes in them and submit the updates. This is something the FreePBX developers all seem to inherently know how to do but it a totally mysterious thing to those coming into this relatively late, such as myself. I could say a lot more about that, but this definitely isn't the place for it.

p_lindheimer, I don't fully understand your comment to X-Rob (in part because he hasn't posted anything here) - anyway, here's my take on your four scenarios:

1. User/Extension 100 calls User/Extension 200, both have conflicting dial options. (and there are probably scenarios where there would be appropriate options from both settings that apply.

I was of the impression that the options related to ringing apply to incoming calls only - so in the case of options that affect ringing tone, the called party's options would apply (again, however, this sort of confusion is why I'd hoped someone would just fix the right paren bug - I fear this will get bogged down in doubt and uncertainty and nothing will happen, particularly since you seem to feel this is a low priority item).

2. User/Extension 100 calls an outside line, and wants different options for that scenario.

And why would they want that? But okay, assuming that is a possibility, have one set of dial options to be applied to inside calls and another to outside calls. Another possibility would be to divide things up along the lines of the way you do trunks - even though everything may go in the same context eventually, you divide them up initially so you can determine which items apply in which situations. So I suppose you COULD do something similar with dial options - have one set that applies to outgoing calls, one to incoming calls from other extensions, and one to incoming calls from "outside." Personally I would have no need for that level of complexity, though, and again I fear that if this is set as the initial goal nothing will ever happen. Baby steps, as they say (and please note that my original report had absolutely NOTHING to do with the scenario envisioned by this point).

3. User/Extension receives calls from an outside line and wants different options than receiving internal calls.

See above.

4. User/Extension receives calls but uses follow-me settings or call-forwarding, and wants their receive options to be set according to their options on the original number called. (and this can be from outside or from internal calls)

Now you've pretty much lost me. However my question would be, do you worry about this level of complexity for every additional feature implemented in FreePBX? I would personally ASSUME that the settings for ringing would only apply when that extension is rung directly, no matter how the call arrived there In other words, if I want to play "Beethoven's Fifth" to callers while my phone is ringing, I don't much care if they called me directly, or the call was forwarded to me, or it came from another extension or from "outside."

In other words I think you're worrying about all sorts of additional complications that really would not be an issue for most users. But maybe I'm wrong about that.

caribou7:

it isnt' a disucssion forum but... Yes documentation would be nice (maybe you could help with some of that? - as you correclty observed, developers hate writing documentation) I was not an original developer, nor part of the original freepbx role out. I also had to figure it out on my own.

another note - I see other very active users who have taken the plunge into trying to do some developement even though they don't have any background. If it's something that you really want, go for it - give it a try. You'll be amazed at what you can eventually accomplish and learning new stuff is always a good thing...

caribou7:

on your comments to my above scenarios. You are right for options like music on hold it is more straight forward. For options like enabling call recording, call transfer and such, there is ambiguity. It is not a matter of making it complicated. It is a matter of exposing the scenarios and then making some decisions. As far as the follow-me example, you can think of follow-me as my virtual incoming settings. If I have enabled on demand recording ability, I would like that feature to follow-me (whether I am answering on an internal or external number).

Example: I purposely added a second option in General for DIAL_OTPIONS applied to dialout-trunk (TRUNK_OPTIONS) instead of sticking DIAL_OPTIONS into dialout-trunk and using the same. Why? because you may not want to give and outside called party the ability to transfer calls, or enable recording on demand, however you may want to allow an internally called party to do this. You have the same issues with inside called parties.

p

p_lindheimer: I see your point about the other options. Well, as I said, you could always allow the specification of three different sets of dial options:

- Options to be used on internal incoming calls

- Options to be used on external incoming calls

- options to be used on outgoing calls

And maybe one or two more?

- Options to be used on incoming calls forwarded to another extension

- Options to be used on incoming calls forwarded to an external location

Would that just about cover everything? This is already way more complex than anything I envisioned but I'm just trying to think about how the desired flexibility to cover all situations could be implemented.

I don't have the time to read through this whole thread. The ")" being stripped off the end WAS a bug in phpagi.php which has been fixed in 2.2 (can't recall the version but it is in rc1 and beyond, and should be in 2.1 branch if I remembered to put it there). The discussions/opinions about what should be allowed in the technlogy dial paramter remain.

Milestone 2.2 deleted