Jump to content
Vodia PBX forum

Vodia PBX

Administrators
  • Content Count

    9,560
  • Joined

  • Last visited

Community Reputation

0 Neutral

About Vodia PBX

  • Rank
    Advanced Member

Profile Information

  • Gender
    Male

Recent Profile Visitors

192,067 profile views
  1. Ringback usually means that a human is being called and that the call will connect within seconds. Generally we want to keep it that way. That is why the ACD plays that sound when an agent is being called for the current call. However there are situations where this is not desirable, e.g. when agents are available only sporadically or when it takes a long time to get an agent to answer the call, and you want to keep the caller on the phone. Yes The way this currently works is that there are no more announcements rendered into the music - a very subtle hint that the ACD is actually ringing an agent! You can actually have multiple calls ringing. For example the ACD can assign the call to a specific agent and then schedule the next agent, even while that call is still ringing. For that, you can set the "Allow multiple calls to ring agents in parallel" option to yes.
  2. I would not random down or upgrades without knowing what is causing the issue. Downloading a domain should be pretty safe - except when there are so many records that you might run out of memory. Maybe you'll see the pattern and then once it is reproducible we can say what the problem is/was.
  3. My thinking would be around using an auto attendant that can distribute incoming calls where we can control the redirection with a star code (aka winter storm redirection). But what is the use case here?
  4. Of course if it happens when a specific action is taking place that helps a lot with identifying the problem. Also the question is what exactly happens - for example does it just stop accepting new connections (which would hint at problems with the number of sockets), does it go berserk with the CPU, or does it just silently drop out. Are you using the RPS service?
  5. Oh what did you put into the field? Maybe there was something the backend did not understand which would explain why the email never went out...
  6. Do you have anything in the log where we can see what exactly is sent to the PBX? For example turn the logging for Call-related SIP packets on - then we should see what is coming in. Also, do you have a country code set for this domain?
  7. You can always use the ERE for inbound trunk routing, for example the one below !^00([0-9]*)$!+\1! !^([0-9]{6})$!+423\1! 40.
  8. There were a couple of issues with the *58 code. First of all, the initial message was confusing. And it could have been that the database query for the next recording did not look at the right fields. However it is important to dial into the right ACD, the code is playing back only the recordings of a specific ACD or account.
  9. You don't have to worry about the media IP - the PBX does not filter for those. As for the signalling IP, you have two choices - leave it empty and assume that you will never receive a packet from another location except where you registered. That is actually a reasonable assumption because everything else will not work with NAT anyway. Otherwise you can write a little script in the programming language of your choice that produces the list of IP addresses - there is no limit on how many addresses you can list there.
  10. In terms of settings what you could do is provision a phone, and then take a look on how it was set up - kind of reverse engineer what has been provisioned. Instead of using the LDAP password you can then use the extension web password, and this should work.
  11. That sounds like the message was lost? Can you play it from the web interface?
  12. You cannot set the LDAP password - it is automatically generated. This is because many SIP phones don't support TLS or StartTLS or it is simply buggy (e.g. no SNI extension and problems with the certificate). Then it is better to limit the damage and have a separate password just for LDAP which does not have the permission to make calls. But you can use the web password instead. It serves as the "master password" for the account - bear in mind if that password leaks out attackers will be able to make calls using the password.
  13. CO lines in SIP work different than in old key systems, especially when "seizing" a line. In order to seize a line the phone actually needs to make a call to the co-line account. Then you would have to enter the phone number in this call - and there would be no way to delete the last digit and the phone system would have to guess when the number is complete to send it to the SIP trunk. In many cases it is better to just use park orbits instead where there is no seizing of lines, just park and pickup.
  14. In principle a good idea. You can get this working obviously on iptables level right now, though it may take up to 4 hours to fend off an attack. We have an automatic blacklisting feature since ages - what could be interesting is sending that information back to them so that they can consider blacklisting the provided address.
  15. Did you try *58? You need to set the permissions for that feature in the permissions tab of the extension to use this feature. Then you can enter what calls you want to listen to.
×
×
  • Create New...