Vodia PBX
-
Posts
11,108 -
Joined
-
Last visited
Content Type
Profiles
Forums
Events
Posts posted by Vodia PBX
-
-
It was introduced with the new ability to treat a hunt group like a shared line. We'll fix this in 68.0.30.
-
You are right. The new MAC range was in some places, but not all. We will include it in the next build. If you like, you can manually change the pnp_yealink.xml:
<pattern>805e0c######.cfg</pattern> <pattern>249ad8######.cfg</pattern> <pattern>yealink.cfg</pattern>
Alternatively you can manually set the provisioning URL in the phone to use something like yealink-############.cfg.
-
Well the passwords are encrypted in the file system, so you would not be able to see the content. However if you check the extensions folder, you should see that the file has changed and the content of the "password" entry has a different value (yes the "password" was the first password entry used by the system, then came the "web_pass" and so on). It does not make a difference if this is single tenant or multi tenant. But it does make a different if the tenant has the magic name "localhost", which serves as a wildcard name.
There were some versions that had problems with the SIP password. What version are we talking about here?
-
AFAIK it does not matter which header comes first (see RFC 5322). I tried to Google for the message but it seems to be a problem with an empty line?! Maybe you can attach the content from the email log. Could be something "stupid" — as usual.
-
5 hours ago, mcbsys said:
I think you mean the local port? Ideally the email would show a log (table) of the attempts: source IP and port, destination URL or IP with port, username and password attempted. That would quickly give me an indication of how seriously to take the hack attempt. Maybe something like this is possible in IPTables, but I'm not a Linux pro.
The port, and with it we also easily get the local IP address that was used. However the PBX SBC does not keep too much detail about each access (this would make DoS a real nightmare), so it essentially logs what has been stored with the associated address.
5 hours ago, mcbsys said:If only I knew what to investigate. "Status change" is the only notice. What Status? Reachability? IP address? Registration? The message as is doesn't tell me much!
The status is the SIP status for the trunk. 200 means "Ok", and other status depend. For example 408 means that the REGISTER that the PBX has sent did not return anything and timed out. Usually this is because of Internet connectivity problems.
-
There is no ghost in the machine. Even though it seems otherwise, there is no magic in running software. There are essentially two problems here.
The first one is password security. If someone gets the password to your PBX that should not, yes there will be chaos. We actually did something about it — passkeys make it a lot harder to steal credentials and we expect that users like administrators will gradually migrate to passkeys. But if someone has the password to the server itself (file system), anything can happen. This is a standard problem and it the PBX is just like any other server software. But my feeling is that this is not the case: If your passwords have been stolen, you would probably have many more problems with other accounts that you own.
The other one is what the PBX does. When the PBX starts up the first time after a fresh installation, it needs to set up a default configuration. This includes a default administrator account and password. When the code starts running, it has to make that decision if this the first time it runs or not. For that, it tries to read the configuration — and this was probably the problem: It could not read the file but it could eventually write it and overwrote the existing configuration. The reading and the writing does not necessarily happen within a second. For example, in MacOS when you start a process you get a pop-up to approve file system access for the process which is exactly that problem: It tries to read, which fails and then later when some other setting needs to be written, it still has that initial configuration in memory. In addition, the operating system calculates a hash over the executable image and stores the access rights based on the hash. If you do a software upgrade, the whole thing starts again because the operating system does not trust the new executable.
If you have two or more processes running the problem is similar. The "sleeping" process eventually wants to write something and the overwrites the configuration of the "active" PBX. This is actually sometimes happening when the installation process manually starts the PBX and the administrator additionally starts the process with the service start command, without prior deleting the already running PBX manually. This is why we recommend a reboot after installation as this avoids that problem and also makes sure the daemon was installed properly. If you don't want to take this step and you know what you are doing, you can at least check with the ps command if there is only one PBX running.
Lastly, we of course want to make this as simple as possible. That is why we have added additional checks for file system access during the start procedure in newer versions. If the PBX has no read and write access, it will exit. This might confuse installers, but at least it does not create hard to understand problem that we are talking about now.
-
It generally almost always makes sense to use the Yealink General parameter to make such changes. The PBX makes sure that the parameters in there are taking precedence over what is in the yealink_common by default. Then future changes in the yealink_common will be no problem.
-
If you are compressing the recordings to the GSM format, this might cause the problem. Unless disk space is a problem, I would today recommend to record it uncompressed and in stereo, so that it is clear who said what.
-
16 minutes ago, RichardDCG said:
using the redundancy settings on the Vodia, when the secondary PBX instance detects a failover situation are the remote IP mappings a manual process so that tenants can reconnect?
If you want to do the Vodia failover, you need to think about DNS. One solution is to choose DNS SRV records, which require that all clients support that (which most do today). Another solution is to choose DNS A records and use the Action URL in the failover case to trigger a script which changes DNS records. Using IP address will not help unless your script if able to re-assign the IP address to the failover location.
Reminder: In most (99 %) of the cases you don't need the Vodia failover because your datacenter already provides you with failover of the VM without you having to do anything. The Vodia failover is for geographical failover and some really special cases, and it is a huge amount of work to set this up properly (and not make things worse).
-
15 minutes ago, RichardDCG said:
ok. This is a multi tenant on AWS, is this an option with prepaid? If that is not possible then the solution to 'keep everything the same like we had before' is not realistic.
Prepaid does not differentiate between extension types (at least today). With postpaid you have the option to have one price for all extensions or different prices for different extension types (at least today). So if you have lots of agents, it probably makes sense to choose the one-for-all option, and you can still do it post-paid.
-
1 hour ago, RichardDCG said:
given this is a multi tenant install, where can I get information on a 'prepaid option'? All I can find is single business.
Well "hosted" is post-paid, and everything else is pre-paid, including standard, pro and enterprise licenses. Technically they can also have multiple tenants in enterprise so that is why multi-tenant is not so much the point.
-
The
ldap.name_filterdoes not look right. It should be (|(sn=%)(gn=%)(company=%)(category=%)). Are you sure you did not override the template? -
8 minutes ago, RichardDCG said:
where can I get that pricing?
Well who ever gave you the current pricing that you have ...
-
Yes, please make sure that you did not modify the Yealink template. What version are you on?
-
Those admin emails are not customizable, actually they are even hardcoded to English (who cares about the administrator
). It might be somewhere on the todo list, however it's usually not a big deal and most administrators on the planet can understand the content. But we are always interested in revealing more interesting information. For example the local address is indeed interesting.
We did include a hardcoded link to a location service, however it changed and became useless.
We do not send email on re-register. If you get an email every hour, you do have a problem that need to investigate.
-
If you are on a license type that does not differentiate extension types (like all prepaid licenses), the extension type for agents does not have a different price tag. Only if the license type permits other types like hotel rooms, the flip side is that agents will be more expensive than a regular extension. If you want to keep everything the same price like we had before, just use the license that does not differentiate extension types.
-
Call queue agents can be agents in a call queue... I know its sounds trivial, but there is indeed not much more to it.
-
We are making good progress on version 69 to fully support video on the apps, including stuff like changing horizontal and vertical orientation. While Windows, MacOS, browser and Android should be fine now, iOS is still on the todo list but we are getting closer.
-
For manual registration, there is the SIP password. It works with the extension number. You also need to make sure that you have the right tenant name in the Request URI (unless you use the name "localhost" for the tenant), e.g.
REGISTER sip:30@tenant.com SIP/2.0where 30 would be the extension name and tenant.com the name of the tenant. The authentication name then is the same 30, and you may choose a different outbound proxy e.g. the IP address of the PBX as long as the phone find the PBX. -
There is no setting for this. You could change the HTML template and just take the icon out.
The point about the information is to see who accessed the recording. It is sensitive information who listened to recordings. Why would you want to hide that information?
-
I think the problem is limited to app registrations for mobile apps. They are kind of random, for example after receiving a call the connection is still active for a few seconds and it makes no sense to count them as registration. However registrations for PC based apps IMHO do count — it should not matter if someone works from home with Internet perfectly okay when the office has an Internet outage. Anyhow we'll adjust that mobile app dangling registration in the next release (69.0.4).
-
SSH is not the problem for sure. It all comes down to the REST API. There are tickets that are two years old, so I take it we are talking about an older version of the PBX? The conclusion in the ticket was that the PBX did not have file system access during the start up of the PBX and was granted later, when it already created a new default configuration with the default password. If you are still running the version, either make sure that the PBX process has file system access from the beginning or upgrade to a later version, where the PBX process verifies that is has file system access before creating a new configuration.
-
Pending really just means that there are other requests that are not finished yet. I would turn on the logging for the web client to see any clue, like the wrong password or a firewall issue. There is no limit on how many requests are pending (they take only small amount of memory), but obviously this is something that eventually need to resolve.
You can also always login to the Yealink management console and see if anything has reached the server.
-
It is less about the agents but more about the queues. The queues are about the caller experience and the reporting. It is not a dramatic price difference, and it helps keeping the other prices stable while many other cloud services are currently significantly increasing prices.
System SMTP headers Misspaced
in Email Topics
Posted
Yes the colon handling is inconsistent, but the reason for that is probably because the Message-ID was inserted by the mailer. We had already changed that in 69. What we could do is to add the Message-ID also in 68 and even add that space after the colon, so that if any other tool feels like inserting headers they would look the same.