How to monitor Dhadi channels with a BLF key and also use it to make calls?

Hello all,

I was wondering if anybody knows the solution for this.
I have an OpenVox A400P04 with 4 FXO modules and Yealink T29G handsets.

I want to program 4 DSS keys on the Yealinks to act as follows:

  • a) As BLF in order to see the status of those channels individually &
  • b) As line selectors (in order to press them and make a call using those channels/lines)

Note that I also have 4 prefixes programmed in the dialplan in order to route outgoing calls via each channel (81, 82, 83, 84). Those work fine if typed manually.

Note also that although the phone supports several SIP accounts I only have one per phone.

First of all, I assume the above is possible. Correct?
I am not sure how to do it however despite the search I have done around the net.

Any help is much appreciated.
K

this thread may get you half way there:

Thank you for the response.

Are you saying that

  1. The configuration cannot be done via the Freepbx GUI and
  2. That both parts of the requirement are not possible?

K

  1. Yes
  2. Not possible to my knowledge.

So what solution is given to someone who wants to both monitor state of PSTN channel and use a button to select that line? Two different buttons for a single line?

By the way I managed to do the following:

(Using one Line button):

  • Monitor the state of the channel
  • Press the button, get dialtone from landline operator and make a call via that operator.
    Note that I am using a separate SIP account for that button. That SIP account has only access to the PSTN trunk via using custom context.

Problem: The CDRs are not correct.
a) They display the hint name as destination (and not the number sent down the PSTN) &
b) The duration of the call is wrong. It shows answered from the moment it access the Dhadi channel. So even you make a missed call to someone it will still show some duration.

I have this in the extensions_custom.conf :
exten => Line1,hint,DAHDI/1
exten => Line1,1,Dial(DAHDI/1)
exten => Line1,n,Hangup

Am I close or I simply started wrong altogether?
What solution you provide to your customers who require such functionality?

Your help is much appreciated.
Thank you.

What you are trying to do is called ‘Shared Line Appearances’ (SLA, or key system). For all the things that FreePBX/Asterisk can do, SLA is one thing it can not do (at least not well). You can fudge around with this and get a partial solution, but if you truly need (want?) a key system, I doubt you will be satisfied with FreePBX. You’re thinking, ‘Now that I know what it’s called, I will just google SLA and Asterisk’, and you will find lots of hits, some of which will contradict what I just wrote, but the general advice for people who need a key system has always been to tell them they don’t need a key system. That sounds condescending, but I think it’s true, there shouldn’t be a need for users to know which lines are busy and which line they want to dial out. On a modern system, users dial digits and talk, the means of terminating the call is irrelevant.
/sermon

Two buttons or learn XML scripting (if supported by the phone) and write a phone app to do this.

This is a shortcoming of POTS lines in general and has nothing to do with the topic of this thread. There is no way to know when a remote party answers on POTS lines, so the call is considered answered from the moment of dialing, regardless if the call terminates successfully or not. If you can get busy detection working, that might solve this for that one case.

1 Like

I can’t agree more. The first thing most people who set these systems up DO NOT learn is that this is not a Key System. We’re not using bus bars. The flow of the outgoing call is intelligently designed to minimize price and maximize performance. Being worried about which line you are using (something that was important 20 years ago) just doesn’t begin to matter any more.

Go watch a rerun of the old “Lassie” TV show. The phone they used can be supported by Asterisk but why on earth would you want to?

1 Like
  1. I already had read about SLA however I noticed that FreePBX (Distro) does not even have a config file (sla.conf) in the server so I realised that even if this required for SLA to “work” it won’t be suported by the distribution and hence customisation will be required. So I left it there.

  2. You’re mentioning that “people don’t learn that this is not a key system”.
    What you probably don’t understand is that people who install a VoIP system expect -as a minimum- to have the same functionality as before with an “older” system PLUS the new benefits.
    By functionality I mean USER EXPERIENCE and not necessarily how it is achieved inside a phone or a server. This is not important to the user.
    If a -very basic- functionality is gone then it depends on the user if he/she will tell you to take “this new system” and throw it as far as possible or keep it because selection of external lines is not important.

