Vodia PBX

Sales is able to generate such keys (at no cost).

"ASAP". We need a new firmware for the 7xx devices anyway.

Isnt there a button dropdown called "Intercom"? Maybe just try this one.

I would suggest you address the question to the snom sales team or to the management.

Well we also had cases where the multicast works in one network and then not in other networks. You have to keep in mind that multicast usually does not cross routers, and smart switeches might also be a problem. For example in the snom office there are several VLAN, and between them multicast is not working.

Dazu muss man Wireshark installieren. Ausnahme ist snom ONE mini/SoHo, wo das PCAP im Webinterface eingebaut ist.

Not sure if those settings there require a http:// in front of the IP address to form a URL.But the topic of the caller-ID update is on the action list (discussing if the from-change can be supported by the phones).

Das wäre dann so: !(8[0-9]{3}$)!\1!t! !([0-9]{3}$)!\1!t!102 Ich bezweifle allerdings das das funktioniert. Soweit ich mich erinnere, funktioniert die 8 nur wenn man über den Auto Attendant (Automatische Vermittlung) geht, d.h. der Benutzer muss in zwei Stufen wählen: Zuerst zum AA und dann von dort aus kann er 8 + 123 eintippen.

snomONE has two things: The first we call paging, which is unicast to a potentially large number of devices (e.g. snom PA1). This can be done over multicast but also with SIP calls. The second thing is called intercom, which is always 1:1 and bidirections. There is a star code for intercom (*90) that you can use for intercom (e.g. *90123), see http://wiki.snomone.com/index.php?title=Making_Calls_Codes. It is important that the extension has the permission to do this, because this feature can be offensive in offices, so the domain admin has to enable it for the extension.

Hmm. Could be a SIP routing issue, e.g. if the contact header in the INVITE contains something that cannot be routed, then the PBX cannot hang up. Actually I am not sure if the PBX treats extensions different than trunks because of the SBC that is primarily for the extensions. The PCAP would be interesting, maybe if you can send a private message with a URL it would be great to take a look at it.

What the PBX does is try to bind a UDP port periodically on a random port 0 to the provided IP address and see if that works. If it fails, it assums that the server does not have that IP address any more, and then you get the effect that the license is invalid. This algorithm makes sense to avoid that for example, someone configures the IP during the bootup of the PBX and then removes the IP later to do the same thing on another server. If the socket opening fails, I agree it does not have to mean that the IP address is really not there. It could as well be that the system is running out of sockets (which would also have consequences for the RTP traffic) or for whatever reason the OS declines opening a port on the IP address. The question is here is there anything in that CentOS installation that could keep the OS from opening another UDP socket on the IP address for the license? Anything special with IP tables? Could it happen that the IP address "disappears" for some time (e.g. because the DHCP server did not renew the lease)? Was there a remporary link loss on the interface? We might also have to talk about changing the algorithm that--if it has previously already approved the IP address--a single failure of verification should not shut the server down just like that. Maybe the PBX should at least try threee times.

Hmm. Was it bound to a MAC address or the IP address? And did that change? Very strange, indeed.

Thanks for sharing this with us.

The licensing server is for sure not high availability and we know that. Also most Internet connections are not reliable enough. That is why the PBX does not void a license because it cannot reach the server. In your case, there must be something wrong with the key, thats why I suggested we take a look at it. We have some installations where the license server provisions temporary keys every now and then, for example with 30 days duration. If the server is not able to reach the servers 30 times in a row, yea than that license would not get updated with a new one and eventually time out. But from what I read in this topic, you dont have a key like that.

Die Call-ID soll zufällig sein, das ist absolut okay. Ausserdem gibt es bei der PBX für jeden Call-Leg (auf Deutsch: Anruf-Bein haha) eine eigene Call-ID; das liegt daran dass die PBX ein B2BUA ist und das könnte hier verwirrend sein. Wenn die Firewall tatsächlich die Call-ID ändert, wird es sehr düster. Ich würde einfach mal versuchen TLS zu verwenden, dann gehen die Probleme vielleicht schon ganz schnell von selbst weg (TLS wird auch automatisch verwendet wenn man PnP macht).

We dont turn off licenses or the missing response does not disable the license. Of course it can happen that a server goes offline, then the calls (for example in the LAN) will definitevely go on. Did you get a temporary license? Maybe private message me the license key and then we can take a look what is going on here.

Das ist nicht die einzige Firewall, die "bockt" wenn sie etwas nicht versteht. Aus diesem Grund bevorzugen wir TLS, da kann die Firewall nicht mehr dazwischenfunken...

Naja, nach einer gewissen Zeit wird der Anruf ja auf die Mailbox umgeleitet. Wer direkt zur Mailbox will, kann die 8 vor die Extension hängen (z.B. 8123) dann sollte es ohne Umwege auf die Mailbox gehen.

Yea the PBX was designed to support remote SIP registrations as much as possible, including NAT, two-tier NAT, full cone, symmetrical you name it. Many gateways dont support registrations, and the other problem is how to tell the gateway which number to call (Request-URI does not work because that's fixed in the registration). Also for incoming call the PBX will believe that the call comes from a extension, not from a trunk--which might be challenging for avoiding toll fraud. I would say give it a shot; maybe it works relatively easily and then you are all set; if you run into trouble I would consider the VPN method.

Ideally, you set up a VPN between the local and the remote location; then you can just route the traffic based on a simple dial plan to the remote break out. I believe Vigor supports VPN. As soon as you introduce NAT things get tricky (but not impossible). For example, you can register a remote PSTN gateway as an extension and use the "send call to extension" entry in the dialplan to send the call to the remote PSTN as if it was an extension.

Einfach die Mailbox anrufen, und dann den PIN eingeben wenn die Ansage kommt. Wenn jemand vom Handy aus anruft kommt es darauf an wen er anruft. Wenn es ein Auto Attendant ist, kommt "die Computerstimme"; wenn er aber eine Nebenstelle direkt anruft sollte es dort einfach klingeln. Man könnte z.B. mit einem IVR Node eine Lösung basteln, so dass der Anruf indirekt auf einem AA landet.

snom is discussing internally how to proceed. There is a solution on the table, but not available yet.

It will work, however with T.38 you cannot get 100 %. If you have a burst where more than lets say 5 RTP packets get lost, you still loose the FAX (thats why they invented HTTPS-based fax). But that is okay for most customers.

No it just has a lot more buttons...

720 is coming to rescue