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.
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?
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.
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?
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.
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.
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)