Vodia PBX

Accessing the phone is a different thing that accessing the web interface of the PBX. For the phone, you will use the username/password set in the PnP section of the domain. This is the same for all phones in the domain. Accessing the web interface of the PBX for the user will use the username and the web password for that account. This is the one that is also used for CSTA. I would not roll out any new TAPI. IMHO this is a technology of the past. Everything is now HTTP. CTI integration is massively moving this direction. In a nutshell it means using ActionURL and REST API.

You need the web password for CSTA (which TAPI is using). I am not sure if that password is provisioned into the phone. If you need it you could include a dummy setting and set it to {web-pass}.

If you have on the head office a inter office trunk with a dial plan assigned it should work. If that still does not work I would turn all logging on to 9 and make a test call. Then there must be something in the log. (Then turn the log down again).

Hmmm, you could hot desk into the extension?

If you change hunt.htm then you should do that in the server level. I totally agree this would be only a kind of last resort and we better add this to the PBX default web page. However it is not clear to me what we should add there, maybe you can try this out with the hunt group and share with us what the pattern should look like. BTW this also applies to the ACD and AA.

The thing is that when the PBX receives a call on IPv6 on SIP, it assumes that the RTP will also be on IPv6 (IMHO a reasonable assumption). What IPv6 address it advertises in the RTP depends on the routing table depends on the operating system. IPv6 usually has lots of addresses, maybe it picks the wrong one (e.g. link local when it should choose a globally routable). Anyway, a PCAP would easily show that.

Lets say your auto attendant has number 123, then you can record specific prompts with *98123*1, *98123*2 .. *98123*5.

The PBX supports "IP transcoding" for a long, long time. It should make no difference if one side uses IPv4 and the other IPv6. I would try to call the mailbox (just a single leg call) and leave a voicemail message, then try to retrieve it to make sure it was two-way audio; for both devices so that you can try to nail down where the problem is. PCAP generation should also work both for IPv4 and Ipv6 for the extension; for that it might make sense to move to the latest version so that you can benefit from that cool feature.

That is why we have the forum :-)

Ok next version will have it.

Setting the caller-ID is generally controlled by a couple of variables. You can use the following variables: f: The user-part of the From header t: The user-part of the To header F: The user-part of the original From header (as the call came in) T: The user-part of the original To header (as the call came in) g: The name of the group (e.g. hunt group) c: The current client matter code for the call You for example you could use Hello {g} {f} as an example. You could e.g. change the template for the hunt.htm and add this to the select drop down. If it generally makes sense, we can also add it to the general drop down.

So you mean if the ACD can also redirect FAX calls to a specific destination?

There is a editor called vi on that system; so you should be able to use vi /etc/ntp.conf to edit this. Check out https://ss64.com/vi.html on how to use vi. Before you do that, make a copy e.g. cp /etc/ntp.conf /etc.ntp.conf.old so that you still have the old file.

Ok, we should be close to solving this mystery. On my mini here the /etc/ntp.conf shows a line # You do need to talk to an NTP server or two (or three). server 188.40.67.131 which is actually the IP address of ntp.snom.com. Change it e.g. to pool.ntp.org and restart the PBX...

Hmm. There is no magic back door here. If you don't have the SSH password then you cannot log in... I know that in the newer versions the root password was written when you write a new admin password from the web interface. I am not sure when that feature was introduced. But maybe we get distracted by trying to get into the system by SSH. If the system was able to get the time before, it should be able to get the time now. I remember that the snom devices were shipped with a NTP server pointing to ntp.snom.com, which does not seem to work properly any more: xx:~$ ntpdate -d ntp.snom.com 14 May 07:41:01 ntpdate[6808]: ntpdate 4.2.8p4@1.3265-o Wed Apr 5 13:28:09 UTC 2017 (1) Looking for host ntp.snom.com and service ntp 188.40.67.131 reversed to hedgehog.snom.net host found : hedgehog.snom.net transmit(188.40.67.131) receive(188.40.67.131) transmit(188.40.67.131) receive(188.40.67.131) transmit(188.40.67.131) receive(188.40.67.131) transmit(188.40.67.131) receive(188.40.67.131) 188.40.67.131: Server dropped: strata too high server 188.40.67.131, port 123 stratum 16, precision -23, leap 11, trust 000 refid [188.40.67.131], delay 0.18391, dispersion 0.00903 transmitted 4, in filter 4 reference time: 00000000.00000000 Thu, Feb 7 2036 1:28:16.000 originate timestamp: dcc2c0d2.f97e6f3f Sun, May 14 2017 7:41:06.974 transmit timestamp: dcc2c0d3.b3e478bb Sun, May 14 2017 7:41:07.702 filter delay: 0.18576 0.24048 0.18391 0.23187 0.00000 0.00000 0.00000 0.00000 filter offset: -0.81079 -0.83555 -0.80983 -0.83128 0.000000 0.000000 0.000000 0.000000 delay 0.18391, dispersion 0.00903 offset -0.809833 14 May 07:41:07 ntpdate[6808]: no server suitable for synchronization found

SSH should be on the standard port. The username is "root" and the password is the password that you are using in the web interface of the PBX.

There is no battery. Did you also restart the PBX before? Anything has changed? In the newer versions the root password is the same like for the super-admin password in the web interface. Did you try that one?

What is in the PBX config file is just used to provision the phones, the PBX itself still takes the time from the OS.

I don't quite remember but at the end of the day the mini is just a Linux computer there (there is plenty information out there on how to do this on Linux computer). You might have to edit the /etc/ntp.conf file.

200 ports should be good for 50 calls: each call takes 2 x RTP and 2 x RTCP. Unless you have a very busy system this should be ok.

Is there a way you can log in through SSH? The PBX takes the time from the operating system, maybe there is a NTP server set up that does not exist any more.

What are your settings for RTP ports? Maybe you have not enough ports there. Generally speaking you should choose a range of at least a few hundred ports, or better thousand. It also helps keeping those active port numbers random, which helps reduce problems with DoS.

Hard to get rid of those links. We are now on https://vodia.com/doc ...

!AMERICAN!211!nf !NEW!225!nf !([0-9]{10})$!\1!t!3000

Wir verwenden den Content-Type application/vnd.etsi.aoc+xml, und die AOC-Daten werden als XML-Attachment übermittelt. Gibt es einen RFC wo der AOC-Header definiert wurde?