I am very surprised by your comments that this is a 20 years old functionality. By that you mean it is not required anymore? How strange!

Check this scenario:

  • A company has SIP trunks to suppliers as well as POTS lines.
  • Company senior executives have dedicated PRIVATE POTS lines who want to share them with other staff (i.e their PAs) but with no-one other. They also want to use features like voicemail to email etc etc.
  • No one from the staff is allowed to make a phone-call via those POTS lines and in some cases the CallerIDs of those numbers are so private that only the executives and their PAs know them.

As you -hopefully- understand those POTS lines cannot be put in a pool of trunks that all staff can use without strict control.

This was just a simple and common scenario. There are also others that I can mention if you like.

To the user (or to your customer if you are an installer/supplier) makes no difference whether this is called “key system” or SLA or whatever technicians call it. They just want to continue doing what they were doing with their old system AND take advantage of the modern functionality/flexibility a voip system is supposed to offer. If they can’t have that why bother changing their system?

As for the comment about the “Lassie” TV show… try to say this to a potential buyer of a VoIP system with similar needs to the above scenario and you will see where they will send you or what they will suggest you to “do”…

Service Level Agreements are handled at the “circuit” level, same as always. SLAs are handled outside the operation of FreePBX - they are part of your network configuration. Traffic prioritization and minimum and maximum bandwidth are external to your PBX. Your routers (and not necessarily the PBX) are where those negotiations and configurations are made. Hence, it makes sense that there’s no SLA in the PBX itself.

I do understand that, perhaps better than you do. I’ve only been working with telephone and computer systems since the 1970s. What you probably don’t understand is that some functionality simply doesn’t make sense with the new framework of communications services. Monitoring individual lines (which is what you expressed a desire to do) doesn’t have a meaningful analogue in the new interface methodology. It’s an expensive and ineffective measure of system performance that’s been replaced by an entire series of other metrics that better describe the system’s health and operation.

Actually, monitoring specific lines is older than that, but it’s no longer pertinent. With the advent of SIP and volume based (rather than circuit based) service delivery, the health of a specific line on the system is no longer pertinent. When we were limited to 24 channels per T1 (or 23 on PRI), yeah, we had to keep track of how many channels were in use, but that’s different than the scenario you are describing.

Whether you understand or not, you are making my point rather eloquently. You have the basics of the technology, but it’s always within the frame of reference of PRI channels and Centrex.

You don’t have SIP trunks to suppliers. You have SIP trunks to and from your ITSP. You also have POTS lines to an ILEC or CLEC somewhere. These can be the same or different providers - that’s part of the power of the system.

The handling of the incoming calls always goes from your lines to your incoming trunks through to your incoming route processing. Unlike the old style T1 Centrex systems, a line doesn’t go to a specific phone - your trunk is processed as part of the day-to-day operation of the system. Everything comes in on a trunk. The PBX answers everything and then calls whoever needs to be notified. Note that this may well be a single instrument, but it isn’t a foregone conclusion.

So, what about your outgoing lines? They are handled either as SIP or DAHDI (POTS) calls through these self-same trunks. Your routing of the calls is no longer a function of the Centrex - it is handled intelligently by an outgoing route through a trunk. The routing of the call is handled separately from the handling of the line - it’s no longer the same thing.

The what of what you are doing is still very much an important part of the system. We all have customers that require these types of services - the difference is that we’ve explained how the old technology differs from the new and have explained why the new way is more than 100% of what they think they want. The how of how we manage those resources is the point at which there is a learning curve.

