I've run into a puzzling issue.
I've an MCU-hosted (4501; v4.3(2.32)) video call, and when I share presentation content from Jabber Video (4.5), the EX90 (TC5.1.4) does not display the content to the second monitor. Depending on the settings used, the content is either missing or displayed in the "important participant" portion of the screen.
I've tried every setting on the bridge that seems to be relevant (general content settings, and conference content settings). An MXP unit connected to the same call has no issues. A point-to-point call with the EX90 does not exhibit the same issue. It seems to be only on a bridged call.
Has anyone experienced this before, and been able to resolve it, or have any ideas?
Hi Anthony. Im not sure that the preso would show on the 2nd monitor for the EX90. Ill have to dig this up to be sure but preso should be seperate channel on EX90 and if call stats show the channel is open, I wouldnt see any reason it shouldnt be receiving it. If you set the same call, send content from Jabber 4.5, snapshot the conference page so we can see whats being received and sent from MCU. On the diagnostics page for both EX and Jabber, verify presentation is declared in receive capabilities. Im curious with the snapshot page on MCU to see whats going on.
Also verify if all calls sip to mcu or is jabber being interworked etc. Would be nice to know to try and mock something up on Monday.
Sent from Cisco Technical Support Android App
Hi Anthony. Thanks. Looks like the call is encrypted, and you may be hitting the known limitation:
Binary Floor Control Protocol on encrypted calls
The transmission of SIP content from the MCU using Binary Floor Control Protocol (BFCP) is not supported on encrypted calls. To allow content to be transmitted over SIP calls in a separate channel from main video, you should disable encryption on the MCU or on the target endpoint.
Page 10 of 18.
The conference jpeg was the most helpful. MCU cant' send content to the first site in the list cause the call is encrypted SIP. Can you interwork the top user or turn off encryption on that endpoint to verify if you still receive it or not?
Okay, well I guess I'm guilty of not checking the documentation thoroughly enough. Thanks for pointing that out; it's definitely the issue. Turning off encryption of switching to H323 resolves the issue. It does present me with a bit of a thorny issue with respect to use of H323 vs SIP, and dial plan implications that I need to resolve now though.
I take it that since it's listed as a limitation rather than a bug, it's not something that is ever going to change? It's a pretty significant limitation on SIP usage. I assume it affects all the MCUs, even the new 53xx product line since they use the same software? It seems odd since I believe even Cisco has said that SIP is the way forward and H323 is effectively dying out....eventually.
Hi Anthony. I understand. Will poke around on this and see. I think if you remove encryption or possibly just register MCU as TCP versus TLS, SIP user may come in as unencrypted and wouldn't be a problem and you wouldn't have to change or mod your rules at the point. Can you give that a shot before changing everything? VCS should remove crypto lines if another connection is NOT over TLS, so this may be something to explore versus changing your search rules or anything.
Disabling encryption on the MCU or having it register with TCP instead of TLS both resolve the issue. Unfortunately this is not an option with some clients as their expectation is that encryption is mandatory. I'd appreciate it if you could get back to me on those issues. At least now I know what is going on.