Vodia PBX

Whow. Maybe it is not the password, maybe the Cisco answeres the challenge with a different domain. "Should not happen", but you never know. Is there anything SIP-aware stuff in the loop? Maybe another firewall that wants to do you a favour (check if the packet gets modified between the phone and the PBX).

Does the phone actually download the software? What you can do is putting the software locally on the server (into the tftp directory) and then point the firmware to something like http://ip-adr:port/tftp/firmware-name.bin. And it would be important to check why the DHCP does not work. Is your Ethernet switch doing STP (spanning tree)? I heared that is a problem, consider turning it off to see if that is the problem.

That sounds like there was a problem with DNS. The PBX caches DNS entries internally, probably the DNS entry must expire first. The expiry time for this is one hour or the time to live that was returned by the DNS server.

Ouch, that sounds like a very strange packet. Can you turn on SIP logging (http://wiki.pbxnsip.com/index.php/Log_Setup#SIP_Logging) and dig out that packet?

Well, I would put two in the first stage, have the timeout one second, then put four in the second stage, have a timeout of one second and put all six in stage three, have a timeout of 28 seconds. Then the total timeout is 30 seconds.

I would perform a manual upgrade anyway (see http://wiki.pbxnsip.com/index.php/Installi...#Manual_Upgrade). Those installers are kind of black magic and IMHO only good for an initial setup.

No - this is hard coded... Unfortunately that's the way FXO works. We thought about ringing the call immediately and then send the Caller-ID when available, but that is very tricky (or impossible) in SIP, so we decided to wait until the Caller-ID is available or not.

Whow. How big is your hunt group? You probably create a burst that generates a major hickup. Consider inviting people in the hunt group in a short succesion, e.g. after one second. That will reduce the load by factor 2.

Try http://pbxnsip.com/protect/pbxctrl-rhes4-3.0.1.3012.

Can you verify that this does not happen with another phone? E.g. pick a softphone and see if you have the same effect. Otherwise, question is what firmware, transport layer (tls, udp).

I think the error was found (another thread), check out version http://pbxnsip.com/protect/pbxctrl-3.0.1.3012.exe.

Unfortunately, the PBX only adds entries to the PnP settings... Not really a reason for concern, obsolete settings are just ignored. If you don't like this mess, you can delete the files in the directory "pnp_parms" and restart the system. Then you see only the parameters that are referenced in plug and play setup. The 3.0 version suggests that you update snom to 7.1.35, so it is okay if the phone wants to retrieve the new software. Depending on the firmware version, the DHCP loop is one reason why the software upgrade makes sense...... You have to power-cycle the phones in order to fetch the latest firmware.

Well, if you don't see any DTMF in the log, that means the PBX does not process any DTMF... Do you have the SIP INVITE packet that hits the PBX (coming from the trunk)? Maybe we can see something there. Or just send my a PM with the HTTP access and we'll log on to your system and do a test call to see what's wrong.

That sounds like a DTMF problem to me. Do you see anything in the log (media, level 6) like "Received DTMF 2"?

This is probably because of the tel:-alias changes. Check if your trunks are set to "global".

No, thoso two lists have not been touched. What has been touched is the way the PBX looks at the OS to find out which interface should be used for sending a request. Especially in Linux and BSD (VPN and ipchains!) that could cause problems. Those two lists are evil anyway. I regret that we added them. It is just a support nightmare - if a customer does not have a public IP address, the ITSP must have either offer a SBC or they must have a public IP address. Period. Everything else is crazy with support and troubleshooting. Frustrating for every one. One nice day hopefully we laugh about it and just use IPv6.

Okay, please give the following image a shot: http://pbxnsip.com/cs410/update-3.0.1.3012.tgz (CS410) http://pbxnsip.com/protect/pbxctrl-3.0.1.3012.exe (Windows)

The only thing I can think of is to send an email when the status changes. Then at least the agent gets aware of the status change. Also, the 3.0 version supports AJAX in the web interface (user mode) where the admin of the queue can see who is logged in an who is logged out.

I think most SMTP servers do not require a client certificate, so I don't think that is the problem. We just need a test account then we can give it a try.

Yepp!

We are looking into this. There is a problem somewhere.

Well, this automatic invitation into the conference has a lot of problems. If you think on how probable it is that the other side really picks up. The biggest problems are redirects to cell phones and mailboxes, where the PBX has no idea if it is a real person or a machine. Then the admin has the problem that the calls need to be torn down again and so on. Muddy area... At least we can say 3.0 offers attended transfer into a conference room. That means the organizer can call people up, call the conference and then perform an attended transfer into the conference.

Currently we don't estimate the waiting time. We have the prompts ready for queue annoucements for that, but the logic is missing right now.

Treat calls to other domains just like calls to other companies. As a trunk you can use the outbound proxy "127.0.0.1" - which loops the request back to itself. Make sure that this trunk is a "global" trunk, then you need only one.

The "outbound proxy" is also the "inbound proxy" for the trunk. You should set an outbound proxy (even if you just want to receive calls) so that the PBX can tell by the IP address and the port where the call comes from. The PBX also supports DNS resolution, that means if you ahve a DNS SRV record, the PBX will access requests from any of the potential destination addresses.