Using “user experience” as an argument is specious. The “Lassie” example above is actually quite to that point. Just because the “user experience” in the 1940s was crank the ringer dynamo and get an operator on the party line to place your call for you doesn’t mean that we should keep doing it that way. The point isn’t that you should install crank phones (or field phones, as we call them where I’ve worked), but that expecting a new technology to work identically to an older one is limiting yourself. Why would you want to keep doing things “the old way” when the new way improves nearly every facet of the user experience.

Your user wants to have a BLF that tells that their “line” is in use. Why? What does that tell you in a modern, mobile, multi-instrument environment? Is it still a meaningful metric? What does that BLF tell you? That you can’t place a call? No, because the system flexibly routes calls to the first available resource. That someone else is using their line? OK - call security. No wait, security should already be on top of that. It’s no longer a meaningful indication of anything except that one of the company’s resources is in use, and your company president should “have people” for that.

Why would anyone but corporate security care about who’s using a line? Afraid someone is going to appear to be from corporate leadership based on Caller ID? That ship has already sailed.

If the line is POTS or not can’t be the reason - POTS is an expensive, dying technology. You spend a huge proportion of your telephony budget for POTS lines, and why? What advantage does your POTS connection have? It has it’s own B+ from the phone company? Your incoming network connection can have the same level of reliability, and not suffer from signal degradation every time there’s a rainstorm.

Let’s look at your scenario:
- A company has SIP trunks to suppliers as well as POTS lines.

This is a common setup. You can do this with any mix of POTS, T1, ISDN, PRI, BRI, and SIP lines that you want. The technology and the handling of that technology isn’t something that the Senior Executives should be spending their important time on. The old standard setups still work, including the equivalent of hunt groups, failover, and a dozen other things that aren’t actually available on POTS.

- Company senior executives have dedicated PRIVATE POTS lines who want to share them with other staff (i.e their PAs) but with no-one other. They also want to use features like voicemail to email etc etc.

OK - but I don’t understand why this is an issue that has anything to do with POTS. POTS (Plain Old Telephony Services) Private lines are handled as direct, inbound numbers, same as they always have been. The system doesn’t have to process the call based on the line it came in on (although it can), it handles the call based on who got called and who is calling. How the call gets handled is a function of the PBX now. You phone doesn’t answer the call - the PBX does. It routes the call (dynamically or statically) to one or more instruments.

Now, one thing that your description alludes to, but doesn’t make clear, is whether these are incoming or outgoing calls? If the executives have private lines, they have private lines. Don’t publicize the numbers and control who can call in on them by filtering the calls based on the Caller ID of the caller. For outgoing calls, set up the instruments that can use the lines so that they are the only ones that can use the lines. For other instruments, require a dialing prefix and a PIN (like we used to do for long-distance).

