2.7 Outgoing CID

Beta Program Issues
1

Using the new “Route CID” in FreePBX 2.7’s Outbound Rule … works great.

However, the intended purpose of extension CID’s, is to override the CID supplied in the trunk config. This does not happen when using the new Route CID feature.

I would think that either:
(a) the extension should take priority, or
(b) along with this new feature, “override” style checkbox, similar to what you’ve done with CID-routing-rules. It could be either on the Extension or Route CID side.

It probably makes more sense to set it on the route “allow to be overridden by Extension CID”, which would be checked by default to preserve the existing workflow/understanding of FreePBX methods.

2

There is another issue with the v2.7 “outbound caller id”, related to the issue I mentioned above.

When using follow-me to dial externally, the rules for CID passing are overridden by the outbound CID rules.

I can’t imagine a situation where someone sets a CID rule for a follow-me, and they would be okay with the outbound routes taking a priority. In other words, I think it’s fair to say that it should work as it did in 2.6, that the CID-passing for follow-me would override any lower-priority rules (such as outbound CID).

Combined with my earlier notice, this totals two very similar/related issues:
(1) Outbound-Rule-CID should not override the extension CID (or there should be an option to choose which is higher priority)

(2) Outbound-Rule-CID should never override follow-me CID passing, and I don’t think there is a situation where you need a checkbox to override this, at least if you apply the 80/20 logic to your systems design.

Also – Is this forum the wrong place to report this? Should I be opening a ticket or something, as well?

3

RKM,

The forum is ok to discuss this. You are right that a bit more ‘flexibility’ would be nice in the Outbound Route CID then is currently there. I put that in as a last minute effort to have something that is better than nothing for this purpose as people have wanted an outbound cid with Outbound Routes for some time.

I’ve tried to document all the limitation in the tooltip. As far as the follow-me for instance, you can always create another route just for the follow-me if you needed to. But it was a decsion that for now the outbound route cid would override the extension CIDs. If that doesn’t work for you then you will need to go back to what you had before and file the feature request changes so that when we get more time we can look at working on more flexibility. (And then a PHD program for people to learn what CID is ultimately going to pop out the end given how complex it is getting for the more casual admin in this space…).

4

Philippe,
Your explanation makes perfect sense. I definitely don’t think this issue should require added complexity, or more of your time coding.

I think there is a very simple solution, that simply involves a conscious review of how it all fits together.

In real-world situations, it’s quite unusual that you’d want the outgoing CID rule to override the preservation of Caller-ID in a follow-me situation.

Just consider the real-world “business requirements” of follow-me caller-ID preservation/settings, and any opposing reasons for overriding them. Also consider that it’s much easier to override the follow-me CID using options that already exist … than it is to override outgoing CID (again, in consideration for real-world applications rather than thinking in the academic/generic sense).

Also, as a general “intuitive” rule of thumb in development, the more -granular- rule overrides the more -general- rule. For example, take firewall rules, or group-security in operating systems. Of course there are exceptions to this thinking when there is a business need against it; however, I think you’ll find that in addition to the “intuitive” argument, the business rules also support the same conclusion.

In short, rather than doing a laborious coding upgrade, perhaps a simple rethink-and-polish would be the best avenue.

…On a separate note… You stated that I should “go back to what you had before.” To be sure I’ve explained: prior to using FreePBX, I was using Switchvox (where this has worked nicely, yet I wasn’t happy with the lack of flexibility).

I much prefer FreePBX to Switchvox and I don’t want to lose my 120 hour investment in learning/customizing/setup of my new FreePBX/Asterisk box; therefore, if there is a workaround and you can point me in the right direction, I’m eager to learn how I can go about the workaround for the time being.

However, at this point, I don’t have any inclination of what to research. For example, I can’t imagine how I’d be able to create a “separate route”, as you suggested, for passing CID on follow-me calls, when these calls match the outgoing routes.

You see, we set CID based on the area code being dialed. Therefore, to pass the follow-me CID, it would always get caught by one of the outgoing routes based on area-code being dialed. Do you have any ideas on how would I designate that it should be avoided because this is specifically a follow-me call rather than conventional call?

