Vodia PBX

The template icon is just an indicator. But maybe it makes sense to make that a link to the actual profile.

The PBX SIP subsystem is aware about multiple network interfaces. In a nutshell, when the PBX sends out a packet it figures out what IP address the operating system would use when sending out the packet and then puts that into the SIP/SDP message. The mechanism can be explicitly overridden by the setting for the "IP routing list". But if the operating system is configures correctly, it is all automatic. This works with IPv4, IPv6, VLAN, VPN, SD-WAN, LAN and whatever is out there. It does not matter if there are single or multiple physical addresses. Vodia IOP happens to have one physical port, but in Linux you can put many network interfaces on it. If you have a server with multiple NIC it does not make a difference for the PBX. Problems are mostly because of NAT, either because the SIP trunk does not use a SBC or because you want to connect users home. But if possible I would prefer to set the routing up properly on OS level and then it will be working out of the box.

If you like, try 68.0.5 (daily build). Poly Edge B will be a challenge because it's a completely different phone. The Poly Edge E series is a lot easier—it's practically just a renamed user-agent.

I would still say this is something the address book can do, also for a queue.

We'll try to suppress it in the next build.

We are trying to get updated MacOS and Windows apps into the stores—but it takes longer than expected.

Other providers are also starting to use OPTIONS, for example Amazon Chime is using OPTIONS. It seems to become "fashion", maybe just to make it very hard to register a VoIP phone there to keep pesky consumers out .

Changing the DNS address for TCP/TLS-based registrations IMHO make no sense. In the old times when the SIP standard was written, there was not such an abundant choice of TCP-based load balancers so they thought UDP would be the answer (but it was not). So why bother looking up the address again and again when the TCP connection has not dropped. Dropping it would leave a small window of non-registration where inbound calls are not sure to terminate. The other real life problem is that providers tend to set DNS durations very short, which causes a lot of extra steps that can fail and cost time, especially when going through the while NAPTR, SRV, A and AAAA chain. That is another reason to keep the TCP connection when the trunk is still registered.

There is no mixing of REGISTER with OPTIONS in Vodia SIP trunks. But IMHO re-register is not as heavy as it might look in the logs; it's actually relatively small bandwidth.

Oops should have expanded it... It looks like the support for the new PolyEdge devices displaced the support for the older Polycom devices. We'll fix that in the next build. If you like, remove the User-Agent lines for the Edge devices in the pnp_polycom and then they should work again.

Oops should have expanded it... It looks like the support for the new PolyEdge devices displaced the support for the older Polycom devices. We'll fix that in the next build. If you like, remove the User-Agent lines for the Edge devices in the pnp_polycom and then they should work again.

Ok some could just provision the tenant DNS address as the site ID or some kind of hash over it.

Hmm so if you change this in the template it works as it should? #Specify whether to encrypt the SIP messages; 0-Disabled (default), 1-Optional, 2-Forced; account.{lc}.srtp_encryption = {outbound-secure tcp 2 0} Maybe Yealink has changed the behavior in the years since we did this...

Hmm. But the MAC is in the device inventory? What is the exact log message about the domain context?

It's all about SDP offer/answer. The PBX will answer a SRTP offer over TLS, and it will offer SRTP over TLS. There was also some support for ZRTP in the PBX some time ago, but it fizzled probably because DTLS became mainstream.

I still believe that the 401 does not matter... Anyhow in the screenshot the flag to check DNS every time is on—is there any particular reason for that? It adds another point of failure, and who knows, maybe that is causing our glitch? Well its not Vodia software but HTML5 rocks!

We'll do the release notes for the 69.0.6 release. The gap between 69.0.4 and 69.0.6 will be shorter than between 69.0.2 and 69.0.4.

You need to have a conference room in the tenant that is not scheduled (aka regular conference room).

When a phone set a DND only locally, there is not much the PBX can do about it. Many phones support a subscription type called as-feature-event which allow the PBX to push the DNS state to the phone. There is another twist about it: some phones still reject the call when they believe that they are on DND, but they are actually not or when the PBX routes the call even though the DND is on (e.g. because of a override permission like a secretary calling the boss). The whole thing is not the finest hour in the SIP ecosystem. Anyhow, without that subscription or when the subscription gets lost for whatever reason, the phone and the PBX get out of sync. As for 69, you need to have the permission to monitor the mailbox for the account. Maybe "handholding the account" would be a better description for this.

Ok that makes sense. Another provider supporting SRTP!

I still don't 100 % get it what the ID are for. Are they used in the Yealink DM as a way to see where devices are? E.g. if you have thousands of devices to better organize them?

The outbound-secure checks the MAC, the extension, the tenant, the system and then the default transport provided as argument what transport layer to use. If it tls, it will be secure, otherwise not. The whole logic whether TLS can be used or not has become very difficult with all the possibilities to upload certificates, automatically generate certificates from LetsEncrypt, and all sorts of manual override possibilities. The intention is to make this process invisible to the regular user and administrator, but its not always possible... We could force the phones to use SRTP when we are using TLS, and this would probably work. However in an effort to minimize trouble (potentially because some admins choose to override settings), we kept is more casual and let the phone also accept regular RTP over an otherwise secure connection. Anyhow, so far we had no trouble with the optional SRTP and everyone seems to be happy with it. If you want to enforce SRTP in your organization, you can just "hard code" the srtp_encryption to 2 in the general parameters—if then for whatever reason there is no SRTP, there will be no audio and this would be a precautionary measure.

It should match the following pattern (from pop_polycom.xml): <file name="polycom_master.xml" encoding="xml"> <pattern mac="0">############.cfg</pattern> <user-agent>FileTransport Polycom</user-agent> <user-agent>FileTransport PolyEdge</user-agent> <prefix>true</prefix> <vendor>Polycom</vendor> <protocol>tftp,http,https</protocol> </file> How is the whole HTTP request from the phone looking? Has anything changed for Poly(com), maybe its HP now? Did you open for provisioning (pairing)? Anything in the log for provisioning that might prove additional clue?

The host in the contact does not interfere with the domain check. This should be no problem. Do you see the call in the tenant call log?

Yes. Vodia actually uses Zendesk for the support tickets