Refresh video low on HDX 7000 to CMS

[ChristopheM]

Good afternoon everyone,

I encounter a problem with my customer.

He've got some Polycom HDX7000 on premise, and CMS (cluster), CUCM (PUB/SUB) too.

SIP is used for registering and communications.

When a videoconference is hosted in CMS, my mookup endpoint Cisco (Roomkit) dial to CMS with URI+PIN, and it works.

However, with all Polycom HDX 7000 endpoints, users doesn't see welcome all page CMS (mountains) and remote sites, whereas they could hear audio CMS and remote sites well. Instead of seeing remote sites, users see big pixels, and there is a log time refresh to the screens.

At the beginning of the communication they see the top of CMS (blue sky and cloud), but not the bottom of the screen is all green, (no mountains).

In CMS administration, I constat that my mookup Roomkit negociate H264 Codec in video and the Polycom HDX negociate H264HP.

The issue is the same when a videoconference hosted 2 Polycom HDX together.

On the other hand in Point-to-point communication (Cisco to Polycom or Polycom to Cisco), there is no issue.

In the interoperability (Acano Knowledge), CMS has been tested with H264 and H264HP, and also some HDX 7000 Polycom (v 3.1.2 or higher).

For information, CMS runs in 2.3.2 version, and Polycom endpoint run in 3.1.10-51067.

Also, we've tried to bypass firewall and rules, therefore we use an unique subnet for all equipment (CMS, CUCM, endpoint). We've attempted to reduce bandwidth, but without effect too.

Thank you for reading my issue.

Christophe

[ChristopheM]

Hi all,

Looking for this issue, I find that in Bug Search Tool :

Polycom HDX does not decode CMS encoded H.264 HP correctly

CSCvh92717

The status is solved but I can see no resolution.

Christophe 

[Wayne DeNardi]

There are many interop bugs that stops video working in the old Polycom 3.1.10 software release that are fixed in the latest Polycom 3.1.12 version.   Polycom bug VIDEO-112780 is probably the one you're getting when there is an MCU involved.  I'd suggest you upgrade your Polycom to version 3.1.12.

3.1.12 also addresses a critical security vulnerability, so I would highly recommend that this is implemented across your Polycom fleet.

[CMONJARET]

Hi Wayne,

Unfortunately I upgraded Polycom endpoint with last release but it doesn't work.

Just anothing strange, I constat in fact when there is just one Cisco endpoint and one Polycom endpoint connected with CMS, everyone hear and see well => negociation is H264HP between Polycom and CMS.

On the other hand when there is a third party (for example Cisco endpoint) connect => negociation is the same between Polycom and CMS H264HP, audio is OK but not video (video poor).

Christophe.

[MooGan]

Hello, I got 100% same problems during POC to replace Polycom, while Polycom infra has no issue on this. Are there any solution to resolve it as Polycom may not sell upgrade lic if we win the project.  

[ChristopheM · Accepted solution]

Hello Moogan,

I have just to find a workaround.

It's possible force H264 codec instead of H264HP in Polycom.

To do that, connect to Polycom by Telnet and set this command:

pbox config H264ProfileName 0 BaseLine

You could do a rollback with :

pbox config H264ProfileName 0 HighProfile

For the moment I don't encounter some issues with this command, and I note negociation H264 in CMS.

CSCuy95177 explains these action in Bug Search.

Christophe.

[MooGan]

Hello Christophe,

Appreciate for your professional suggestion. BTW, this telnet command seems not valid in HDX. It prompts "error: command not found". Also, I can't find such API in Polycom's doc. Can you recheck? Or else, can we disable this H.264HP in CMS instead?   

[ChristopheM]

Hello Moogan,

I could set this command to HDX7000 on 3.1.10 and 3.1.12 release.

CSCuy95177 explains it's an undocumented command, and I don't find information on admin guide or API guide of HDX.

At the moment it's not possible to deactivate H264HP. Peehaps future release 2.4 could solve that.

Christophe.

[MooGan]

Ahh.. I really have no luck. HDX doesn't response to this command.  My one is 3.0.x version. I have tried this command with their new Group series, it also doesn't work. Do you think CMS & HDX will have no issue, if we have no choice to subsidize the upgrade cost of HDX to 3.1.x?  

[ChristopheM]

I think updating 3.0x to 3.1x isn't upgrade major. So I could try to upgrade in 3.1.x and if you have some issue, downgrade it.

Christophe.

[bobbyg]

Thanks Christopher, this works perfectly to fix the green bar issue on my HDX 7000 running Firmware 3.1.12-54021

Log into codec via Telnet and run the command Christopher listed above: pbox config H264ProfileName 0 BaseLine

[ChristopheM]

Happy to help you!

Christophe

[GABRIEL KNEBL TUMOLO]

Upgrading the CMS to the last version avoid you to change the H264HP.

[privateuser]

Issue I had

When doing a call using a HDX7000 running version 3.1.12 and dialing to CMS on version 2.4 on SIP we experience a green screen covering more than half of the screen. The codec being used is H.264 HP and this can't be changed. When dialing using H323 this is not an issue.

We have also noticed when dialing straight into a Meeting Space the green screen will appear and then go away, when dialing to the CMS Auto Attendant it will not disappear and we are not able to insert the Meeting PIN.

When dialing from the same HDX7000 to and older version of CMS this issue is not present. So the newe software from Polycom and Cisco is not working together, should I log a call with Polycom for this or has anyone else experienced something simmilar.

What resolved the issue for me:

Can you please check if compatiblityProfile is set on the lab CMS?

To do this, use Postman or similar app for API access to the CMS.

Perform GET method on https://x.x.x.x:445//api/v1/compatibilityProfiles

Check if you have element h264CHPMode set to basic on that compatibilityProfile.

There is a known defect https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvh92717 which shows the exact same symptoms that you are seeing on the production CMS with 3/4th screen filled with green. The defect was fixed in 2.4 version by adding the h264CHPMode in the compatiblityProfile. By default the mode is set to auto but by changing it to basic, the use of H264 HP will be avoided.

The instructions to restrict the use of the H.264 CHP encoder to basic mode are:

• POST to /compatibilityProfiles with the parameter 'h264CHPMode' set to 'basic'
• PUT to /system/profiles with the parameter 'compatibilityProfile' set to the GUID of the compatibilityProfile created in the previous step