Is there a direction I should research to do this directly in the config files? I don’t mind getting dirty; I just can’t understand the logic to begin knowing what to research. The same goes for the extension override; I’m not sure what the logic would be.

Let me put that a different way… On the hands-on side, I get it: it would probably involve custom config files and some special context. However the high-level logic is where I’m confused; for example, how could I know whether it was follow-me v. conventional call. Same goes for the extension call-out override.

Thank you in advance,
RKM

5

Philippe,
I haven’t heard back and I was wondering what else I can do to make sure this issue makes its way to a bug-list. Should I setup some sort of formal issue in a tracker somewhere?

Alternatively, do you have any suggestions as to the basic fundamentals (I can do my own reading/searching, I’m just not even sure of the correct tech/concepts to search FOR at this point) to accomplish the workarounds, based on what I’ve explained above?

To summarize the issues once more: In the new outgoing route CID feature, it’s overriding two more granular areas that it should not, by default (because the outgoing route CID really cannot be as easily worked around as the reverse):

(1) Extension CID (extensions settings the CID and overriding the outgoing route CID)

(2) Follow-Me CID (when chosen to preserve the CID, does not, because the outgoing route overrides).

The new outgoing route CID module should simply yield to these two, which are more granular and apparently far more difficult to workaround than vice-versa (more difficult than simply creating the outgoing route CID workaround, if someone really does need the outgoing route to override the others).

6

RKM,

there is no ‘right’ way and although your logic makes sense, you will find every possible permutation that people want for the right way. As far as my comment about doing it how you were before, that was referring to the fact that this feature was not on pre-2.7.

As far as helping you understand what I mean by setting up a route to bypass it, just crate a route with an ‘access code’ that you use for follow-me settings. For example, you may be setup for normal 7/10/11 digit dialling and have routes based on area code that you want to send to your customers.

You can simply create a route with an access code of ‘9’ (or what ever you want) and not set an outbond CID on that route.

If you want to file a feature request or bug and gives your reasons, the bug tracker is the place to do it. Things get lost in the forums. The bug tracker is reviewed, especially when coming up with new releases and features.

7

no built in method. It will require additional information similar to what you requested (e.g. a checkbox or equivalent that says the outbound route CID should/should NOT override an extension CID…)

Today, the EMERGENCY CID of an extension will ultimately override EVERYTHING if the route is marked as an emergency route. So if you want to take advantage of that you could mark such routes as Emergency Routes and supply the Emergency CID for those extensions.

8

Philippe,
That’s a great approach on overriding outgoing CID for follow-me, thank you for the suggestion.

For the override when dialing out from a particular extension, there is no way to catch that extension and create a custom route in this same way, correct?

For example, I cannot create an outbound route specifically for certain extensions; therefore, the outbound route’s will override and CID associated with an extension.

In that case, if I’d like certain extensions to have different CID’s (without dialing a custom access code), what would be the best workaround in that case? I’m hoping there is somewhat of a built-in method to achieve this without resorting to custom contexts.

Thank you in advance,
RKM

9

RKM:

#4067

As soon as core get’s published and updated, it will have the option to decide whether or not the CID should override the extension. It should be published by end of day latest.

10

Philippe,
Thanks a million for this. After updating the core this morning (now on 2.7.0RC1.3) the option is available in the “Outbound Routes” UI.

However, it does not appear to work in my case.

I’ve set the CID on the extension, I’ve unchecked Override on the outbound route (also tested with this checked), and yet I’m always getting the CID of the outbound route, never the extension. Just to clarify I did reload w/all changes ;-).

While I’m on the topic of the outbound routes, I thought I would throw together a small UI suggestion for you. The current outbound routes require two lines per row, to fit the arrows, and moving from top-to-bottom is also a whole-lotta clicks. This is somewhat cumbersome and I thought I could improve upon it.

I’ve created a couple PSD’s based on a 960px layout (the most common across all development at present, and the standard for admin GUI’s), showing an alternative. The first shows the UI as it is now (although I’ve moved the CID-override to be in-line with the other options). The second is a proposed mock-up that I’ve created.

If you need help creating the XHTML for this, I can lend a hand, although to be honest, I’ve never really become too skilled at modern web design (I’m still accustomed to doing table-based layouts in conventional HTML).

