Vodia PBX

I agree if a SSD goes down this must be really bad. You don't have the file system full, do you? I remember in the early days of snom ONE plus, NBE was configured to write logs and never delete them...

Of course you can specify the server port. My answer was related to the sniffing; sniffing on the loopback interface can be a problem; maybe for the sake of testing, just specify an external server to see if you can grab the traffic.

Ouch. At first glance, this looks like a hardware problem. If you have some network monitoring tool, maybe just ping it every so-and-so seconds to see if there is anything wrong. Anything special about the environment like you are in the Sahara or on Northpole? Stable power, humdity? Maybe you just had back luck and got a device that was in the edge. If this proves to be a hardware problem, and you are in the warranty period you probably have to RMA the device. If you have a server sitting around, you might want to move the service to another standard PC platform, at least until the RMA device is back. I would definitively talk to the RMA guys to see how the switch-over can be made as smooth as possible. Of course: Backup, backup, backup. If the hardware should go down forever, at least make sure that you have the configuration, so that you can resume from another hardware.

Well, just map the service flag to a phone button. Then the secretary (and also others) can see when the button is on/off. When it comes on, just press it again (then for a few seconds the redirection will be on). Before going home, press it again.

Does not ring a bell for me right now... I don't think it is the header representation, that was the problem when upgrading from 4.3 to 4.5.

I the US, snom has made some devices based on the PA1. Not sure if the striker will work; PoE does not have so much "juice" AFAIK.

7.8 ms to ping something in the subnet? I would try to run a Wireshark on the call, ideally with a Ethernet port mirror from the switch (not locally on the virtual machine). Then it will be clear where the problem comes from, and it probably saves a lot of time for trying this and that.

Yes this is something that we have on the to-do list for years... Technically you can have an external application taking care about it using a HTTP URL (e.g. curl). We have already added the "bell" functionality when someone presses the door bell (which gets translated into a HTTP GET request); now we need to extend that so that the PBX does the HTTP get without external help. Should be actually pretty simple.

You can always ask sales for a 30 day trial key... The documentation for pbxnsip/Polycom is still there: http://kiwi.pbxnsip.com/index.php/Polycom

No. But the snom ONE mini is.

This is not good... I think we need to investigate what is going on here. It would be great if the phone team can provide a version that has buttons AND PnP working...

The Polycom provisioning needs to be enabled in the license key; I guess that's already the case. The provisioning templates for the Polycom devices are about two years old. While snom was taking care about snom ONE, there was obviously not much work done to keep that up to the latest; but I believe that the changes there must have been backward compatible and you can actually still use the firmware from then. NAT should be no problem, this was in a good shape for many years already.

Thanks for sharing this with us.

OMG. This is far too much trouble for just two phones. Do you have any SIP packet trace that we can look at? I know the provider is hosting it; will be difficult to get anything from there. Maybe you can get something from the phone's web interface?

So after disabling the RTCP-XR does it work now? It is very tricky to find that RTCP-XR problem, I remember it also took us days the first time to realize that equipment that does not do it would actually not just ignore it.

Right now that is not possible. However this is a good idea, and actually it would be easy to add this.

Wie man jetzt true und false übersetzt kann man debattieren... WIchtig ist halt dass im XML File der richtige Zustand ist. Wenn das Webinterface den Wert manchmal falsch wiedergibt, wissen wir wo wir schrauben müssen.

The SIP signalling looks "beautiful" as far as I can see. My worry is that the phone obviously did not receive any (valid) packet. Why the phone thinks that 1 billion packets have been sent from remote is another question (I suspect a minor glitch in the phone). Because the phone is in the same subnet like the PBX, I don't think we have the usual firewall/NAT problems. My feeling is that there is something wrong with the SRTP. Anything in the phone that hints after MAC check problems? If you can, try to use TCP transport layer for that phone; then the RTP should be unencrypted and we can rule out that SRTP is the problem.

Hmm. Klingt für mich eher nach einem Problem mit dem Webinterface. Ich würde ich da erst mal auf das Filesystem verlassen, im XML-text steht der Zustand von dem die PBX intern ausgeht (srvflags Verzeichnis).

The dial plan in snom ONE is not the same like in Asterisk. The dial plan in snom ONE has the function to tell the PBX which trunk to use after it has been decided that the call will be going out from the PBX. If you have only one trunk, then you can just use the default dial plan and that's it. Only if you want to define which number gets sent where, you need to add entries to the dial plan. The priorities are like line numbers in basic; the PBX processes them from top to bottom until it finds a match. There are two kinds of patterns. Simple and ERE (see http://wiki.snomone.com/index.php?title=Dial_Plans). Your examples would look like this pattern: xxxxx replacement: 0597* (that's a simple pattern) pattern: ^(0[1-8][0-9]*)@.* replacement * (ERE pattern) pattern: ^(003[1-4][0-9]*)@.* replacement * (ERE pattern) pattern: ^(004[1-9][0-9]*)@.* replacement * (ERE pattern)

We have this topic from time to time. For example Asterisk supports it, there is something like canreinvite=true/false/maybe and so on. The problem with that is that it is difficult to get it working (getting trunks working at all is already difficult) and we made the decision at the time to keep trunks on the SIP level really as simple as possible. I know from a architectural point of view it is madness; however keep in mind people want to be able to record calls or hit ## to get back to the dial tone (from the cell phone). Those features are extremely difficult to implement if the PBX does not stay in the media path. In addition to that, even if a SIP trunk provider seems to support it, we have made the experience that SIP trunk provider interoperability is not a static thing. It might even depend on who you are calling (next tier provider). This is something you really don't want to troubleshoot.

Oh oh. I saw the title that says that only off-net calls are affected. Then this has nothing to do with the memory size or CPU load. Sorry for sending you in the wrong direction. If internal calls are fine, then you don't have to worry about memory size or CPU load. If only off-net calls are the problem, then there must be something different or wrong with the routing. Because this is a new system essentially, you should double check if the routing table is what you would expect (route command). How many interfaces do you actually have (private/public IP). Is the VM host applying NAT to the host?

Take that out. There is no need to port forward the SIP or RTP traffic on the router.

Ops must have overlooked the name... Anyway if it is hosted you can exclude problems on the trunk side. If you use Aastra is then you must have set it up manually I guess. The main problem will be that the SIP traffic is probably done using UDP, and that is causing problems with firewalls. What firewall or router are you using? Do you see anything there with SIP/ALG in it? Turn it off when you see anything there, this is only causing trouble. If you just have two phones, why don't you buy two snom phones? There you can use automatic provisioning and encrypted traffic, so that your firewall will not be able to intercept and modify the traffic between the phone and the PBX.

512 MB RAM sounds very low to me. I guess the VM is constantly swapping. Try to increase it dramatically, just to see if that is the right parameter.