* You are viewing Posts Tagged ‘pbx’

Wierd Question – Give Me Your Opinion Please

Client – Not for Profit in the Middle of the Jungle/Rain Forrest

Infrastructure – Datacenter is Non Climate Controlled, Prone to Flooding, and has Sketchy Power, LAN – NEW Cabling in main Office building, Hodge Podge of DYI wiring across remaining buildings. Phones – Total of about 50
extensions. Only about 25 – 30 phones will be IP phones, 20-30 more will have to be analog due to the distance.

Analog Extensions will be on Digium TDM2400 or Sangoma A400 Cards.

Analog extensions WILL Hit a Surge Gate before the cards, and as much precaution on grounding protection and power protection is being taken as possible. The cards WILL BE PCI not PCI-e (They are being donated)

A New Dell Power-edge Server will be acquired for the PBX

HERE IS MY QUESTION….

Would you purchase a NEW TOWER Server with PCI slots to accommodate the cards,

OR

Purchase a NEW RACK MOUNT server for the PBX, and Buy/Build a Cheaper Server just for the analog extensions,


I’m torn… The ease of management of one server, or the “isolation” of analog extensions scattered through the jungle on it’s own server.

Opinions?

Reporting Utility

When CDR reporting was raised a few days ago, it prompted me to add a section on how ADTransform could be used to address the problem raised about consolidating CDR information from various divisional PBXs and producing consolidated reports.

I wrote a short Use Case article. http://www.artifact-software.com/?page_id66

I also thought about the problem of getting the configuration files into a readable format such as phone lists that could be distributed and added a second Use Case. I am only maintaining our internal PBX so reporting configurations is not a big issue but I would imagine that for someone maintaining many clients or many corporate PBXs, having a batch tool that can collect the data files, produce nice looking reports and automatically upload them to a portal might be helpful.

I would be grateful for any comments about content, format or my skill as an artist.:-)

Ron

Telecom Best Practices

OK. I’m getting out the fireproof suit because it’s coming and my hackles have been raised by a number of comments on the list of late.

Disclaimer:
No disrespect intended to the individuals of any *specific* thread. I’m a little frustrated over energy wasted on pedantic top/bottom posting crap rather than understanding the technology and industry best-practices which have been built upon for years.

I’m not against change – far from it. I’m against throwing out good work and history done by an entire industry to make telecom one of the most complex and yet stable computing environments (class 4/5 entrants from Nortel, Lucent, etc.) We should learn from and extend best practices where they do not address circumstances which weren’t available 20 years ago (or more) but not to ignore proven practices simply because the transport mechanism is now a packet instead of a circuit.

I’m not alone.

Here’s the deal with Asterisk as an Answering Machine – industry best practices.
- don’t put phones in parallel with the PBX except for the single, emergency phone next to the PBX.
- PBX’s are directors of calls. For it to direct, it must have control. For it to have control, you can’t answer some calls in parallel.
- even if it is a home/1-phone-office, the PBX accepts and directs the call to phones *behind* it. The phone rings, if you don’t answer it goes to voicemail.

If you don’t follow this practice you will have:
- timing issues with the answering of analogue phones – rings are not always consistent.
- people will pick up “just in time” and will have to compete with voicemail.
- you won’t get accurate CDR’s which means you can do proper billing reconcilliation, chargebacks or help you understand your call paths and volumes to help troubleshoot down the road. (You may not care about bill reconcilliation or chargebacks but remember – this is a PBX (aka business phone system) and that’s what business does so that’s the business model that is supported by most practices.

Just to prove I’m not too old for change and acceptance of new technology…
- If you get charged by the connect from your provider, route by DID but don’t answer it in an IVR. That way you don’t get billed.
- Once you are looking to route to a phone behind the PBX, hey – check your jabber status. Is your desktop in IDLE, you’re not there – send it to your cell phone. Oh, BTW – change the CLID on the way back out to append “H-” to the caller so you know it came redirected from the house. This helps you decide context of the caller and decide if you want to answer or *how* you will answer.

There is no reason to not have all phones behind the PBX. There is nothing mandating you to dial a 9, or similar to get an outside line. Be creative. Use internal extensions that don’t conflict with your local calling area exchanges. Then you write dialplans for the phones that will dial right away and not make you wait to timeout on the 10-digit+ dial.

There are *way* too many cool things we can do with Asterisk that worry about top/bottom posting. Let’s get back to reading docs – asterisk &
industry practices.

Fireproof suit on and buttoned up. I’m ready.

-dbc

BLF And Call-limit In 1.8

Hello

We have recently upgraded our internal PBX from 1.4 to 1.8. This made the BLF lamps on our Polycom phones stop working. After a lot of googling and a lot of testing, I have been unable to find a solution.

I did try to change the call-limit value from 4 to 1, and this actually made BLF work (noone suggested this, and what documantation I can find states that this option is deprecated). This change has other implications, however. Call waiting stops working, queues don’t offer calls if the user is in a private call etc.

We have customers that require both BLF and call waiting at the same time.


We are running Asterisk 1.8.11-cert7

I’ve made the following additions to sip.conf [general]:
callcounter=yes counteronpeer=yes (undocumented? Supposed to replace limitonpeers?)

(old relevant values, unchanged)
allowsubscribe=yes subscribecontext=blf notifyringing=yes notifyhold=yes limitonpeers=yes

I also tried may other suggestions I’ve found like placing the hints in the same context as the extensions and removing subscribecontext.

Is there something I’m missing? Is something not working correctly?

Thanks in advance, Pan

Leading Ghost 0

Hi all,

I have problems dialling out because my new telco (the previous gave no problems) tells me my PBX adds a leading 0 and that’s why I cannot dial out (but I can receive calls).

I make a small extensions.conf as a test:

exten => 666,1,Dial(DAHDI/g1/339xxxxxx)
but cannot dial out

Curious thing is that exten => 666,1,Dial(DAHDI/g1/0233xxxxxx)
and exten => 666,1,Dial(DAHDI/g1/233xxxxxx)
call the same number!!!

Line in use is a PRI.

My Asterisk version is 1.4.26.2
dahdi version: 2.2.0.2
wanpipe-3.4.6

I checked with intense pri debug and see no 0 inside frames….

How can I really be SURE Asterisk is not adding some leading zero?

Thank you.

Giorgio.