Vodia PBX

# host -t A smtp.gmail.com smtp.gmail.com is an alias for gmail-smtp-msa.l.google.com. gmail-smtp-msa.l.google.com has address 173.194.70.108 gmail-smtp-msa.l.google.com has address 173.194.70.109 smtp.gmail.com is an alias for gmail-smtp-msa.l.google.com. gmail-smtp-msa.l.google.com has IPv6 address 2001:4860:800a::6d smtp.gmail.com is an alias for gmail-smtp-msa.l.google.com. The PBX prefers IPv6... It would be great if google had a record like ipv4.smtp.google.com, but I could not find anything.

Are phone calls generally stable? *87 can of course have the problem that the call either already was picked up in another location of the caller already hung up. Especially when using analog gateways, the hangup delay can be significant so that you technically pick up the call, but you hear nothing for some time until the gateway disconnects the call.

We have seen registrations, and so far nobody (else) complained...

The username and password are stored in the settings for the domain, at the bottom. The snom phones support only one login account, therefore we had to make a decision if we provide the user credentials or the admin credentials. Central provisioning does suggest to use admin credentials, thats why we went this way.

What about just putting the IPv4 address there instead of the DNS name? That's a kind of workaround until IPv6 is available; maybe google wants to push for IPv6 and publishes the records on purpose...

You can easily use UDP for the gateway and TLS for the phones. As for the PBX, if you use a outbound proxy on the gateway trunk like 192.168.1.2:5060, it is always UDP by default (thats the RFC). No need to change that in the provisioning settings for the snom phones...

Das ist sicher eine gute Idee und schadet der PBX Funktionalität überhaupt nicht. Wie man das einstellt weiss ich allerdings nicht ...

The default for that is TLS. Did you change that for a reason? Usually, TLS is the best choice as it avoids problems like the UDP fragmentation problem and it also keep other parties from reading the traffic betwene the PBX and the phones. If you want to overrule if for certain extensions, you can do this by modifying the PnP files only for the specfic extensions.

No, the PBX does not take a look at that. So do you still see the IPv6 addresses in the log? If it all does not help, there is a option --ipv6 false when you start the PBX to disable the IPv6 functionality.

Why do you need to use VPN? snom ONE has a "mini session border controller" built-in, so that devices can also work behind NAT. Also, regarding packet fragmentation, why dont you just use TLS? If you use plug and play, the phones will have all the settings right, so you dont have to worry about details.

Well, you can configure the m9 so that all handsets are using the same identity, I think that is the core of the problem. Manually, you would assign all handsets to the same identity. Then the PBX sees only three phones, and then you can work with three registrations on the same extension. The problem remains how to transfer. We could do the trick to run the call over the trunk and then back (e.g. loopback trunk), so essentially the PBX sees that as a new call coming in. Inside the DECT device, you can use "internal call" to transfer calls from one handset to another. The alternate solution would be to assign every handset its own extension and use a hunt group that rings all of the extensions. Then we would have the problem that they would have to share a mailbox, which will make MWI a pain. I believe in residential area the user experience is not so much the hunt group, it is more like one extension. Maybe we need the check if we should add the option that calling your own number does not call the mailbox, instead it calls all other registered extensions.

Not sure how long the DNS TTL is, usually it should be only 24 hours or less; maybe they have set it to 7 days. If you want to find out, I guess you have to restart the system.

In Windows, AFAIK the default configuration prefers the NIC with the highest link speed. Maybe your traffic gets routed over the 2nd NIC by accident. First of all, you must be able to send emails out. Then you just go into the domain, then the extension and then registrations, there is a drop down where you can select to send an email when the registration changes.

LoL, seems you are a "victim" of the IPv6 day (June 6, 2012). Did you have IPv6 connectivity on that server? Hopefully the DNS cache entry expired already, and everything goes back to good old IPv4 times... Call call limit reached message is stupid, you have zero calls. We probably should just show the message when there are more than zero calls.

I guess you want to be able to send traffic to the PBX, e.g. when dialling certain numbers and you want to be able to receive traffic from it as well. If you can route packets from and to the PBX (e.g. because they are in the same LAN or because you use VPN between the locations), I would probably just use a gateway trunk and the dial plan to send certain numbers to the other PBX. You can think of the other PBX like a service provider that takes care about certain numbers, and the calls are like PSTN calls. When receiving calls, you can tweak the extended regular expression pattern list on the trunk to send the incoming call from the trunk to the right destination, again similar to what you would do with a ITSP.

You must use PnP on the phone to make the magic happen. There are a lot of settings that need to be set, and the snom ONE plug and play does it all for you.

Hmm, first thing comes to my mind: NAT involved? Cheap routers and many UDP/TCP connections? Limited bandwidth? Second, you should check if there were IP addresses automatically disabled (Admin/Access). If thats the case, explicitly allow access from those addresses (especially if they are in the LAN). There are other reasons like IP address conflicts that can cause very annoying effects. You can also use the automatics email reporting when one of the extensionbs is loosing registrations; This is a good way to see how stable the connection to the phone is, 24/7.

You mean snom ONE to snom ONE or snom ONE to another vendor? What other vendor?

Maybe you have to terminate your entry with a # (thats a question for the ATA when it detects the end of the dialled number).

That is because the cell phone user then can make another call, e.g. when driving in the car without the need to dial into the PBX again.

Vermutlich sind in diesem File die Übersetzungen drin. Einfach mal das gesamte Directory umbenennen und bei nächster Gelegenheit neustarten.

I would actually not use the IP replacement, instead use the routing list. Then you can have a list with the specific rules first and the generic rules at the end; essentially telling the PBX to overrule the OS routing table and use this table instread. With that you can usually get around such problems.

Well, there is a transfer star code (*77 for blind transfer). However, the ATA must be able to put the call on hold. Usually that can be done with a flash hook (tap the on hook key for a short time). Then you should get secondary dial tone where you can dial *77123 to transfer the call to 123.

Habe das gerade nochmal auf unserem System überprüft. Dort wird in Deutsch sinnvolle Inhalt angezeigt... Gibt es ein Directory webpages in der Working Directory der PBX, und falls ja sind da Dateien drin? Dann könnte hier das Problem liegen.

Whow that would mean that maybe even when fax transmissions are going on, failover over would not miss a beat! However, from what I heared the faoliver is in the 1000 ms area, where regular calls may stay alive but fax would end.