Now, this is one of the places where it’s important to understand why falling on your sword to support private POTS lines doesn’t make sense. From experience, we know that each number and associated POTS line costs a minimum of (say) $45 a month (or more including taxes and fees). Inbound local calls are free (in the US) but long-distance calls are billed at some number of cents per minute (favorably in the neighborhood of $0.005. That’s before you’ve made a single call. Contrast that to a single, on-demand SIP channel. Billed at an exhorbitent per-minute rate, you are going to be spending $0.0003 a minute for outbound calls (and 1/10th that for incoming). This new “line” (plus the required $10-ish for the number and associated taxes and fees) would cost $31.68 assuming the Executive was on the phone (outbound) eight hours a day every day for the entire month.

- No one from the staff is allowed to make a phone-call via those POTS lines and in some cases the CallerIDs of those numbers are so private that only the executives and their PAs know them.

I can think of a dozen ways to do this, although I’m not sure that a company that wastes this kind of money on the personal vanity of its managers has much of a future. These lines to not “belong” to the executives. They belong to the company, which graciously allows them to use them.

Assuming the reason is the outbound Caller ID, you can configure the outbound caller ID to be whatever you want on many SIP providers. For others, any outbound caller ID that is known on your account (in other words, isn’t a “foreign” CID) can be processed using any SIP line on any trunk.

That’s not the case with POTS lines - these lines have one, and only one, Caller ID. No masking, no variation, no chance of placing a call that isn’t identified as being from that line. The problem with this certainty is that the opposite isn’t true. For any Caller ID you have to have set up on your POTS line, anyone with a modicum of experience can set up a SIP call that appears to be exactly the same. CID is no longer indicative of anything. This is why people that don’t understand telephony still think that a FAXed prescriptions are the same as an original one…

You have a dedicated POTS line for your President. That’s terrific. You can set it up so that his phone, and his phone alone can access the line. You just don’t monitor the line from a BLF anymore. You monitor his instrument or better yet instruments, which in a modern system could be any number of fixed or mobile devices. So, instead of having a dozen private numbers, he has one. It gets routed to his PA, then to him, then to his cell, or voicemail, or to another PA, or wherever you want to send it, and it gets routed with the right Caller ID for whoever is calling him.

The important part of having this bit of your scenario isn’t that he has a dedicated line (something that is actually an impediment unless he is sitting at his desk) but that he now has a flexible methodology based on his private line number for receiving calls and for his staff to filter the calls he receives.

In an outgoing scenario, if you want to change the controls on the line so that a group of people can access it, you apply PINs, or authorize those instruments to use the line. His line always uses the line (without a PIN) and everyone else uses a BLF which includes the dialing access information for his private line (which requires a PIN).

By doing away with the entire concept of a dedicated, unitary line (and its associated single point of failure) and replacing it with the most cost effective choice within a larger pool of resources, you save the company money and maximize the President’s access to calls that are placed by and destined for him.

The only reason you’ve provided that gives your argument any weight at all is “that’s the way they expect it to work.” The problem is that it’s just not simple any more. It’s more complex, more flexible, and significantly more powerful than the old way.

You are replacing a system that is already paid for - why? Because it works flawlessly? Because it’s so inexpensive to maintain? because of the abundance of spares? Because of the superior reporting and security features? I doubt that. You are replacing the system because of economic or technical pressures. With the inherent power of the new system, why on Earth would you want to have it work the way the old one did?

Everything you want to do is doable in the system. The problem is that some of the things you want to do just aren’t useful in terms of enlightening or informing your users. Your job, as the technology belly button, is to maximize the capabilities of the users of the system while minimizing the costs of doing that. If they want a Centrex system, install a Centrex, with its associated cost and inflexibility. If they want a modern, flexible, extremely powerful communication platform, help them understand why they don’t want to make that mistake.

Another way to look at this is

If you have ONLY dahdi FXO/FXS technology, than you can achieve what you wish totally within dahdi.conf for the channel driver mappings and Asterisk’s sla.conf for the “Shared Line Appearance” (not Service Level Agreement in this case) , BLF’s, multiple phones ringing, transfers, bridged calls,voice mail and all,there will be no need for for FreePBX. You van map endpoints to the sla.conf, but you will need multple extensions on each SIP phone each one to be consider single channel although call waiting should work. The limits of course are the same on your old Key-System as to your 4x8 or 32x128 limits and the number of buttons you have on each phone.

The PBX in FreePBX stands for “Private Branch eXchange” but even “20 years ago” you had to choose between a Key-Swich solution like a Samsung or Panasonic, or a PBX like Mitel/Nortel/Lucent . . . even with those technologies you had to go through hoops to emuate a key system and lose a lot of function at the same time.

About 10 years ago asterisk kind-of gave up on SLA implimentation because it was just too hard to make SIP trunks and phones and all their advantages map correctly to a phonecall per channel concept.

So I guess, as previously noted, either reeducate your users, or rely on “10 year old” legacy asterisk functionality and abandon any PBX ideas.

Also as a further note , your old analog lines have an immutable DID associated with them that you have to map into Asterisk, your digitalor analog DID trunks would not have that “Channel Associative” mapping but again dahdi.conf has that covered. (they DO NOT have a CallerID in anyway associated)

1 Like