Closed Bug 1349233 Opened 7 years ago Closed 7 years ago

While screen sharing on Cisco Spark (web app) the receiving end only sees a still image

Categories

(Core :: WebRTC, defect, P1)

Product:
Core
Component:
WebRTC
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla55
Tracking Flags:
Tracking Status
firefox52 --- unaffected
firefox-esr52 --- unaffected
firefox53 + wontfix
firefox54 + fixed
firefox55 --- fixed
firefox56 --- ?
firefox57 --- affected

People

(Reporter: asimonca, Assigned: jesup, NeedInfo)

References

Details

Attachments

(3 files, 1 obsolete file)

allow SSRC changes in VideoConduits
8.10 KB, patch
bwc
: review+
gchang
: approval-mozilla-beta+
Details | Diff | Splinter Review
18052363_10210001432215841_659989497_o.png
645.70 KB, image/png
Details
18674921_10210279721412897_992732295_o.png
756.48 KB, image/png
Details 
[Affected versions]:
- Aurora 54.0a2

[Affected platforms]:
- MacOS X 10.11.6, MacOS X 10.12
- Ubuntu 16.04 LTS, Ubuntu 14.04 LTS

[Steps to reproduce]:
Make sure you have 2 Cisco Spark accounts.
1. Open www.web.ciscospark.com in Aurora 54.0a2. One on a Mac and one on an Ubuntu OS.
2. Make a video call between the 2 accounts.
3. Press the "Share screen" button on either side and then click "Allow" on the doorhanger.

[Expected result]:
- The opposite side of the screen share can see the screen that was shared.

[Actual result]:
- The opposite side of the screen share sees a still image of the last frame before the screen share.

