netpro78

I had T.38 working well on version 56.1 Win64 both with the built in fax to email, as well as a T.38 ATA. When upgrading to 59.0 Win64 they stop functioning, however downgrading to 56.1 solves the problem without changing any other settings. Any suggestions?

If the buttons are the only issue then I would like a win64 version since I am currently running 59.0, and not being able to do a CSV import of all extension values is the main problem that is holding me up, and I do not want to downgrade.

Since you are not offering 59.1 for Win64, any estimate of when 59.2 will be released?

Just curious as to when 59.1 for Win64 might be released

type;alias;ani;password;web_pass;first_name;display_name;mb_pin;mb_enable;picom;orbits extensions;101;;jfdshdhc;jpiqedc;Kim;;7217;true;*;171 172

I tested this out now that 59.0 has been released, and while it created the extension, it did not take the non standard values like mb_enable;picom;orbits These fields all stayed at their defaults.

I have since restarted the PBX, confirmed the settings were still set, and was still able to create an account as an administrator. I also noticed when listing all accounts that ANI, and DID colums do not populate

59.0 allows a domain admin to create accounts/change dialplan/ and change ANI even if the permissions at the system level are set to not allow a domain admin to create accounts.

Because right now the provisioning password is the same as the web password, and it is a regular activity for the end user to change their web password. It is not normal for them to change the provisioning password on the phone, and therefore they should be separate.

How about separating the provisioning password?

Yes, and you cannot trust an end user to update their phone's provisioning password in the phone if they happen to update their web password. Possibly each extension should have separate passwords for each function: LDAP password SIP Password Provisioning password Web portal Password Voicemail PIN

It is not as much of a LDAP issue is it is an issue with the way the system builds the config files. I would propose that there be an account type at the domain level that has permissions to download config files for the domain. Then when the system generates the config file, it fills it with the credentials of the account that the MAC is bound to, and not the credentials of who is logging in to get the file (like it currently does). It would probably also make sense if there was a separate password for LDAP since web, sip, and VM all have individual passwords.

I have found that 58.4 has issues when importing a domain with any browser other than Chrome. Also there seems to be an issue when trying to add address book entries at the extension level (the domain level works fine)

One small glitch I found with using an account just for provisioning is that the system fills the LDAP credentials in based on the creds used to log in, and not based on the extension that the MAC is bound to, so that would need to be corrected.

This worked well, and I also realized some details that I were not in the documentation. One of the confusing issues I was having is my wildcard, and my regular cert both have the same base domain name. My regular cert is xxx.yyy.mydomain.com. Wildcard certificate was *.mydomain.com. The problem was with regards to the web portal (the main reason I have the SSL cert is for the web portal, most all recent browsers support server name identification). If I put the wildcard at the domain level, then the server would utilize it when accessing xxx.yyy.mydomain.com. Technically it should not, and only match yyy.mydomain.com, and therefore it would not get to the server level traditional cert of xxx.yyy.mydomain.com that I needed to put there in the default position for phones that do not support server name identification. So the solution I found was to put the traditional cert at both the domain, and server level, and the wildcard only at the domain level, and everything worked fine. This should not pose much of an issue since very few customers require SIPS/SRTP, so by the time I get another customer that requires it, chances are their phones will support server name identification, or I will have filled the server up, and be on to the next one. This does lead to a potential feature request. If a domain could be bound to both a specific IP and port, then you could bind a certificate to the domain. This would make for a much more granular approach. It would also make sense to be able to select certs separately for HTTP versus SIP access

Really all you would need to do is to make the pbx do is accept the username/password of users in the domain admin field for phone provisioning requests. right now I can work around it by creating an extension just to provision with, however that is a waste of a license.

Since I am trying to support a phone that does not support server name identification, and it also does not accept wildcard certificates, I would like to set a default certificate that is issued whenever the client does not support server name identification.

While I have a feature request open with the phone manufacturer, is it possible to specify a default certificate that is presented if the client does not support RFC 3546 (Server Name Indication)

I am referring to a username/password that can be used on all phones in the domain to download their config, that would be a great feature for a future version, and make me more likely to utilize the built in provisioning of the PBX instead of hand writing config files, and hosting them on a separate server.

Is there a way to create a username/password per domain that will allow downloading of config files? Right now only the extension web usernames/passwords seem to work, and while it is more secure, it would be much easier to have the option of a domain level username/password that would permit provisioning.

Perfect, THANKS!

Typically I like to be able to create extensions with the following fields prefilled: alias,ani,password,web_pass,first_name,display_name,mb_pin,mb_enable,picom,orbits

I really do not care about bulk import of anything other than extensions, however not being able to preset all of the values of the extension is a big step backwards. The number of steps required to click through all of the extensions, set intercom permissions, set park orbits, and enable/disable mailboxes after creation is a huge waste of time. At first I was slightly upset by loosing the ability to create 10 extensions at once in the GUI, however it was more than made up for by the ability to set any extension parameter that I desired via CSV. Now that option has been taken away, I feel like it is just a large step backwards.

Regular web browsers do not have the issue. Is there a specific name for the extension that presents the domain name in the client hello? Just trying to be as specific as possible when opening a ticket with Polycom.

I am trying to utilize multiple certificates. I have a wildcard certificate as the server certificate. I have a regular certificate as well that I have uploaded as a domain certificate. When using the web portal, the system seems to always utilize the proper certificate for what I am accessing. The problem is when I have a phone trying to register to a specific domain, the system does not utilize the certificate that matches the domain I am trying to register to, it is utilizing the wildcard certificate instead. Since the phone does not like the wildcard certificate, the registration fails. My current setup is version 58.3 Polycom VVX 410 firmware version 5.60