Vodia PBX

Ehhhh.... I would say the PSTN gateway should know which number is being called. There must be something in the gateway that should be configured in order to do this. There is nothing like an "anonymous destination"... Alternatively, you can try the pattern "!(.*)!\1!t! 25" (see the space between the two party of this pattern). Then the PBX should route the call to 25 if the pattern resolution does not come up with a match.

Incoming calls on Telco1: Set in the "Extension" field of the trunk: "!(.*)!\1!u!25!" (see http://wiki.pbxnsip.com/index.php/Inbound_Calls_on_Trunk). If your operator sends the extension in the To-header, choose "!(.*)!\1!t!25!". Outgoing calls: Create two dial plans. Make Plan1 your default dial plan for the domain (http://wiki.pbxnsip.com/index.php/Domain_Settings#Default_Dial_Plan), and assign Plan2 to the fax extension. Both plans just use the star as the pattern (no replacement) and route to the Telco1 and Telco2, respectively (see http://wiki.pbxnsip.com/index.php/Dial_Plan). If you want, you can use a pattern like 0* as a prefix for the dial plan. However, my suggestion is not to use any prefixes. Just make the numbers diallable as they are - on a cell phone you also don't use a prefix to dial a number. That makes the address book much easier and you can call back missed calls.

The trunk may use STUN to allocate a public IP address. This is very unreliable, therefore we strongly recommend not to use this feature. However, there are stupid marketing people who believe that if that feature does not show up in the datasheet the product is inferior. We all know that this is bulls*** and STUN is just creating huge support problems. When an extension registers, it should just point the outbound proxy towards the PBX. On the snom phones, you can use even use TCP (or TLS) transport layer. Just use an outbound proxy like "sip:2.3.4.5:5060;transport=tcp". Then the NAT problems should also disappear, because even crappy routers support TCP connections. Of course, do not use STUN on the phones as well.

When a user receives a new voicemail, the PBX calls the users' cell phone and reads out the new message. Of course Caller-ID is not secure. That's why you must enter a PIN e.g. if you want to go to "your" mailbox or place an outbound call. A good reason to choose a different PIN than just "1234".

It is really hard to say. The numbers in http://wiki.pbxnsip.com/index.php/Hardware_Requirements are really just a "rule of thumb". It depends on the packet length, the codec, the I/O subsystem performance, OS-related jobs like packet routing (ipchains & Co), cache size, usage of features like call barge in or call recording, and other factors. Also the performance depends a little bit on the used version, as we constantly try to improve the performance. Fortunately, the PBX has a feature that constantly measures the performance and then stops accepting new calls when it is getting into a dangerous zone.

Hmmm... I think it is sometimes hard to say if something is a bug or just a configuration problem. And even if it is a bug, it is probably still better to post it in the right forum, so that other users experiencing the same problem can search that forum first. If we make a general "bug" forum then it will be hard to find something there "IMHO".

Well, there are simplified dial plan entries available that usually do the job. I don't remember the last time when I needed regular expressions to get something done in a dial plan. See http://wiki.pbxnsip.com/index.php/Dial_Plan.

Well, can't reproduce it here. But we changed something yesterday in the OOB DTMF processing, so maybe the problem went away by itself... Try pbxctrl-2.0.4.1749.exe is you can.

First of all, if you want to turn the feature completely off, change the setting "camp_enabled" in the pbx.xml file. The camp on is only offered to internal extensions and to cell phone callers (must be somewhere on the list of the cell phones). The number must be dialable anyway, otherwise also other features like mailbox readout are not working either. I strongly recommend that you have a "default" dialplan that works without any prefixes. It is okay if you have special prefixes for special routes, but you should have always a route that works on standard numbers. For example, you need that feature for callback (*69) anyway.

All these holidays are a pain. No doubt. Maybe there is a web site that tells if "today" is a holiday in a specific region or not. Then the PBX could go there at the beginning of the day and turn the flag on or off automatically.

The PBX does what can be done. But most ITSP simply do not respect the information. SS#7 supports it, and it is a know feature in most digital systems. But today, the PSTN gateways still have a problem with it. See http://wiki.pbxnsip.com/index.php/Outbound_Calls_on_Trunk, especially the "f" flag. You might have to try out which mode (Remote-Party-ID or RFC 3325) your provider supports.

That's a good one. Seems like we need a translation for UK... But we were seriously considering recording prompts because of the different accent in UK. That would be just another reason to do it.

You mean you want that the PBX walks through a sequence of service flags and then makes a decision if one is on? Interesting idea. I guess the short-term workaround would be merging the active times into one flag and then use that one for making routing decisions.

I guess you are not using STUN on the phones? So far it seems that other installations do not have such a problem. You can do PCAP traces both from the phone and from the PBX - then it should be easy to see where the RTP gets lost.

Well technically nobody is on hold in a hunt group - it just rings. Even if there are callers agead, they get not queued. That is the job of the agent group. Once they are connected is it a regular call, that means the domain rules for MoH apply.

We have made a little MIB for the pbxnsip's available objects. Can anyone verify this? We are not even sure about the syntax, so please don't expect too much. But we want to get this thing off the table. -- -- MIB for pbxnsip PBX -- Copyright ? 2007 pbxnsip Inc. -- PBXNSIP-PBX-POLL-MIB DEFINITIONS ::= BEGIN IMPORTS enterprises FROM RFC1155-SMI OBJECT-TYPE FROM RFC-1212; pbxnsip OBJECT IDENTIFIER ::= { enterprises 25060 } poll OBJECT IDENTIFIER ::= { pbxnsip 1 } pollCallObjects OBJECT-TYPE SYNTAX INTEGER (0..2147483647) ACCESS read STATUS mandatory DESCRIPTION "The Call Objects shows the number of call objects that have been allocated inside the PBX. Note that usually there are at least two call objects for a regular call, and during call forking you might have even more. This object will give you a good overview on the internal resource usage of the PBX." DEFVAL { 0 } ::= { poll 1 } pollRegistrations OBJECT-TYPE SYNTAX INTEGER (0..2147483647) ACCESS read STATUS mandatory DESCRIPTION "The Registrations object shows how many extensions are actively registered with the PBX. This object gives you a good overview on how many active users the system has." DEFVAL { 0 } ::= { poll 2 } pollMessages OBJECT-TYPE SYNTAX INTEGER (0..2147483647) ACCESS read STATUS mandatory DESCRIPTION "The Messages object shows you how many voicemail messages the system currently has stored. Note that when you do Email-forwarding, the messages are not stored on the PBX." DEFVAL { 0 } ::= { poll 3 } pollCallAttempts OBJECT-TYPE SYNTAX INTEGER (0..2147483647) ACCESS read STATUS mandatory DESCRIPTION "The Call Attempts object is useful to measure the Busy Hour Call Attempts (BHCA) number. This number is useful when you want to see where the limits of your system are. The BHCA number is a important performance number of traditional PBX. Feel free to compare the BHCA value of your modern CPU to the value of an old-style hardware PBX." DEFVAL { 0 } ::= { poll 4 } pollSuccessfulCalls OBJECT-TYPE SYNTAX INTEGER (0..2147483647) ACCESS read STATUS mandatory DESCRIPTION "The Successful Calls object is similar to the Call Attempts, but is measure the number of successful calls. The number is increased when the call terminates. The number can be used to determine the busy hour call performance of the system. Please note that on this software PBX, not only the call establishment takes resources. The call traffic itself also causes significant traffic, especially when the CPU has to do codec translation." DEFVAL { 0 } ::= { poll 5 } pollMediaCPULoad OBJECT-TYPE SYNTAX INTEGER (0..100) ACCESS read STATUS mandatory DESCRIPTION "The Media CPU Load object show (in percent) how much time the media CPU threads spend in processing. This information is very important, because as this number approaches 100 % the jitter gets worse and the CPU eventually will not be able to process all media streams." DEFVAL { 0 } ::= { poll 6 } END

Oh, incoming? Then you can just set an alias name for the account where you want to send the call. Or use some of the extended regualr expression tricks shown on http://wiki.pbxnsip.com/index.php/Inbound_...s_the_extension. If the gateway is not sending the Caller-ID, well then the PBX cannot fix that any more.

Did you try the prefix setting for the trunk? This way, you can put something in front of the extension number. In most parts of Europe and the rest of this planet except NANPA that solves the problem.

Can you tell us what timezones that are? Ideally in the PBX timezone format... (see http://wiki.pbxnsip.com/index.php/Localization#Time_Zones). Then we will include it in the next build. It is clear that we don't have all time zones, but don't forget that we want to support multiple zones at the same time and we want to be able to automatically provision them!

We started a script collection on the Wiki. Probably some scripts can do a lot of work, e.g. this nice Password script http://wiki.pbxnsip.com/index.php/Shell_Scripts. There we should also include stuff that does other useful stuff, e.g. setting up domains automatically.

Agreed.

2.0.3 has just been moved to the "released" state. It seems to be a great improvement to the 2.0.2, although the 2.0.2 was also not bad. See the (updated) release notes at http://wiki.pbxnsip.com/index.php/Release_Notes_2.0.3. The big bullet points are T.38 fix and SRTP fix. For Linux, the great thing is the strict scheduler usage, in our day-to-day usage that made a big difference regarding jitter. In Windows, we now (again) support Windows 2000 (fingers crossed a little bit).

Well, in general you should try to avoid by all means to mix multiple-digit length extensions. Especially when they overlap. Bad: having extension 20 201 202 203. To the question: There are a few exceptions. If you have set direct destinations, they will be (of course) processed first. If there is a mailbox prefix and the first digit matches that prefix, well then the length is not being checked (ops), instead the PBX waits until there is a match. The mailbox prefix case does not work if you are using an external voicemail system, because the PBX has no idea what extensions are available there. As a rule of thumb: Use extension names starting with 2..7 and use a fixed length (= 2 or 3 digits). Use 8 as mailbox prefix. Do not use 9 as default outbound prefix (make numbers diallable as they are without any prefix).

In 2.0.4 we'll do a overhaul of the AA, including a multiple-language support that is parallel to the other options "for sales, press 1. For support, press 2. For Spanish, press 3." or so. Then we can make it also explicity selectable what callers hear as initial annoucement.

The configuration is really a black magic. That is why I would recommend to use the plug and play mechanism and set the list of watched calls. Then those calls should be visible on the phone. You can monitor CO lines as well as extensions. Make sure you have a 2.0.2 (or a 2.0.3 beta) release.