Vodia PBX

Yepp, military is always more precise! So you mean the PBX should interpret 9-5 as 09:00-17:00? Because 5 <= 9? What aboud 8-9 as in "08:00-21:00"? I am also worried about IE8. Not sure if we can do anything to make it display everything immediately. When I move the mouse over it sometimes refreshes the area below.

I would always recommend to send an email as well (additionally to the MWI) for a shared mailbox. It does not hurt. Even if she reads emails only once per day - this will be still faster. MWI on shared mailboxes are a pain. We will change this shared MWI into a true copying of the messages. That will make life a lot easier.

I don't get it... Are you waiting for the automatic flag to change? When you go to the accounts list, it reads the status of the flag and prints "clear" or "set" on the web page...

We already put a "USA 9-5 with holidays", "Canada 9-5 with holidays" and some others into the new template for the PBX on head (version 4). Future generations will be able to enjoy that! We have the "template" download category on the web page. Maybe a good opportunity to put more templates there...

Yea, it is a kind of self-protection mechanism. The 75 % is a setting and can be changed if neccessary. The closer you get to the 100 %, the more jitter you get. IMHO 75 is a reasonable value.

Eeehhhhh.... You can only hot desk on an extension; not on the cell phone. If you want the cell phone to ring, you can fork the call to the cell phone.

You can fast forward using "3"; press it multiple times to speed up. To save the message, press "9" and it will move on to the next message. Or press "7" if you want to delete the message anyway. Also consider forwarding the message in an email. The audio playback tool of your choice will probably offer you to move the mouse to fast forward or backward.

Yea, that seems to be a common problem when using the cell phone forking. Maybe we need to disable the mailbox pickup until the PBX has played back the annoucement to pick up the call plus two seconds.

I don't believe it's the PBX. 5 seconds is pretty long. Especially if there are other calls going on that have media playout going on it should never take 5 seconds to get media started. Wireshark will show the problem. Then it will be easy to see who is delaying the media playback. Hopefully there was no device that tries to be "smart" and uses STUN in order to allocate an IP address. This can take a couple of seconds. In any case, make sure nobody is messing things up with STUN.

That should be working beautifully. Do you see that the PBX sends the INVITE to a IPv6 address? Are you using DNS? Make sure that you have proper AAAA records set up... On log level 9 you can see how the PBX determines the destination address. Otherwise, make sure that the outbound proxy looks like this: "sip:[2001:db8::1234]:5060".

Hmm... Hard to say. At first glance, nothing obvious. I guess we need to test this and see if we can reproduce the problem.

How do you route between the VLANs? Remember that VLANs should have the impression that they are different LANs ("virtual LANs" ). That means you need to route between the LANs. The alternative is that you run the PBX in multiple VLANs at the same time. That means you have to assign an IP address for every VLAN. Not an easy task in Windows! I believe in Linux it is comparatively easy (if you can deal with bash). Then the PBX would have three IP addresses, in the above example maybe 192.168.2.123, 192.168.5.123 and 192.168.6.123. Auto provisioning is another tricky topic. The problem is the factory reset. When the phone gets a factory reset, it starts in VLAN 0 (no VLAN) and gets the configuration from there. The PBX will happily provide the VLAN number and then the phone will reboot and try the VLAN. Then the same PBX must be there in the same VLAN! I believe the only way to get that working is to use option 66 with two different DHCP servers in each VLAN that provides the different IP addresses of the PBX in each VLAN. In other words: Forget it. You will probably have to manually set up the VLAN on the phone and start the provisioning from there. And tell the users to stay away from factory reset.

There was a fix recently, also for version 3.4. We hope every day we can release a 3.4 image, but we are still finding things...

No, this should work. Definitevely with version 3. If the packet is sent on IPv4, the PBX will use a IPv4 identity for that. For example, if a SIP proxy would receive the SIP packet on IPv4 and then send it on IPv6, then you would have a problem. If you send it out on IPv6, then there should be no problem and you should see the IPv6 address on the SDP. What OS are you using?

I tend to agree... I would vote to keep the flags in a certain range, for example 80-89. If we have a "regular office hours", most installers will be able to change the office hours based on the (reasonable) proposal. Then we can have another service flag for "holidays", and also one or two manual service flags. I hope this plan is not being crossed by the license key. Some homework to do...

Yea, this is a tricky topic. We have to pretend that there is a phone call on the monitored extension. This is ugly in many ways; for example the Polycom phone has to believe that there is a call going on for hours, days, maybe weeks! Maybe we can add an option that pretends the phone is on a call when it is idle, but on DND...

Yea, we need to take a look at the configuration template again... It is probably just a line missing somewhere. spa_phone.txt

Speex is very nice; there is only one catch--speed. While this is no problem for a softphone running on a GHz CPU, it is for a PBX that potentially has to run ten or fifty of those calls at the same time. For example, when a user presses the hold button, the PBX has no choice but encode the music with the codec. Another example is people waiting in the ACD, there you have different annoucements; others might be in the mailbox. I know, the optimistic case is that there are only simple calls with codec pass-through. But we also must think about the cases where that is not possible. Speex is fortunately "free". Of course, we like that part! And it is good quality. We also like that part. I would say, it is only a question of time when we have it. We'll leave it then to the customer if they want to enable it or not.

The good news about the pbxnsip PBX is that you can run it virtually on anything that runs Windows, Linux, FreeBSD, MacOS or whatever. For example, we just got it working on the SheevaPlug! There you can actually do all kinds of routing, and maybe even MPLS is an option! The CS410 is just one "example" of a device that can run the PBX software. Unfortunately, the Linux there is not the latest and getting Debian applications running there is a little bit difficult. It is more for the plain doctors office or shop that wants the FXO gateway in the same box.

Cisco has so many MAC address, it is difficult to keep up! Considering that each of these addresses has 24 bits for a serial number (that's 16 million devices!) Cisco phone sales must be cranking. We'll include that MAC in the next build. Send a PM if you want to get the latest pnp.xml to try it out.

If you do that, you really turn the multicast PnP off on all PBX - otherwise they attract the snom phones like a magnet. You can then use the "manual setup" (see http://wiki.pbxnsip.com/index.php/Snom#Manual_Setup) for the phones, so that they do plug and play with the right PBX.

Did you try to monitor the hunt group using the mode "monitor extension (on phone)"?

We have to be careful that we don't drift into router topics. After enabling the NAT routing, the next things could be: Adding PPPoE Adding a firewall Adding a virus filter Adding VPN support on the WAN port Adding MPLS support on the WAN port Adding 802.1X authentication on the LAN port Adding PoE on the LAN port Obviously, if we would go this path, we would loose our focus and have a lot of half-finished features and open topics. pbxnsip is not a router company...

For example, when someone calls a hunt group then that's one call, but it might ring ten phones. Then the number of call legs is 1 + 10 = 11.

The PBX should automatically find the next available port. If a port is not connected or busy does not matter. If you include the "line" parameter in the SIP URI, then the FXO gateway will stick to the line that you provide. For example, if you use "sip:\1@\r;line=1" in the replacement, then that dial plan entry will work only on line 1. If you want to fail over to another line then you need to turn the failover on on the FXO trunk and add another line to the dial plan that uses another line. As for teh failover, it is okay to failover on 5xx codes. The dial plan then may look like this: 110 PSTN-Gateway * sip:\1@\r;line=1 120 PSTN-Gateway * sip:\1@\r;line=2