Original:
http://img214.imageshack.us/img214/5181/freepbx1.png
Proposed:
http://img651.imageshack.us/img651/2276/freepbx2.png
(you’ll notice in the second image, we’re able to fit a lot more routes in the same space)

To digress to the original issue w/override… Can you reproduce this, or would you like me to send you some sort of diagnostics?

Thank you in advance!

11

as far as code suggestion, please put those into a ticket. They will get lost in the forums.

As far as reproducing the issue, I tested it before submitting an it worked fine. You can do the following for us to have a look.

Create a route without it checked. Then paste the dialplan generated for that route. (You will find the dialplan in extensions_additional.conf. Do the same for a route that has it checked. You should see the following code:

Not Checked:

[outrt-014-MyBogusRoute]
include => outrt-014-MyBogusRoute-custom
exten => _904X.,1,Noop(Macro(user-callerid): executed in outbound-allroutes PRI 1)
exten => _904X.,n,Macro(pinsets,1,1)
exten => _904X.,n,ExecIf($["${DB(AMPUSER/${AMPUSER}/outboundcid)}"="" & "${TRUNKCIDOVERRIDE}"=""],Set,TRUNKCIDOVERRIDE=2125551212)
exten => _904X.,n,Set(_NODEST=)
exten => _904X.,n,Macro(record-enable,${AMPUSER},OUT,)
exten => _904X.,n,Macro(dialout-enum,10,${EXTEN:2},,)
exten => _904X.,n,Macro(outisbusy,)

Checked:

[outrt-014-MyBogusRoute]
include => outrt-014-MyBogusRoute-custom
exten => _904X.,1,Noop(Macro(user-callerid): executed in outbound-allroutes PRI 1)
exten => _904X.,n,Macro(pinsets,1,1)
exten => _904X.,n,ExecIf($["${TRUNKCIDOVERRIDE}"=""],Set,TRUNKCIDOVERRIDE=2125551212)
exten => _904X.,n,Set(_NODEST=)
exten => _904X.,n,Macro(record-enable,${AMPUSER},OUT,)
exten => _904X.,n,Macro(dialout-enum,10,${EXTEN:2},,)
exten => _904X.,n,Macro(outisbusy,)

You can see the difference between the two nocheck(-)/checked(+):

- exten => _904X.,n,ExecIf($["${DB(AMPUSER/${AMPUSER}/outboundcid)}"="" & "${TRUNKCIDOVERRIDE}"=""],Set,TRUNKCIDOVERRIDE=2125551212)
+ exten => _904X.,n,ExecIf($["${TRUNKCIDOVERRIDE}"=""],Set,TRUNKCIDOVERRIDE=2125551212)

When not checked (don’t override extension callerid), it checks if there is no outboundcid defined for the extension ("${DB(AMPUSER/${AMPUSER}/outboundcid)}"="") where as in the other case it doesn’t care. You will also note that if there is a TRUNKCIDOVERRIDE defined elsewhere, it will not be set. (That is defined in certain Follow-Me and Ringgroup CID settings).

12

They look identical to what you’ve expected … numbers changed to protect the innocent :wink:

Checked: [outrt-014-area941] include => outrt-014-area941-custom exten => _1941NXXXXXX,1,Noop(Macro(user-callerid): executed in outbound-allroutes PRI 1) exten => _1941NXXXXXX,n,ExecIf($["${TRUNKCIDOVERRIDE}"=""],Set,TRUNKCIDOVERRIDE="Co Name" <9415551212>) exten => _1941NXXXXXX,n,Set(_NODEST=) exten => _1941NXXXXXX,n,Macro(record-enable,${AMPUSER},OUT,) exten => _1941NXXXXXX,n,Macro(dialout-trunk,2,${EXTEN},,) exten => _1941NXXXXXX,n,Macro(dialout-trunk,3,${EXTEN},,) exten => _1941NXXXXXX,n,Macro(dialout-trunk,6,${EXTEN},,) exten => _1941NXXXXXX,n,Macro(outisbusy,) exten => _941NXXXXXX,1,Noop(Macro(user-callerid): executed in outbound-allroutes PRI 1) exten => _941NXXXXXX,n,ExecIf($["${TRUNKCIDOVERRIDE}"=""],Set,TRUNKCIDOVERRIDE="Co Name" <9415551212>) exten => _941NXXXXXX,n,Set(_NODEST=) exten => _941NXXXXXX,n,Macro(record-enable,${AMPUSER},OUT,) exten => _941NXXXXXX,n,Macro(dialout-trunk,2,${EXTEN},,) exten => _941NXXXXXX,n,Macro(dialout-trunk,3,${EXTEN},,) exten => _941NXXXXXX,n,Macro(dialout-trunk,6,${EXTEN},,) exten => _941NXXXXXX,n,Macro(outisbusy,) ; end of [outrt-014-area941]

UN-checked: [outrt-015-area954] include => outrt-015-area954-custom exten => _1954NXXXXXX,1,Noop(Macro(user-callerid): executed in outbound-allroutes PRI 1) exten => _1954NXXXXXX,n,ExecIf($["${DB(AMPUSER/${AMPUSER}/outboundcid)}"="" & "${TRUNKCIDOVERRIDE}"=""],Set,TRUNKCIDOVERRIDE="Co Name" <9545551212>) exten => _1954NXXXXXX,n,Set(_NODEST=) exten => _1954NXXXXXX,n,Macro(record-enable,${AMPUSER},OUT,) exten => _1954NXXXXXX,n,Macro(dialout-trunk,2,${EXTEN},,) exten => _1954NXXXXXX,n,Macro(dialout-trunk,3,${EXTEN},,) exten => _1954NXXXXXX,n,Macro(dialout-trunk,6,${EXTEN},,) exten => _1954NXXXXXX,n,Macro(outisbusy,) exten => _954NXXXXXX,1,Noop(Macro(user-callerid): executed in outbound-allroutes PRI 1) exten => _954NXXXXXX,n,ExecIf($["${DB(AMPUSER/${AMPUSER}/outboundcid)}"="" & "${TRUNKCIDOVERRIDE}"=""],Set,TRUNKCIDOVERRIDE="Co Name" <9545551212>) exten => _954NXXXXXX,n,Set(_NODEST=) exten => _954NXXXXXX,n,Macro(record-enable,${AMPUSER},OUT,) exten => _954NXXXXXX,n,Macro(dialout-trunk,2,${EXTEN},,) exten => _954NXXXXXX,n,Macro(dialout-trunk,3,${EXTEN},,) exten => _954NXXXXXX,n,Macro(dialout-trunk,6,${EXTEN},,) exten => _954NXXXXXX,n,Macro(outisbusy,) ; end of [outrt-015-area954]

I’m going to just do a full reboot and see if anything changes, because from the looks of it, everything is setup as it should be.

13

Okay, I’ve isolated the problem!

It has to do with the formatting of the CID on the extension.

If the extension is formatted with CID in this format:

It will not work.

If it’s formatted without the text, as follows:

Then it will override as expected.

This isn’t intended functionality for some reason, is it?

UPDATE: I’ve also been able to fix the issue with overriding the CID on the Follow-Me setting.

For example, the outbound route was not allowing the override (despite the new option being UNchecked), when the Follow-Me was in “default” mode.

When the above fixed worked, I tried changing this. Sure enough, changing the CID to a fixed, static number, works fine.

In summary

  1. If the extension has the CID formatted with the text (eg “NAME” ) the “outbound route override” will not work).
  2. If the Follow-Me is set to “Default” (pass the CID of the incoming caller along) – then the “outbound route override” will not work.

Hope this is of help,
-RKM

14

File a bug please.

15

Already done (well, technically I updated the original ticket #4067) to refer to this post. I’ll create a new ticket now.

16

From what I can tell, it seems to work in 2.7.0RC1.4

You sure are quick! Thanks for everything.

17

It’s, perhaps, in the quoting,

exten => _1954NXXXXXX,n,ExecIf($["${DB(AMPUSER/${AMPUSER}/outboundcid)}"="" & "${TRUNKCIDOVERRIDE}"=""],Set,TRUNKCIDOVERRIDE="Co Name" <9545551212>)

should be (on my system)

exten => ...Set,TRUNKCIDOVERRIDE="\"Co Name\" <9545551212>")

works over here anyways.