Jump to content

Vodia PBX

Administrators
  • Posts

    11,108
  • Joined

  • Last visited

Posts posted by Vodia PBX

  1. Admittedly the 69 frontend turned out to be a bigger project than anticipated. But we are getting there. For example, it can now do things that were not available in 68, like dragging calls into the conference room and actually showing participants in the conference call, or allowing redirection while turning DND on for some time. Visual appearance is always debatable, but at least 69 is completely responsive and modular, which should give us happiness in the years to come and the screen resolutions to come. 

  2. 19 hours ago, RichardDCG said:

    the issue with the mobile carriage is also CGNAT in a lot of cases.  

    If the carrier supports IPv6, you can just do that. All you need to do is add an IPv6 record. iOS and I think also Android prefers IPv6 today, so IPv4 and IPv6 can coexist. 

    But even with CGNAT it should be working with the Vodia PBX SBC as long as the PBX runs on a public IPv4 address that can be resolved from the handset.

  3. I would assume that all they are looking for is RTP content, which is relatively easy to spot by filtering for UDP packets with a certain header. It does not matter if the content is encrypted or not, the header looks the same.

    On the Vodia apps, we could think about changing the RTP packet signature to some random, proprietary format because we control both ends; however this will not work when we use standard SIP devices and software. 

    The other interesting avenue could be to loo into RTP header compression (RFC 2508). Maybe the carriers just want to preserve bandwidth and apart from that have nothing against VoIP, and this could be a way to have everyone happy.

    Apart from that, there is almost no reason to use the standard port 5060. It just attracts scanners and creates unnecessary traffic.

  4. There are NAT types that change the port if you send a packet to a different port on the same destination, though thinking about it this should not cause any issue because the PBX never changes the port. Luckily, the router industry has realized that VoIP is a reality today and have also improved their algorithms. Ultimately, WebRTC will pressure all manufacturers, and we don't have to worry about two-way audio any more. But until then it's a good idea to stay away from standard ports for VoIP, unfortunately. 

  5. Would the watch VoIP call work without the phone being in Bluetooth distance? I would doubt it. I would assume the watch is from audio point of view just a Bluetooth speaker device. 

    I have also taken calls on the watch, but the audio quality is given the hardware far inferior to the phone itself. I do it if the phone is too far away, e.g. another room. I agree there are some cases where taking a VoIP call on the watch would make sense, but I would say something in the 1-5% area of all calls.

  6. You don't need STUN for NAT traversal. The PBX SBC takes care about it. Yes the PBX in the beginning sends the packets to the "advertised" address, but as soon as the first RTP packet from the phone hits the PBX, it will change the destination and "learn" the real IP address. STUN may help to make this a little faster, but it can also make things complicated for certain NAT types. IMHO it is not worth the trouble. 

  7. One way audio is almost certainly a problem with the firewall if other offices and devices are working. You could try to use TLS so that the firewall cannot intercept the traffic. You could also ask the user to move the Yealink phone to another location (e.g. different office or home) to see if that makes a difference. 

  8. If only those users are affected and other users are okay, it is usually their Internet connectivity. I would turn the PCAP on for those users and take a look at the RTP. 

    If the problem is only with a specific SIP trunk, then that SIP trunk provider might have a problem. But this happens almost never. 

    If all users are affected, the problem is likely with the server. You can check if the server run out of RAM, which can happen sometimes. If a restart solves the problem, you might have not enough memory on the server.

    BTW 68.0.30 is available. 

  9. That's right, currently it's only in the personal address book. However if the call came in through a group, it might make sense to assign the number to the shared address book. It would requite though that the one who is blocking the number also has the permission to manage the shared address book.

  10. The latest 69.0.3 contains a new graph right now only on the personal level that shows "availability" over the past 7 days. It consists of DND, registration availability (either though a registered phone or through the app) and actually being in a call. This should provide a good insight about staff working times, especially from home. One of the next steps would be including it in a weekly email to the user.  

    The backend is pretty generic, 7 days could be a month or quarter and the term availability is also generic. At the moment we want to get this out of the door on an extension level, but we will soon move the also into the queue. The new frontend has a statistics section — what other graph would make sense? We can put the graphs that we have in the tenant administrator menu there easily and they might also help providing insights. One of the ideas is that 2020 it was about working from home, and in 2023 it is more about working from home and properly documenting it. We were thinking about measuring talk ratios (agent talking or caller talking) as an additional valuable insight, especially when compared with peers in the tenant. 

  11. Hmm. It would have to be all primary agents busy, otherwise it would get very hard to understand and maybe recursive. But there is a point about keeping the calls in the same queue.

    Queues are typically intended to process one caller at a time, similar to landing planes on a runway. That would imply that most of the time all agents are busy. This is why there was always this extensive music on hold for the waiting callers.

    Waited longer is supposed to look at the duration callers are waiting, essentially hearing music on hold; after hearing ringback is about callers hearing ringback because an agent is being alerted. These durations should be different. In most cases the waiting with music in several minutes while the waiting for the agent to pick up the call should be seconds. But when the waiting times are practically zero because calls are already redirected out of the queue these two conditions might look the same.

    Before jumping into adding a new condition IMHO we need to take a step back and see what we want to achieve here and if there is a better way that would fit the next few years, where the classical call center will definitively go through some more changes. 

  12. On 4/14/2023 at 5:10 PM, mcbsys said:

    So is OPTION something I can add to a trunk and if so, how? The documentation says that the Keep-alive time setting applies to registration, which is not in use here.

    I guess I can switch to registration; I just didn't think it was necessary if I have a static IP.

    In the type from down for the trunk, there is an option for "option". You can try that. 

    But even if there are only few calls and the amount of keep-alive might look ludicrous it makes sense to use the registration model. If you compare with how much traffic is being generated by watching a video, the keep-alive again looks more like a rounding error again. Actually depending on the firewall setup or if there is no firewall, you might be good with refreshing the connection every 5 minutes or so, which would really keep the overall overhead small. 

×
×
  • Create New...