Vodia PBX

Maybe http://www.pbxnsip.com/download/qos.ppt is a interesting PowerPoint for you. Make sure that the broadband is reliable to transport voice, that will keep trouble away and make the customer happy.

Yes, use "sip:\*411@\r;user=phone" as replacement.

No. The user can only set up scheduled conferences where the PIN code is specifically assigned for a specific user.

Please try http://pbxnsip.com/protect/pbxctrl-rhes4-3.0.1.3018.

Well, we have two options: Make is accesible through the PnP settings of the PBX or always set it to one. Votes?

Well for that problem RFC 3326 has been invented. However, Polycom seems to support a proprietary feature called "calllist-missed". However, I quickly searched and found nothing on the topic. Maybe we just turn the local missed call lists off. I agree, having the messager that you have 323 missed calls is not very useful.

What kind of Linux flavor do you prefer?

You may have to move straight to 3.0.1.3017 (http://pbxnsip.com/protect/pbxctrl-3.0.1.3017.exe). There were a couple of problems with email servers, so I think it is better to upgrade to the above version. If you can, make a backup and give the new version a shot.

It is a global setting with the name "multiple_hot_destking" (see http://wiki.pbxnsip.com/index.php/Global_Configuration_File), not directly available through the web ínterface.

The entry in pnp.xml was missing. Take the attached one or wait for the next release. pnp.xml

No, just select "user must press enter" as region... That does not change anything.

So far the workaround is to stay away from TLS and use UDP or TCP instead. We have a new toolchain for the CS410 that should make the PBX respect the real time scheduler the right way, but we need to polish that a little bit before we can release it. That will be definitevely much better than a backport, plus the backport will loose the system management web pages that we introduced in 3.0.

Yes, these two actions are quite similar. The difference is that the 'Pretend to be busy' sends a missed call and checks for redirects, while 'Reject Call' does not redirect the call (more rigorous). I would say the first one may redirect the call to an assistant for call screening, the second one does not accept anonymous at all. I think we have to turn off cell phone forking if the call comes from the same cell phone. Will be in the next version. Oh yes, that is not good. It is not a secury problem as the caller still has to punch in the PIN, but must be corrected (next version will have it). Yea, in the case of the intercept, the PBX did set a timeout of 0 to call the cell phone in addition to calling it immediately. Will also be fixed in the next version.

If you are using a SIP trunk then there is no analog on the PBX (the PBX does not change the volume). I would try to swap out the handset, maybe there is a problem with the specific unit.

Customer happiness if first priority. So it that solves the problem move to a PC-baesd solution. Did you set the transport layer on the PnP parameters?

Aha... So if you answer the call and hang up on the SIP phone, it works fine? I would expect that. Otherwise we do have the busy tone detection problem. The PSTN side sings the "please hang up song" (AKA busy tone), and the PBX has the job of detecting it. But in that case you should be able to take the call down by clicking in hte web interface on the delete icon. It does not solve the problem, I know, but it should work and you are saving a reboot cycle. Okay, don't touch that part. For the sake of testing things out, I would suggest you pick up the phone call on the SIP phone. Then you can first hang up on the PSTN side (hear busy tone), and if the PBX does not detect the busy tone, then you can still hang up on the SIP phone. Maybe the tone sounds very silent, distorted, or maybe the carrier just says "Your cann has been disconnected. Please hang up." In that case it will be really difficult to perform an automatic hangup detection.

Maybe some problem on Ethernet layer (maybe spanning tree problems, LLDP or something with the configuration of the Ethernet switch)? Maybe something stupid like a broken cable or the default gateway or netmask not okay. Yea, I had the 7960 in mind. I would say ACK routing is so extremly basic that I would rule out firmware problems here.

Okay, but then we are talking about a completely different problem than the busy tone detection. Is the call still "up" on the PBX in the web interface? Maybe there is a problem between the SIP phone and the PBX. Did you change the port setup for the FXO gateway? Or the IP address (1.1.1.1 and 1.1.1.2 by default)? Hanging up from the PBX side was never a problem...

I would say at this point that it is better to check if TLS is being used. It is a small CPU and it seems that too much TLS encryption slows the CPU down so much that you can "hear" it. We had customers that went to UDP and that did solve a problem.

Just kidding. Next version will have it. But still it would be a good idea to check out this time zone!

Okay, do you have something that can monitor if the system stays alive? Something like logging ping? I want to make sure that the OS is alive so that we know if the hardware or the software is the problem here. Are we talking about the black box?

? If you are on an extension call, the call should be cleared when you hang up on the IP phone. Otherwise we have not a busy tone detection problem here.

It does not exist. The CS410 is only on version 3, because version 2 does not have the pages for setting the system up (IP, FXO). The voice quality actually should not be different between 2 and 3.

Did you turn the busy tone detection on? In reg_ip.htm, setting is called "Detect Busy Tone".

It is our strict company rule that we first have to visit the place for quality assurance purposes...