cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1562
Views
0
Helpful
1
Replies

Phone Screenshot URL with HTTPS

gruber
Visitor

Hi All,

I need help regarding the phone screen feature. Our product uses a built-in Cisco IP phone feature that provides the current phone screen as PNG or BMP image via HTTP access.

Phone Screen URL: http://<IP-ADDRESS>/CGI/Screenshot

Problem

This phone screen feature works fine with all types of IP phones by using HTTP protocol. However, if we switch the URL to HTTPS, this feature is unreliable. It works in some phone types but does not work with other types. As a result, we noticed an unpredictable and unreliable behaviour.

It has been also tested without our product, so we carried out tests directly with Chrome and Firefox browsers and the result was the same. It seems to be unreliable when HTTPS is used in the URL.

Assumption

Could it be an issue with the phone firmware? Perhaps some firmware versions do not support HTTPS properly?

 

Please look at the attached Word document (phone_screen_issue.docx) where I added pictures for both working and non-working cases.

Kind Regards,

Zoltan Balogh

 

1 Reply 1

Rich R
VIP
VIP

Hi Zoltan

For https to work reliably you need to use a public trusted https certificate.   Otherwise every single device will need the correct private CA and intermediate certificates installed.

I see your URL is http://<ip address>/ - that's an immediate red flag for me because certificates should normally only be issued for a fully qualified DNS domain name (FQDN).  So the URL should be something like https://mydomain.company.com/ resolved via DNS and the certificate (issued by a trusted CA) should exactly match that domain.  That is the starting point for reliable working https.

The other factor is different TLS versions and ciphers/hashes.  Your client and server need to support common protocols and ciphers/hashes.  If client or server is horribly out of date (for example a very old client which doesn't support TLS) then they will not be able to negotiate the TLS connection.  So you need to make sure all clients and servers are capable of supporting the latest standards - in some cases that may require software or firmware updates.  It might not be possible on old products which are end of support.

------------------------------
Please click Helpful if this post helped you and Accept as Solution (drop down menu at top right of this reply) if this answered your query.
------------------------------
TAC recommended codes for AireOS WLC's   and   TAC recommended codes for 9800 WLC's
Best Practices for AireOS WLC's,   Best Practices for 9800 WLC's   and   Cisco Wireless compatibility matrix
Check your 9800 WLC config with Wireless Config Analyzer using "show tech wireless" output or "config paging disable" then "show run-config" output on AireOS and use Wireless Debug Analyzer to analyze your WLC client debugs
Field Notice: FN63942 APs and WLCs Fail to Create CAPWAP Connections Due to Certificate Expiration
Field Notice: FN72424 Later Versions of WiFi 6 APs Fail to Join WLC - Software Upgrade Required
Field Notice: FN72524 IOS APs stuck in downloading state after 4 Dec 2022 due to Certificate Expired
- Fixed in 8.10.196.0, latest 9800 releases, 8.5.182.12 (8.5.182.13 for 3504) and 8.5.182.109 (IRCM, 8.5.182.111 for 3504)
Field Notice: FN70479 AP Fails to Join or Joins with 1 Radio due to Country Mismatch, RMA needed
Field Notice: FN74383 APs Running 17.12.4/5/6/6a May Run Out of Flash Space Preventing Upgrades
How to avoid boot loop due to corrupted image on Wave 2 and Catalyst 11ax Access Points (CSCvx32806)
Field Notice: FN74035 - Wave2 APs DFS May Not Detect Radar After Channel Availability Check Time
Leo's list of bugs affecting 2800/3800/4800/1560 APs
Default AP console baud rate from 17.12.x is 115200 - introduced by CSCwe88390