Vodia PBX

There is no *, but you can list the extensions one by one. If there are many extensions, you might not want to call them all at once...

Hmm, we generate XML for this model... In theory it should be the same like for the X4U model, but Fanvil sometimes comes up with completely different names for buttons. Can you send us the XML file (maybe in a private message)?

Please try the reset button for the profile (because the names have changed).

Well those variable names are cASe sEnSiTIvE. Also if you turn the logging higher (web client level 9), you will see all available variables.

Looks like the pages were indeed messed up with the X4x devices and possibly also the X5. If you can, please try the version-68.0.7.beta.xml which should fix that problem and also uses a different resolution for the background images.

Hmm on the app it should work with the 1.15 version. However on the trunk side I would not be so sure. Many trunk providers have problems with different codecs. Because of that there are various settings, e.g. answer only with one codec in the SDP answer or just set the trunk to use only one codec.

IMHO its not super critical, however I agree its confusing. Especially when there is no area code adding the "0" in front of it makes only limited sense. But IMHO it makes a lot of sense e.g. when dialing international. We'll have to look into this with the next iOS build and potentially also the other platforms.

Well computer are always right... As for the stats, there might be still some other reasons that would make it add up properly but they are not shown. Are we talking about the email or about the wallboard?

Getting that directly out of the REST API will be not straight forward. What would be an option would be to write the records into a database and then fish them out through a query.

Generally speaking, u-law and a-law are very similar and there is a lossless conversion between the codec that does not take much CPU, its just a table lookup. So it's not a big problem if the PBX has to transcode between them (transcoding between e.g. OPUS and G.711 is an entirely different story in terms of CPU and also audio quality losses). It's even possible that one direction is u-law and the other direction is a-law. As long as it sounds good, I would not worry too much about it.

Please make sure that the "Baltimore CyberTrust Root" is installed. If not, reset the certificate list on your PBX or import the following certificate as Trusted Root CA for server authentication: -----BEGIN CERTIFICATE----- MIIDdzCCAl+gAwIBAgIEAgAAuTANBgkqhkiG9w0BAQUFADBaMQswCQYDVQQGEwJJ RTESMBAGA1UEChMJQmFsdGltb3JlMRMwEQYDVQQLEwpDeWJlclRydXN0MSIwIAYD VQQDExlCYWx0aW1vcmUgQ3liZXJUcnVzdCBSb290MB4XDTAwMDUxMjE4NDYwMFoX DTI1MDUxMjIzNTkwMFowWjELMAkGA1UEBhMCSUUxEjAQBgNVBAoTCUJhbHRpbW9y ZTETMBEGA1UECxMKQ3liZXJUcnVzdDEiMCAGA1UEAxMZQmFsdGltb3JlIEN5YmVy VHJ1c3QgUm9vdDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKMEuyKr mD1X6CZymrV51Cni4eiVgLGw41uOKymaZN+hXe2wCQVt2yguzmKiYv60iNoS6zjr IZ3AQSsBUnuId9Mcj8e6uYi1agnnc+gRQKfRzMpijS3ljwumUNKoUMMo6vWrJYeK mpYcqWe4PwzV9/lSEy/CG9VwcPCPwBLKBsua4dnKM3p31vjsufFoREJIE9LAwqSu XmD+tqYF/LTdB1kC1FkYmGP1pWPgkAx9XbIGevOF6uvUA65ehD5f/xXtabz5OTZy dc93Uk3zyZAsuT3lySNTPx8kmCFcB5kpvcY67Oduhjprl3RjM71oGDHweI12v/ye jl0qhqdNkNwnGjkCAwEAAaNFMEMwHQYDVR0OBBYEFOWdWTCCR1jMrPoIVDaGezq1 BE3wMBIGA1UdEwEB/wQIMAYBAf8CAQMwDgYDVR0PAQH/BAQDAgEGMA0GCSqGSIb3 DQEBBQUAA4IBAQCFDF2O5G9RaEIFoN27TyclhAO992T9Ldcw46QQF+vaKSm2eT92 9hkTI7gQCvlYpNRhcL0EYWoSihfVCr3FvDB81ukMJY2GQE/szKN+OMY3EU/t3Wgx jkzSswF07r51XgdIGn9w/xZchMB5hbgF/X++ZRGjD8ACtPhSNzkE1akxehi/oCr0 Epn3o0WC4zxe9Z2etciefC7IpJ5OCBRLbf1wbWsaY71k5h+3zvDyny67G7fyUIhz ksLi4xaNmjICq44Y3ekQEe5+NauQrz4wlHrQMz2nZQ/1/I6eYs9HRCwBXbsdtTLS R9I4LtD+gdwyah617jzV/OeBHRnDJELqYzmp -----END CERTIFICATE-----

