Vodia PBX

This will be sufficient. I would recommend 2 GB RAM, especially if you are using Windows.

Please try 5.1. There was a bugfix in that area.

Failover bekommt man über "Verhalten wenn nicht verfügbar" hin. Wenn da irgendwas anderes als "Abbruch" steht, wird die PBX die Abarbeitung des ausgewählten Rufschema fortsetzen.

Sounds to me more like a reboot did the trick. Anyway. Never change a running system.

Workaround could be to register all those phones to the same extension and don't use the hunt group. Most SIP phones support multiple registrations.

Some devices have no valid certificate. It seems that there are good and bad devices... If you get a message like this, open the account for provisioning from the web interface. 5.1 also contains a new setting (admin/provisioning/settings) where you can set how long an extension should be open for provisioning. The default of 10 minutes was in many cases too short, especially in LAN environments where the risk of getting hacked is relatively low. Also make sure that you have the right MAC set for the extension.

Well try again now from the web interface using the XML link. Maybe the 302 error occurred because the session already timed out when you started the software update. Otherwise you will have to do a manual upgrade, which is a little bit more complicated.

That also works.

Your are right regarding the overlapping. The 408 code is being set even though the SIP registrar might still have a valid registration. I don't agree on the 100 Trying though. That message just stops the message repetition, but it not considered a message that changes the registration status itself. It would be great if the service provider as a similar feature that measures when the registration gets lost -- on their end. Maybe the whole problem then looks much less problematic and snom ONE actually sends a lot of false/early alarms.

It is the plan to add more and more GrandStream devices. The challenge is to actually have the devices in-house for testing everything out. But maybe we can just use the 1400 as template and then make incremental changes. Let me know if you can help us testing it.

At first glance this looks good. I would not use any timeouts on the Vegastream (the Ethernet connection to the Vega is not supposed to go down). But that is not the problem I guess. Next step is to dig deeper into the logs. Make sure that you have "trunks" set for logging on level 8 or 9...

One more thing that you can try. DNS is another problem zone for keeping trunks stable. We had a case recently where the DNS server was down and the trunk also because offline because of this. Can you use the IP address of the DNS name? Maybe the DNS records TTL are another complication in this game and using the IP address may help to rule this out.

302 sounds like you have an issue accessing that XML file from the mini. Can you load it from your PC? If yes, try to log in on the mini using SSH (username root, password your PBX admin password) and use wget to download the XML file. That will probably also fail. Check ifconfig, route and /etc/resolv.conf. Maybe your firewall is also blocking the mini from downloading stuff.

It is debatable what should be done when a group misses a call. Imagine you have a hunt group with 5 extensions, a customer calls, and every extension get the missed call email. Then that customer will be surprised that he gets five calls back.

In the old versions, you have to use the extended regular expressions (the Javascript is just sitting on top of that). See http://wiki.snomone.com/index.php?title=Inbound_Calls for some examples. "!([0-9]{10})$!\1!u!700" should be close (if 700 is your default and you are looking at the request-URI header).

Dazu muss man dann die leidigen ERE bemühen. Am einfachsten ist es einfach "51" in den Trunk bei "Send call to extension" einzutragen.

Put the 40 into the keep-alive time. Sorry for not being very clear... The point is that the Trying of the next message could interfere with the previous request. Hopefully if you set the interval to 40 seconds the problem is a lot less visible, if not gone completely. But I do encourage you and everybody to send an email when the trunk status changes. This is a very important sign how stable the setup us. If you don't get any warnings, you can be sure that the PBX is not missing a single beat, as it should be.

In version 5 (5.1 just released today) it is actually quite simple. If you are in the US/Canada, first of all set the country code in the domain settings to "1". In the trunk select "Routing/Redirection", then "Destination for incoming calls". Then select on the trunks "send to 10-digit DID". Source for caller-ID just leave it to Request-URI. Then make sure that your accounts have your DID names set up. For that, set the "Account number(s)" to something like "40 8123245445" if 8123245445 is the DID that should be linked with the extension 40. You can also add more than one, e.g. "40 8123245445 8123245446".

Per RFC the registrar set the registration duration, no matter what the client proposes. Probably your registrar sets it to 30 seconds, which is not unusual. 30 is actually a little unfortunate because the SIP transaction expires after 32 seconds. The setting overrides that; maybe just try to put a 40 there; that might solve your problem without having to charge your customer a fortune for the upgrade.

Automatic recording is not included in the snom ONE mini license.

My point was: The PBX might confuse which trunk it actually is; but if you use the same rules for determining the destination based on the Request-URI or on the To-header, you can still route it to the right destination. Just make the routing dependent on the Request-URI, not dependent on the trunk. That implies that the routing rules for both trunks must be the same.

You can still set passwords later. The form to set up extensions is just for the quick setup. There you don't have to pick a password any more if you decide to PnP a phone for the extension later.

Yea this is a known problem. We have added a proper solution in version 5; if you cannot upgrade the reason for the problem might help you. The problem can occur if you have a registration interval that is too short. Then the old REGISTER transaction is still in the PBX while the new one is already being sent out. That messes things up as responses for the old transaction are coming in. If you can, try making the registration longer and hopefully keep the SIP UDP ports still open on the firewall.

Just for the record, "packetrino" is not SIP complaint if it deliberately decides to throw away the line parameter that was present during the registration. But we know that such complaints are easily overheared by equipment manufacturers and don't help solving the problem . As long if both trunks are in the same domain, does it matter which trunk the PBX will pick? Usually you can set up a rule for sending the call to the right destination that applies to both trunks and then you don't have to care. You can do this by giving accounts in the domain additional names that match the numbers that are being called.

What kind of NOTIFY is it? Can you copy & paste one here?