Vodia PBX

Maybe you should use as pickup code *87?

Yea I agree. Originally the intention was to keep the BLF really simple, but then more requests for different behavior came in so we split it up. Essentially, the question is if you want only to control the LED and use the button essentially as speed dial (independently on the call state) or you want that the functionality of the button with the change of the state. The problem here is that there might be ugly race conditions, for example you want to call someone, then a call comes in for that someone and you accidentily pick that call up.

Registration is not neccessarily linked with the ability to place outbound calls. This is a policy question of the provider. Such instability issues have most of the time to do with the firewall setup. Maybe the number of ports on the firewall is exhaused or for some reason it believes that the traffic from the PBX is illegal. I would start searching in this direction.

Version 4 on the PBX (like 4.2). We introduced a feature in version 4 that automatically blocks IP addresses when they sent too many requests without proper authorization. That gives you this feeling of sporadic "dead horse" behavior. If you are still running the PBX on version 3, I would suggest that you make a backup and try to move to version 4.2 (latest). There are many issues being addressed between version 3 and 4, and your problem might be one of them.

Hard to say from that log, try to get the SIP packets in the log as well. You could also try to set the registration interval on the PBX to a very short duration, at least for TCP (like 20 seconds). Maybe this helps to avoid the TCP disconnects; I agree that could be the problem. The Communication has some weired bugs like it cannot deal with Expiry times; anyhow those problems should be better visible if we can see the SIP packets. Unless you are using TLS, a PCAP trace might also be useful.

If you are using version 4, check if the IP address was automatically blacklisted (admin/settings/access) or better make sure it is whitelisted. Thats the only thing I can think of regarding "intermittent".

Well, when it comes to configuring Asterisk you ask the wrong guy!

From the PBX perspective, Asterisk acts as a PSTN gateway just like many other gateways. The only different is that the IP address is 127.0.0.1. I would specify not only the proxy address, but also list the 127.0.0.1:5090 as the inbound address. Then the PBX will know that the call came from the trunk. For inbound calls, the default destination is in the request-URI (first line of the SIP packet); you can either let Asterisk do the magic of extracting the extension number out of the number or the PBX (e.g. use something like "!0049401234([0-9]*)!\1! 40" to get the digits after the shown number or use the default 40 as the extension). Asterisk is very flexible with the presentation of headers. I would recomment to use RFC3325 (P-Asserted-Identity) for the network number and the number in the From header as the display number for outbound calls.

We could even re-write the mailbox and the auto attendant in that script language!

You need to change the file "ringtones.xml", you can do this from the web interface (admin/web page control/templates).

If you have set the country code to "1" then the number that you want to block would be 900*. This is because domestinc numbers are represented in the 10-digit format.

Well, right now you cannot tell the PBX what WAV file to play back, the only thing that you can do is to tell it what the destination number is. The only dirty workaround I can think of is to write the WAV file to the file system before returning the SOAP... Could be a bit flaky, the PBX WAV cache might become your enemy here. Even if you return a WAV file, that would not entirely solve the problem. What should the PBX do next? Wait for more DTMF? We had this idea to write some small programming language (like a small subset of Javascript) that can be used to program the behavior of the IVR node and make it a very powerful mechanism to solve all kinds of problems (talking about version 6 here). That would be the ultimate solution to any kind of problem.

Yes "automatic" does not need intervention, sometimes a little adjustments of the parameters when the PBX thinks that someone is trying to attack the system. If you know what addresses are fine, then it does not hurt to give them full access. For example, if you are running the PBX in a LAN, it is okay to give all addresses in the LAN access to the PBX (e.g. 192.168.1.x/24). This avoids false alarms, which can be annoying.

Oh no, this says "everyone is allowed". The rule goes like this: Ifyou allow an address or subnet, well then this one is allowed to access the PBX, even with floods of requests. If you disable an address, the PBX will not look at traffic from that address, even if the request looks nice and friendly. If the address is neither allowed nor disabled, then we are in "automatic" mode, which means nice requests are allowed, and floodings are stopped after a handful of invalid requests.

The PBX uses a TCP connection that transports the CSTA XML. There you have to log in first (via some CSTA message), and then the messages are sent back and forth inside the TCP (or TLS) connection. AFAIK the PBX does not support SOAP CSTA, just the "plain" CSTA. Regarding uaCSTA, in principle the PBX does not use/need that. There are exceptions for example for the redirection indication; but for stuff like calling the PBX just talks plain SIP to the end device.

We had that topic, but so far the problem was that the updating of the caller-ID is a big problem with most phones so we put it on low prio (waiting for the request to complete is not an option IMHO as it adds too much delay and unpredictable instability).

Dialog state (http://tools.ietf.org/html/rfc4235) was never supposed to be used LED on the phone. Companies like snom used it because there was just nothing else available. For example, there is nothing said in the RFC what should happen when someone actually pushes the button, even in the example where they show how a "shared line" system works (shared lines without the possiblity to seize the line). That is why we came up with the "button" package, which solves all problems when it comes to LED buttons on the phone.

Probably either the SIP ports (5060, 5061) or the HTTP ports (80, 443) or LDAP ports (389) is blocked by another service running on the same host. Use netstat to check if the ports are blocked.

What is clear that is we have to change the way we are using the CPU cores. If we can lift the restriction to have everything running on the same core, we can get 500 concurrent calls within reach, especially with new CPU available (8 cores). This will make larger installations possible (and those deals are what you want!), and also for quadcore CPU it will give customers a piece of mind that the number of concurrent calls plays no practical role. Also, it makes the licensing model, especially snom ONE blue an unbelievable good deal. Also the trunk SIP header manipulation (RFC3325 etc) must be a lot more flexible. There are so many different ways of interpreting the SIP standard; I would say practically every carrier has a different one and we must be able to deal with them without code changes. The other thing is that the cell phone support which is good already can be extended by more "cool" (productive) features. For example, it should be possible to transfer calls that have been received on the cell phone to other users on the system.

Well, dont clear the input and then hit the "save" button. This tells the PBX to have the file with an empty input. You should use the "restore default" option.

Ich würde auf jeden Fall mal 192.168.178.x white-listen (admin/settings/access), damit die PBX nicht glaubt dass das Telefon einen DoS startet. Ausserdem sollte die MAC des Telefons im Registration Tab der Extension eingetragen sein (oder ein * Sternchen irgendwo).

No so far it was not done. We are changing a couple of things in the area of cell phone twinning, and that feature might become a nice side effect of it...

Thats not 100 % correct. It allowed 5 "third party" registrations with a restricted feature set (e.g. no transfer).

Well, can you fetch those files from a standard web browser from the public Internet? It shows that the request timed out. I could not (maybe you just changed the IP address in the log above). Is the PBX running with one NIC on that public IP? Do you get IP addresses blacklisted? t could be a problem with the firewall configuration for the PBX and/or a HTTP proxy problem with the phone.

Well, it should provision the LDAP access to the PBX address book.