Use an outbound proxy like sip:provider:5060;transport=tcp. The PBX follows RFC3263.

Short answer: No. Little bit longer answer: Vodia is using its own internal logging mechanism for most log messages, which end up internally in memory or are written to the working directory of the PBX. There are some messages that are logged through syslog(3) however all of those messages do not take any input that could be controlled from the outside, for example Starting up or Administrator password changed from 192.168.1.2.

This would be "Trusted Root CA for server authentication".

Its usually because the PBX does not trust the new LetsEncrypt root CA. You can try to import the following Root CA into the PBX: -----BEGIN CERTIFICATE----- MIIFazCCA1OgAwIBAgIRAIIQz7DSQONZRGPgu2OCiwAwDQYJKoZIhvcNAQELBQAw TzELMAkGA1UEBhMCVVMxKTAnBgNVBAoTIEludGVybmV0IFNlY3VyaXR5IFJlc2Vh cmNoIEdyb3VwMRUwEwYDVQQDEwxJU1JHIFJvb3QgWDEwHhcNMTUwNjA0MTEwNDM4 WhcNMzUwNjA0MTEwNDM4WjBPMQswCQYDVQQGEwJVUzEpMCcGA1UEChMgSW50ZXJu ZXQgU2VjdXJpdHkgUmVzZWFyY2ggR3JvdXAxFTATBgNVBAMTDElTUkcgUm9vdCBY MTCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAK3oJHP0FDfzm54rVygc h77ct984kIxuPOZXoHj3dcKi/vVqbvYATyjb3miGbESTtrFj/RQSa78f0uoxmyF+ 0TM8ukj13Xnfs7j/EvEhmkvBioZxaUpmZmyPfjxwv60pIgbz5MDmgK7iS4+3mX6U A5/TR5d8mUgjU+g4rk8Kb4Mu0UlXjIB0ttov0DiNewNwIRt18jA8+o+u3dpjq+sW T8KOEUt+zwvo/7V3LvSye0rgTBIlDHCNAymg4VMk7BPZ7hm/ELNKjD+Jo2FR3qyH B5T0Y3HsLuJvW5iB4YlcNHlsdu87kGJ55tukmi8mxdAQ4Q7e2RCOFvu396j3x+UC B5iPNgiV5+I3lg02dZ77DnKxHZu8A/lJBdiB3QW0KtZB6awBdpUKD9jf1b0SHzUv KBds0pjBqAlkd25HN7rOrFleaJ1/ctaJxQZBKT5ZPt0m9STJEadao0xAH0ahmbWn OlFuhjuefXKnEgV4We0+UXgVCwOPjdAvBbI+e0ocS3MFEvzG6uBQE3xDk3SzynTn jh8BCNAw1FtxNrQHusEwMFxIt4I7mKZ9YIqioymCzLq9gwQbooMDQaHWBfEbwrbw qHyGO0aoSCqI3Haadr8faqU9GY/rOPNk3sgrDQoo//fb4hVC1CLQJ13hef4Y53CI rU7m2Ys6xt0nUW7/vGT1M0NPAgMBAAGjQjBAMA4GA1UdDwEB/wQEAwIBBjAPBgNV HRMBAf8EBTADAQH/MB0GA1UdDgQWBBR5tFnme7bl5AFzgAiIyBpY9umbbjANBgkq hkiG9w0BAQsFAAOCAgEAVR9YqbyyqFDQDLHYGmkgJykIrGF1XIpu+ILlaS/V9lZL ubhzEFnTIZd+50xx+7LSYK05qAvqFyFWhfFQDlnrzuBZ6brJFe+GnY+EgPbk6ZGQ 3BebYhtF8GaV0nxvwuo77x/Py9auJ/GpsMiu/X1+mvoiBOv/2X/qkSsisRcOj/KK NFtY2PwByVS5uCbMiogziUwthDyC3+6WVwW6LLv3xLfHTjuCvjHIInNzktHCgKQ5 ORAzI4JMPJ+GslWYHb4phowim57iaztXOoJwTdwJx4nLCgdNbOhdjsnvzqvHu7Ur TkXWStAmzOVyyghqpZXjFaH3pO3JLF+l+/+sKAIuvtd7u+Nxe5AW0wdeRlN8NwdC jNPElpzVmbUq4JUagEiuTDkHzsxHpFKVK7q4+63SM1N95R1NbdWhscdCb+ZAJzVc oyi3B43njTOQ5yOf+1CceWxG1bQVs5ZufpsMljq4Ui0/1lvh+wjChP4kqKOJ2qxq 4RgqsahDYVvTH9w7jXbyLeiNdd8XM2w9U/t7y0Ff/9yi0GE44Za4rF2LN9d11TPA mRGunUHBcnWEvgJBQl9nJEiU0Zsnvgc/ubhPgXRR4Xq37Z0j4r7g1SgEEzwxA57d emyPxgcYxn/eR44/KJ4EBs+lVDR3veyJm+kXQ99b21/+jh5Xos1AnX5iItreGCc= -----END CERTIFICATE-----

