Cisco Bug: CSCtf41729 - Listener joins with scheduler in MR and 2nd listener in WR
Jul 13, 2010
- Cisco Unified MeetingPlace
Known Affected Releases
Symptom: When a listener joins a meeting with scheduler in main room, and another listener already moved to waiting room, the scheduler can not move him to waiting room any more during that meeting. Conditions: Procedure: 1. User A schedules a lecture style meeting from Conference Manager/Webinar meeting from Web UI. 2. Scheduler joins via video phone and via web (enters web meeting room). 3. Guest 1 joins the meeting via audio IP phone. 4. Scheduler moves all listeners to Waiting Room (WR) via Conference Manager/Adobe Meeting Room/TUI. 5. Guest 2 joins the meeting on video phone. 6. Scheduler moves all listeners from WR via Conference Manager/Adobe Meeting Room/TUI. 7. Scheduler again moves all listeners to WR via Conference Manager/Adobe Meeting Room/TUI. 8. The meeting ends (either by itself or by scheduler). Actual behavior: After step 4, Guest 1 is correctly moved to WR (verified in Conf Manager, adobe meeting room and TUI), and scheduler's video freezes on last image. After step 5, Guest 2 joins as listener. In Conf Mgr he enters Main Room, in Adobe meeting room is correctly marked with a lock and muted icon, but on his video phone - although he can hear the main room meeting, his video is off. Scheduler's video is still frozen. After step 6, Guest 1 is correctly moved from WR to MR. Guest 2 is as after step 5, except his video turns on - he can now see scheduler's video. After step 7, only Guest 1 gets moved to WR (In Conf Mgr, Adobe meeting room, and on the phone). Scheduler's video freezes, as after step 5. Guest 2: in Conf Mgr stays in MR, in Adobe Meet.R. he's marked with lock and muted icon and is still in main room, and on his video phone - he can still hear the main room, and sees the scheduler's frozen video image. After step 8, the meeting ends, scheduler and guest 1 get disconnected from their video and audio phones, but guest 2 is disconnected only via video, he remains on the audio for an indefinite time. Expected behavior: After step 4, scheduler's video should not freeze. After step 5, Guest 2 should see video of the main room meeting. After step 7, Guest 2 should get moved to waiting room, he should hear a voice prompt via audio that he is being moved to WR, his audio should be turned off (he shouldn't hear the main room - instead, he should hear the meetingplace music), and his video should be turned off and he shouldn't see frozen image. Scheduler's video shouldn't become frozen, instead he should see local video from his video phone's camera. After step 8, Guest 2 should hear a prompt that the meeting is over, and he should be disconnected from the audio.
Bug details contain sensitive information and therefore require a Cisco.com account to be viewed.
Bug Details Include
- Full Description (including symptoms, conditions and workarounds)
- Known Fixed Releases
- Related Community Discussions
- Number of Related Support Cases