Vodia PBX

"TRUE" is not "true"... It is case sensitive.

Okay, added as OID .16. That is not so easy... Workaround: If you want to check if there is traffic on the trunk you can also use the trunk calls OID. Yes, added as OID .15.x. It will return the last registration status (e.g. 200 for "200 Ok"). See http://wiki.pbxnsip.com/index.php/SNMP. A build is available at http://pbxnsip.com/protect/pbxctrl-3.2.0.3141.exe.

Oh oh. There was a bug in OID.14.x. Please get the latest & greatest from http://pbxnsip.com/protect/pbxctrl-3.2.0.3140.exe.

Did you put the country code into the domain settings? That makes the PBX aware about the location and then it tries to be smart about the number representation.

Those files are in the audio_moh directory. Check "bi_gong1.wav" and "bi_gong2.wav".

You are close. I would use something like this http://$pbx/snom/adrbook.xml?user=$index&auth=md5("$username:$password") You also need to know the index in the users table. I know that was stupid, but at the moment that's the way it is. And of course the hash should be something more "random"...

At the moment that is the only way. The PBX is not aware of file system changes in the configuration. We are working on improvements regarding failover; but it will take some time until we have what we want...

Does the gateway give you any log? Maybe there is some dial plan missing on the gateway. Or it does not trust the IP address of the PBX. On the PBX the setup seems to be fine.

The only weird thing that I see is that the SUBSCRIBE packets for TAPI are sent twice. Maybe something "smart" on the PC that doubles the packets?

What you can do easily is register the agents phones in both locations. Having a phone number associated with the agent will easily result in loops. For example, agent A redirects all calls to agent B; who redirects all calls to C; who redirects all calls to A again. This will generate nice traffic storms, and you'll have a hard time figuring out why which agent redirected a call to which other agent. And you cannot stop them from doing this.

Nono, use .14.x, where x is the trunk number. This OID has one more digit than the other OID.

Do you find the trunk in the trunks/xxx.xml files? If the answer is yes, something went wrong with the deletion.

At the moment it is pretty much hardcoded to 240 samples per day (that is every 6 minutes). Regarding the maximum, you don't miss anything - it precisely calculates the maximum within that 6 minute window.

Okay, we added 13: Number calls (not call legs) and 14: Number of calls on a specific trunk. The trunk number must be the index of the trunk (to locate it see the XML file name in the trunks directory). For example, if the file name is 25.xml then the OID would be 1.3.6.1.4.1.25060.1.14.25. Check out http://pbxnsip.com/protect/pbxctrl-3.2.0.3138.exe for a build that has these two additional OID. Would be great if you can verify this.

Maybe it really checks the www.pbxnsip.com URL. There is no document and maybe that is a problem for ASP.NET.

I dunno understand. You need 3.2 software for that, is that what you mean?

I am not the big expert on SNMP... Is it possible to pass a string to the GET request? Then the SNMP tool could tell the PBX what trunk it is interested in. That would simplify the setup. Otherwise we would have to assign a OID to every trunk. That would not simplify the setup.

Okay, that helps. Obviously, one way to use it is to set it up to the corporate Active Directory. You don't need the PBX for that.

A difficult topic. I believe if the user agent advertizes RFC2833 (the new number is actually RFC4733) the PBX has no motivation to burn CPU resources on analyzing it. Yes, you should see "DTMF: Power:" on log level 9 (Media).

Regarding the IP address there are esentially two possibilities. The first is to use DNS SRV entries; in this case it is the SIP device's job to locate the secondary server. The second is to give the new server the same IP address; this avoids the requirement for DNS SRV. However it has the problem that this setup can easily result in an IP address conflict - espcially when the primary server restarts and the old IP address is still active (which is very probable in the case of a sudden shutdown).

Yes, that is on the list. I am sure that once that we have the feature people will try it out, have a lot of problems, they will pick up calls and nobody connectd (because someone else picked the call up), their phone bill will explode (talking to a lot of mailboxes all the time and waiting for the "1" to connect the call), cell phone mailboxes will be full, their lines will be busy all the time (because one incoming call triggers multiple outgoing calls), the QoS to the ITSP will be hell (because practically nobody has a call limitation) and so on. But if customers are demanding it, we will put it in. Just want to keep the expecation level reasonable.

Hmm. A search for "LDAP" does not return a result...

They are fine. So you are saying other emails in the domain are working fine? What version and OS are you running? I remember there was a bug in this area, maybe you just need a newer version. In version 2, the PBX will present the tel:alias number. This number is supposed to be the number than outside parties dial. The internal number can be "embedded" in other places, for example the conference name (okay, that's a workaround).

We have good experience with AudioCodes, Mediatrix, Parlay, Patton, Vegastream as seperate gateways. Also there is the AVM FritzBox if you want BRI. If you want to use PC cards, there is Sangoma and Dialogic that offer SIP-based cards. We try to keep http://wiki.pbxnsip.com/index.php/Interoperability_Pages up to date.

The problem is simply that most (all?) phones have only one storage place for MWI and the last message is stored. The workaround is to register two extensions (all phones can register the same 2nd extension), then the phone will receive the MWI on two different accounts (one private and one shared).