Vodia PBX

Yes this is something that we are trying to resolve as well... It is mostly false alarm. Please ignore it for now.

You can find some additional information on http://www.vodia.com/documentation/pnp_snom especially about the question how the phone is supposed to find the PBX.

If your phone has still the old call logs, it could be that it matches the old SIP URI and then overrides the display-name provided by the PBX. If you can reproduce the problem, try to factory reset one of the phones that has the problem and see if that clears the history and solves the problem.

I checked this thread again and saw that you are still on version 4. Also in version 4, you need to specify the trunk outbound proxy and you may specify the inbound addresses. Nothing different here. However as far as I remember version 4 had the problem that as soon as the source matches any account in the domain, the call was accepted. That explains why your service flag is allowed to make calls in your domain. However the damage should be limited as the service plan does not have a dial plan and thus the calls will always remain in the domain. The hacker probably tries a couple if numbers, and must find out eventually that the calls do not terminate anywhere useful and give up. If the hacker finds an extension that would be able to make a call, that person has to guess the password. If the passwords are not trivial (e.g. account number = password), then the system is still safe. We have changed that in version 5, so that only extensions or trunks can make calls.

The PBX needs to find out where the call comes from. It does that by going through a couple of rules (see http://wiki.snomone.com/index.php?title=Inbound_Calls). When the PBX says "Received incoming call without trunk information and user has not been found" it was not able to match the SIP request to any of the provided IP addresses in any trunk. I guess you need to double check the source IP of the request coming from the Asterisk server.

Let me clarify something that might is causing some confusion. When you choose "try loopback" in the dial plan and the PBX has a number that matches the destination, it will send the request on the loopback interface of the system (typically 127.0.0.1 or ::1). In this case you still need to have a inbound trunk that takes traffic from 127.0.0.1 or ::1 (explicitly specify the address in the trunk). The loopback detection is about detecting calls that have the same call-ID. It does not matter if the "loop" goes through the loopback interface of the PBX or through an external proxy. If you are using an external proxy you can use a gateway trunk to tell the PBX that the traffic from the proxy IP address should be landing on the trunk. It is right now difficult for me (Christmas travelling) to try the loopback trunk setup. We probably have to do this after the holidays. 5.1.3 does change a couple of things in the routing. I would not say it broke something; it probably fixed a bug that was previously allowing calls to happen that should not happen .

Das snom m9 wird mit Plug and Play unterstützt. Aber es gehen auch andere Gerate, z.B. Gigaset oder Panasonic. Da bei DECT Funktionen wie BLF sowieso nicht unterstützt werden, reicht im Prinzip der Basic-SIP Standard aus.

If you are using snom phones with 8.7.3.25 (which is the default for 5.1.3), you might experience SCPP-5306: no ring tone being played on incoming calls intermittently (only visual indication). We have not experienced this issue personally yet, but it seems that this problem is a problem with the snom firmware.

Tell the PBX where the trunk traffic comes from. This is done by specifying an outbound proxy and/or listing the IP addresses where trunk traffic comes from. It should be really easy to do that. If you have JavaScript enabled on your system, the web browser will actually warn you if you don't have a outbound proxy set up.

Schwieriges Problem... Pickup wird über ein Sternchen-Code gestartet. Das Telefon ist sich ja gar nicht bewußt dass es sich um ein Pickup handelt. Die Listen werden lokal auf dem Telefon gespeichert, was nicht besonders elegant ist. Was man bräuchte wäre eine Subscription ähnlich wie Message-Waiting, wo der Server dem Telefon die Historie mitteilt. Aber es findet sich im SIP-Standard der immerhin inzwischen tausende Seiten enthält nichts über Anruflisten. Wir hatten mal Anruflisten über snom XML implementiert; dabei ist das das Telefon sich aber nicht bewusst dass der Inhalt Anruflisten sind was auch nicht gut ist. Am einfachsten wäre es wenn das Telefon die Caller-ID Updates auch in der Anrufliste reflektiert. Das würde jedoch bedeuten dass die Telefone mit einer neuen Firmware gefüttert werden müssen.

Trunks are not extensions. If it absolutely normal to link trunks to specific IP addresses. Extensions can then still register from anywhere, if they have the right password. If you run your PBX on public IP, it is very important to have users pick "good" passwords. This can be enforced by the password policy in the settings on the PBX (admin level). Don't use STUN. STUN is just a hack for servers that don't have a SBC built in and it causes more problems than it helps. Just register directly to the PBX, which will automatically detect if the device needs help with NAT traversal.

It should work also with 2 MAC... Did you put a space in between them?

For lookback trunks you MUST use global names. For example, sip:+3000@domain1.com would work, while sip:3000@domain1.com does not work. It was actually a requirement also in earlier versions, but if the domain name was right it would also take it. However this method lead to a lot of problems with calls ending up in the wrong domain, which is very confusing for callers. Just give your accounts names that look like "real" telephone numbers with more than 6 digits. Then it will be a lot easier.

Explicitly specify the IP addresses from where the traffic comes from or at least set the outbound proxy for the trunk.

You will not synchronize with Outlook (which is the client), but with the server (Exchange). It works with Office 365; but it should also work if you are running your own Exchange server.

Loopback trunk calls must use global names. You must assign at least one alias name to the account that looks like a telephone number (starting with +) and they must be unique in the system. You can archive that by using a prefix per domain, for example +1777123 for domain 1 and +1777124 for domain 2 (if you are in the NANPA region). If 3 is already your domain, then just put a + in front of it; that should also work (+3000).

I wasn't even aware that Google hosts a service that offers ActiveSync.

Okay, we need to look into the call pickup and how it looks like. We have tested the inter-domain calling, at least in the lab it was working. However you must make sure that the numbers are presented in the +-notation (e.g. +16173998147).

The other calls must be parked by your extension. Then the PBX puts them into a conference.

If you have that problem, your web browser or firewall has problems with websocket. You can try www.websocket.org/echo.html to see if your setup supports websocket.

Well, as for the call pick up CDR on the phone. If you tell me how we can write the phones CDR, we could take a look at this! But the call pickup is a star code. As for the colors of the phone; I believe there is more flexibility on the phone for this now; however we are currently glad that we have a stable firmware that works well with snom ONE (if you forget about the problems with the 870 incoming calls for a second). 5.1.3 will not be the last version; we still have work do to trying to get the extension board provisioned.

You probably also have to upgrade the PBX. This is something that we have changed for 5.1.3.

Ja ich glaube jetzt ist es besser mal ein Blick auf die Anlage zu werfen.

Good question. I know that for the call button there is a dial pad. Looks like this has been forgotten in the console!!

I just provisioned a 870 and it was fine. Maybe you should first factory reset the phone? The PBX provisions not all possible settings and it could be that there are some leftovers from previous setups.