No right now its really just that file.

The GRP2624 and GRP2634 were not on the list. We don't have those models in our test lab, but thanks to the better aiming scheme they should work as well with the GRP template. The only question is if the number of VPK, MPK and EXT keys are correct. We assume the following: GRP2624: { vpk: 32, mpk: 12, ext: 0 } GRP2634: { vpk: 32, mpk: 10, ext: 160 } Anyhow if you want to try please use the 68.0.5.beta.

If you want to try 68.0.5.beta this one contains a reworked Polycom template. Please make sure that you reset the Root CA list on the PBX, so that the ISRG Root X1 is there.

We are stilling trying to figure out what the VVX are doing... One major problem is that the LetsEncrypt intermediate certificate is also a Root CA (ISRG Root X1), even though in the chain it is not self-signed and the phone should proceed to the actual root CA. If you google for it, there is lots of talk about it and how this makes older Android versions work for a few more years. Anyhow, for the VVX it does not seem to do us any favor. The phone just does not accept the certificate not matter what we set up un the TLS settings. There is an alternative LE chain available, where the ISRG Root X1 is the Root CA (which might cause actually more problems), but this also does not work. We'll try to figure this out, but it might take some more time.

The problem with 18x without media is that it's not possible to control how the ringback sounds (e.g. country) and it also adds additional delay upon pickup for connecting the call. Because of that the PBX always uses 18x with SDP and provides media, either locally from the PBX or from the trunk.

Well first of all, if the provider does not provide the ringback thats for a reason — the called phone does not ring yet! Especially when calling cell phones it really can take some time before the phone actually alerts the user. To bridge that time, we provide "comfort" noise so that the line does not sound dead. When calling the mobile app we provide a special ding-dong ringtone to bridge the sometimes awful long time before the app wakes up. What you can try on the trunk is to change the "Local ringback generation for outbound calls" setting. If the provider sends any kind of 18x that could solve the problem. The other "hack" would be to load a new audio_moh/noise.wav file that provides some kind of ringback tone, similar to what is happening when calling the app.

Looking at https://en.wikipedia.org/wiki/Telephone_numbers_in_Australia the 12345 would be an actual number? If you dial for example a mobile phone number would would actually expect the 0 in the front? The whole idea about putting the number into the format is to tell the user how the PBX would understand the number and to make it better readable with spaces as separators.

Can you make an example? What country code are you using?

In the next version "app" means "mobile app". Then the desktop apps will not be affected by the flag. Its in 68.0.5.beta but not released yet.

Yea its on the list. The hard work was done and we need to essentially add this to the front end. Workaround for now is to use a generic online tool (e.g. you can log into your Google account and generate it from the text to speech API page) and upload the audio.