Vodia PBX

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

Well in the latest version 69.0.5 (as we all know 69 is maturing) an administrative account can change the DND status of extensions through the front end by clicking on the account and turn DND off. The permissions to monitor the mailbox does that. I believe that is a workable solutions for most environments where users need some hand holding. But we need to keep this on the radar. I would be hesitant to immediate make that another account permission or feature, after all we were able to survive for the last 18 years without it and we might be able to survive another month or two without it.

But the site ID would not be a general parameter, it would be parameter for the MAC address? Otherwise, if it's just a general parameter YMCS would not take notice?

You would definitively see the OPTIONS packets, e.g. by filtering SIP packets by the IP address. If you don't see them—something is wrong. Originally we did that for Teams (not sure why, probably just the "Microsoft way"), but other vendors are also starting to use OPTIONS as well and this seems to work fine.

The name is "Explicitly list addresses for inbound traffic". The whole logic of figuring out where packets can come from is tricky because of the DNS NAPTR, SRV, A, AAAA records that are in play. Its also tricky to figure out if something is changing!

I have no doubt that the registration is stable. It's just the glitch with the notifications. sip-anycast1.telnyx.com and sip-anycast1.telnyx.com seems to have a random TTL between 1 and 60 seconds, and maybe we see those glitches because it changes and then that address is not on the IP address whitelist any more. I would assume that the glitch goes away if you add the 64.16.250.10 and 192.76.120.10.

You can include the field names like this #alias;first_name;last_name;email;position 123;Gunter;van Dunkel;abc@def.com;President

Thanks for the great analysis. We had a similar problem many years ago with UDP and missing SBC on the SIP trunk provider side. OPTIONS work only for SIP trunks that don't register. If the SIP trunk does register, you can instead the "Keep-alive time" and force the PBX to re-register every 3.5 minutes or so.

Oh great... But can you connect e.g. with Safari?

As far as I can see it might be because the associated IP address has changed, even though the registration status stays the same.