[Regression range]:
- This seems like a regression and we`ll return with more info as soon as possible.

[Additional notes]:

- Not reproducible on Windows due to bug 1337777
- Not reproducible on Mac-to-Mac connections
Hi everyone! 

Please note that this issue is reproducible between Windows 10 x64 or Windows 7 x64,using the native client, and Ubuntu 16.04, by following this steps:

1. Open the Cisco Spark Native Client on Windows 10 x64 or Windows 7 x64 (x).
2. Make a video call between the Native Client (x) and Ubuntu 16.04 x64 (y).
3. Press the “Share Screen” from the Native Client (x).
4. Observe that the screen from user (x) is displayed as frozen for user (y).
Rank: 15
Priority: -- → P1
tested locally works great.  This assumes that the Pipeline/Filter above us has already decided to send the SSRC to this conduit; this patch doesn't try to address any issues with bundled-stream-SSRC-changes.  Try is https://treeherder.mozilla.org/#/jobs?repo=try&revision=7756f969dff2263fc57e8685708541152518d11a
Attachment #8851766 - Flags: review?(docfaraday)
Assignee: nobody → rjesup
Status: NEW → ASSIGNED
Comment on attachment 8851766 [details] [diff] [review]
allow SSRC changes in VideoConduits

Review of attachment 8851766 [details] [diff] [review]:
-----------------------------------------------------------------

::: media/webrtc/signaling/src/media-conduit/VideoConduit.cpp
@@ +1837,3 @@
>                  // SSRC is set; insert queued packets
> +                // XXX This releases all packets; if we had two switches before this can run
> +                // we may drop a packet or two.  Not something I care to add more-complex-code to

But which packets will we drop? Will we drop the first couple of the newest SSRC (really bad!), or the last couple of an intermediate SSRC (not so bad at all)? If I'm reading this code right, we are likely to do the former. I think we should stomp the queue every time the ssrc changes, since everything in there is almost certainly unusable, and only drain the queue when we stabilize.
Attachment #8851766 - Flags: review?(docfaraday)
(In reply to Byron Campen [:bwc] from comment #3)
> >                  // SSRC is set; insert queued packets
> > +                // XXX This releases all packets; if we had two switches before this can run
> > +                // we may drop a packet or two.  Not something I care to add more-complex-code to
> 
> But which packets will we drop? Will we drop the first couple of the newest
> SSRC (really bad!), or the last couple of an intermediate SSRC (not so bad
> at all)? 

*If* this were to happen, we'd likely drop the first packet(s) of the last (newest) SSRC.  However, this is a *very* unlikely situation (extremely) - it would require receiving at least one packet with a new SSRC, then before we could send a runnable to MainThread and back receiving another packet with a different SSRC.  Such fast SSRC changes are virtually non-sensical for video, and in any case the code must handle packet losses, especially on the start of a stream.

> If I'm reading this code right, we are likely to do the former. I
> think we should stomp the queue every time the ssrc changes, since
> everything in there is almost certainly unusable, and only drain the queue
> when we stabilize.

While this is amazingly unlikely, it doesn't hurt us to do it that way.  Actually passing in the intermediate SSRC would be more work, but dropping the intermediate is as you note not hard.
MozReview-Commit-ID: 6PNyjLyl9L0
Attachment #8851859 - Flags: review?(docfaraday)
Attachment #8851766 - Attachment is obsolete: true
Attachment #8851859 - Flags: review?(docfaraday) → review+
Pushed by rjesup@wgate.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/e78ec594440e
allow SSRC changes in VideoConduits r=bwc
https://hg.mozilla.org/mozilla-central/rev/e78ec594440e
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
status-firefox55: affected → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla55
Do we want to get this fix in beta54?
status-firefox53: affected → wontfix
Flags: needinfo?(rjesup)
yes
Flags: needinfo?(rjesup)
Comment on attachment 8851859 [details] [diff] [review]
allow SSRC changes in VideoConduits

Approval Request Comment
[Feature/Bug causing the regression]: Webrtc.org 53 landing (bug 1250356)

[User impact if declined]: Screensharing unusable in Cisco Spark (major problem)

[Is this code covered by automated tests?]: no

[Has the fix been verified in Nightly?]: yes by us and cisco

[Needs manual test from QE? If yes, steps to reproduce]: see bug comments; easy to repro

[List of other uplifts needed for the feature/fix]: None

[Is the change risky?]: No

[Why is the change risky/not risky?]: Extends (and in ways simplifies) an earlier fix to deal with non-signaled SSRCs

[String changes made/needed]: none
Attachment #8851859 - Flags: approval-mozilla-beta?
Patch applies easily to beta.

Since this affects a major feature of Spark (and perhaps some other MCU/SFU setups), I'd love to get it into 53 as a ride-along, but lets get beta first.
Hi :asimonca, 
Can you help check if the fix is expected in the latest nightly?
Flags: needinfo?(alexandru.simonca)
Hi,
I was not able to establish a connection between 2 accounts. I don't know what happened. Attached a print screen so you can see  the issue. I used 2 regular cisco spark accounts and tried calling each other but it didn't work neither on Ubuntu 14.04 or on macOS 10.12.3, after several tries. I used the latest Nightly build on both computers. I'll try again tomorrow with other computers but it seems to be a bug that regressed from somewhere. Leaving ni? in place for tracking.
(In reply to Alexandru Simonca, QA (:asimonca) from comment #13)
> Created attachment 8859614 [details]
> 18052363_10210001432215841_659989497_o.png
> 
> Hi,
> I was not able to establish a connection between 2 accounts. I don't know
> what happened. Attached a print screen so you can see  the issue. I used 2
> regular cisco spark accounts and tried calling each other but it didn't work
> neither on Ubuntu 14.04 or on macOS 10.12.3, after several tries. I used the
> latest Nightly build on both computers. I'll try again tomorrow with other
> computers but it seems to be a bug that regressed from somewhere. Leaving
> ni? in place for tracking.

I think there was a outage today .. Check status.ciscospark.com before testing ..
Hi :asimonca,
Can you check again?
Hi :gchang,
Just checked again. I'm getting the same error when trying to establish a connection. I have used an iMac with MacOs 10.12 and an Ubuntu 14.04 laptop and I can't make a call between the 2.
Randell, any idea why Alexandru isn't able to get spark to work and verify this fix?
Just noticed that my connection problems are only on Nightly, but Beta doesn't work a whole lot better either. Between 2 Windows 10 PC's, both running the latest Beta build, I've managed to establish a call but the other caller could not see me, although the audio was running fine. I think that's bug 1337777 at play.
[Tracking Requested - why for this release]:
Critical feature for CiscoSpark
tracking-firefox53: --- → ?
tracking-firefox54: --- → ?
I realize I nominated it for tracking53 though 53 is out; this is a critical feature for CiscoSpark, one of our partners.  Once we verify it and have it 54, we should at least consider if it's an option for a 53.x ride-along.
Cisco informs me the problem is worse; it affects all 3-person or more calls.  When the server switches video streams when someone starts talking, we see an unannounced SSRC change, and the call fails.  The workaround suggested for screensharing (re-negotiate) is not practical for these sorts of high-frequency changes.

This means the Spark will be unusable until 54 ships (presuming we land this patch in 54).  This also means that we should even more strongly consider this for any 53 point release.
Flags: needinfo?(lhenry)
Track 54+ as this is a critical feature for CiscoSpark.
tracking-firefox54: ? → +
OK, let's keep that option open for 53.  Let's see if we can get a verified fix in 54.
status-firefox53: wontfix → affected
tracking-firefox53: ? → +
Flags: needinfo?(lhenry)
I've tried to test again today and I still can't make a connection between Ubuntu and Mac on Nightly. Removing ni? until this is sorted. Please contact me again when the issue is fixed on the ciscospark side.
Flags: needinfo?(alexandru.simonca)
Is this a problem Cisco needs to address?  As I understood, the problem was that Spark is switching in a different media flow (thus a new SSRC) and that wasn't handled by FF.
(In reply to Paul E. Jones from comment #25)
> Is this a problem Cisco needs to address?  As I understood, the problem was
> that Spark is switching in a different media flow (thus a new SSRC) and that
> wasn't handled by FF.

That's correct

We need to land this on beta; we've had it on central for 2 months now(!) and I've locally verified it several times.  It makes a major partner's service unusable in Firefox release; we can't have that continue in Fx54.

Paul, can you verify that Nightly/55 is working with this testcase from your perspective?
status-firefox53: affected → wontfix
Flags: needinfo?(paulej)
Flags: needinfo?(jcristau)
Flags: needinfo?(gchang)
Comment on attachment 8851859 [details] [diff] [review]
allow SSRC changes in VideoConduits

Fix a very important feature of Spark. Beta54+. Should be in 54 beta 9.
Flags: needinfo?(gchang)
Attachment #8851859 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
Flags: needinfo?(jcristau)
Flags: qe-verify+
Hello,
I've tried to test this issue again and I experienced 2 problems:
1. Using a 2013 MacBook Pro I was not able to log into the web.ciscospark.com site. After I typed in my password it went into an infinite loading screen and I couldn't get in. I used both macOS 10.12.4 and 10.11.6 and the result is the same.
Also, when I tried logging into the site with an iMac, it worked.
2. Using a 2010 MacBook Pro with macOS 10.12.4 and a Dell laptop with Ubuntu 14.04 I managed to log in and establish a connection. Neither sides of the call could see each other although the audio was working fine. Screen sharing did not work due to this issue.
Did anyone else try a connection between Ubuntu and macOS when testing this?
As Randell requested, I did test FF55 nightly.  Issue 1361206 was preventing me from testing that, but that code change is in this morning's FF55 nightly.  I tested it using Windows 10 and it worked.  I'll see if I can get a colleague to test on Mac, though I'm really surprised that logging would present an issue on one platform or the other.  Maybe there is a cache issue?
Flags: needinfo?(paulej)
I meant to say "I'm really surprised that logging in would present an issue..."
Developers tested today's FF55 nightly on Mac OS 10.12.4 on a 2015 Macbook Pro and it worked fine.
Hello. I managed to establish a connection between an iMac with macOS 10.11.6 and Ubuntu 16.04 LTS. 
Screen sharing worked for Beta 54.0b9, but not for Nightly. On Nightly I was only able to share the screen of the iMac to the Ubuntu computer but couldn't when trying it the other way around. When trying to share the screen of the Ubuntu computer I got the red notification that says: "Failed to start screen share."
Please see the attachment for the error message.
Both running nightly?
In one case I ran Beta on both and in the second case I ran Nightly on both. The Beta case worked, the Nightly one didn't when trying to share the screen from the Ubuntu computer to the iMac.
Hello,
We've tested this again on the latest Nightly 56.0a1 build (id: 20170710030203) and the issue is still reproducible on the following OS combinations:

CiscoSpark Web App

- Ubuntu 16.04 x64 + Windows 10 x86
- Mac OS X 10.13 Beta + Windows 7 x64
- Mac OS X 10.13 Beta + Ubuntu 16.04 x64

CiscoSpark Web App + CiscoSpark Native App

- Ubuntu 16.04 x64 + Windows 10 x86
- Windows 10x64 + Mac OS X 10.13 Beta
- Ubuntu 16.04 x64 + Mac OS X 10.13 Beta
For these combinations of Web App and Native App the issue is only reproducible on the Web App. The Native App works fine.
Hello,
   I tried out Firefox 54 and 56 nightly on unstable.ciscospark.com. It looks like firefox nightly is generating the m video line with 0 port when we try to do screen sharing.


m=video 0 UDP/TLS/RTP/SAVPF 120 121 126 97

c=IN IP4 172.20.2.157

a=bundle-only

a=sendonly

a=end-of-candidates

a=extmap:1 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time

a=extmap:2 urn:ietf:params:rtp-hdrext:toffset

a=fmtp:126 profile-level-id=42e01f;level-asymmetry-allowed=1;packetization-mode=1

a=fmtp:97 profile-level-id=42e01f;level-asymmetry-allowed=1

a=ice-pwd:321203535e733fb980000d9507a39595

a=ice-ufrag:aa6c59d0

a=mid:sdparta_2

a=msid:{70d6507f-3023-c64b-95e7-aafc7c392fba} {02732395-5cd2-da48-bd04-38240b470994}

a=rtcp:50256 IN IP4 172.20.2.157

a=setup:actpass

a=ssrc:4266434141 cname:{ce9ceb40-95ce-824f-9d92-5f8ff7547684}

Firefox 54.0.1 works fine for screen sharing on mac
Flags: needinfo?(rjesup)
We need more than just a snippet of SDP.  What actions were performed? 
port 0 (typically in an answer) means "we reject this stream"
What calls were made?  Who made the offer/re-offer?  Was a screencapture MediaStream added to the peerconnection?

Normally I'd expect to see '9' there.  Can you do your test, then open a tab to about:webrtc and "Save" the data there and attach or email it?

Thanks
Flags: needinfo?(rjesup) → needinfo?(arungane)
Have sent an email to you with the sdp and logs. 
The action was create offer for screen sharing on a existing peerconnection which has already connected with a audio and video m line.

Scenario: 1) Make a audio video call from firefox to firefox on native client 
2) After successful connect try doing screen sharing .
3) The offer SDP has one audio m line  and the 2 video m line(video and screenshairng ) , The 2nd m line has port 0 on the offer
Flags: needinfo?(arungane)
Hi Jesup, Arun, is this issue still reproducible? Do you have the data that you need to investigate this further? This bug was highlighted in the WebRTC sign off report by Softvision. It seems severe enough. Thanks!
Flags: needinfo?(rjesup)
Flags: needinfo?(arungane)
Reminder to have a look at this.
Flags: needinfo?(drno)
(In reply to arun ganeshan from comment #39)
> Have sent an email to you with the sdp and logs. 
> The action was create offer for screen sharing on a existing peerconnection
> which has already connected with a audio and video m line.
> 
> Scenario: 1) Make a audio video call from firefox to firefox on native
> client 
> 2) After successful connect try doing screen sharing .
> 3) The offer SDP has one audio m line  and the 2 video m line(video and
> screenshairng ) , The 2nd m line has port 0 on the offer

The offer from Firefox is actually spec compliant. That m-section is offered as a=bundle-only (which causes the port to be set to 0), because the default bundle policy is "balanced" which results in this behavior. https://www.w3.org/TR/webrtc/#rtcbundlepolicy-enum
As Spark (or more precisely Linus in this case) does not support bundle the application, so the Spark frontend code for the browsers, needs to set the bundle policy to "max-compat" instead. I'm pretty sure if that gets done you will get a new m-section with port 9 and proper ICE candidates.

So this is not a Firefox bug, but a client side bug.
Flags: needinfo?(rjesup)
Flags: needinfo?(drno)
Blocks: 1394602
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: