1455374 - Video is not provided during a web.ciscospark call

Status: REOPENED

(Core :: WebRTC: Audio/Video, defect, P2)

Description

[Iulia Cristescu, QA [:JuliaC] (away, please needinfo? [e-mail])]

[Note]:
- This issue is triggered only on calls between certain OS and build combinations: 
  - calls between macOS 10.12 (Firefox Beta) and Ubuntu 16.04 (Firefox Beta) 
  - calls between macOS 10.12 (Firefox Beta) and Ubuntu 16.04 (Firefox Nightly)
  - calls between macOS 10.12 (Firefox Release) and Ubuntu 16.04 (Firefox Nightly) 
  - calls between macOS 10.12 (Firefox Release) and Ubuntu 16.04 (Firefox Release)
  - calls between macOS 10.12 (Firefox Beta) and Windows 10 x64 (Firefox Nightly) 

[Affected versions]:
- Nightly 61.0a1 (2018-04-19)
- 60.0b13 build1 (20180416175245)
- 59.0.2 build1 (20180323154952)

[Affected platforms]:
- Windows 10 x64
- macOS 10.12

[Steps to reproduce]:
1. Launch Firefox
2. Log in to http://web.ciscospark.com/ using valid credentials on station (A) and station (B)
3. Perform a call between station (A) and station (B) 

[Expected result]:
- The call is successfully started
- Both audio and video components are provided for caller and callee 

[Actual result]:
- Video is missing for both caller and callee

[Regression range]:
- We will provide more details as soon as possible

[Additional notes]:
- The issue is not reproducible on calls between two ciscospark native clients

Comment 1

[Nils Ohlmeier [:drno]]

Paul, are you aware of this problem?

Comment 2

[Paul E. Jones]

No, I wasn't aware.  We need to FF endpoints for this or one Spark Native and one FF?

Comment 3

[Paul E. Jones]

I should have asked, "we need two FF endpoints..."  Sorry for the typo.

I can test two Windows clients, but I'm confused if Mac is a required component.  I can look into why the issue exists if I have a tracking ID.  Easiest way for me to debug it is perhaps place a call to me (let me know so I can be sure I'm logged into FF) and I can then pull call logs to investigate.

Comment 4

[Dan Minor [:dminor]]

Leaving a needinfo for Paul's questions.

Comment 5

[Iulia Cristescu, QA [:JuliaC] (away, please needinfo? [e-mail])]

(In reply to Paul E. Jones from comment #2)
> No, I wasn't aware.  We need to FF endpoints for this or one Spark Native
> and one FF?

As I already mentioned in comment 0, we reproduced this issue during calls between 2 Firefox endpoints. We will try to see if the issue is reproducible between one native client and a Firefox endpoint as soon as possible.

Comment 6

[Paul E. Jones]

(In reply to Iulia Cristescu, QA [:JuliaC] from comment #5)
> (In reply to Paul E. Jones from comment #2)
> > No, I wasn't aware.  We need to FF endpoints for this or one Spark Native
> > and one FF?
> 
> As I already mentioned in comment 0, we reproduced this issue during calls
> between 2 Firefox endpoints. We will try to see if the issue is reproducible
> between one native client and a Firefox endpoint as soon as possible.

Comment 0 suggested that the issue is only seen if one endpoint is on MacOS 10.12.  That's what I wanted to get clarity on, since I do not personally have a way to test that.  I can test on Windows and would be happy to have a test call with you so I can then get the info I need to pull the log files.

Comment 7

[Iulia Cristescu, QA [:JuliaC] (away, please needinfo? [e-mail])]

Didn't manage to reproduce the issue anymore using the OS and the latest build combinations mentioned in comment 0. Therefore this can be considered as a temporary site issue. Will keep an eye on it, in case it will be reproducible again.

Comment 8

[Ciprian Georgiu [:ciprian_georgiu], Release Desktop QA]

This issue started to occur again on Beta 61.0b13 (20180611134439) and latest Nightly 62.0a1 (2018-06-14). We've encountered this bug mentioned in comment 0, on calls between macOS 10.12 with Windows 10 x64 and Ubuntu 16.04 x64.

Reopening this issue given the above.

Comment 9

[arun ganeshan]

(In reply to Ciprian Georgiu, QA [:ciprian_georgiu] from comment #8)
> This issue started to occur again on Beta 61.0b13 (20180611134439) and
> latest Nightly 62.0a1 (2018-06-14). We've encountered this bug mentioned in
> comment 0, on calls between macOS 10.12 with Windows 10 x64 and Ubuntu 16.04
> x64.
> 
> Reopening this issue given the above.

just to confirm. What is the end result do you see ? . Assuming alice on bob are on call and does it lead to black screen ?.
It could be a DTLS issue due to network . Can you click the support page and upload logs and send your user ID to have a look at the server side .

You can 1:1 me on [e-mail]

Comment 10

[Iulia Cristescu, QA [:JuliaC] (away, please needinfo? [e-mail])]

Redirecting the needinfo to Ciprian, as he managed to reproduce the issue on the latest Firefox builds and therefore is able to provide up to date info.

Comment 11

[Ciprian Georgiu [:ciprian_georgiu], Release Desktop QA]

(In reply to arun ganeshan from comment #9)
...
> just to confirm. What is the end result do you see ? . Assuming alice on bob
> are on call and does it lead to black screen ?.

Yes, it leads to a black screen for both caller and calle, although the audio works as expected.

> It could be a DTLS issue due to network . Can you click the support page and
> upload logs and send your user ID to have a look at the server side .
> 
> You can 1:1 me on [e-mail]

I'll just go ahead and remove the ni? since I already provided the logs during the call we had.

Comment 12

[arun ganeshan]

It looks like the firefox didnt generate the H264 codec in the SDP when the call was made. Are you trying to spin a firefox instance all the time when you try to make a call or it happens all the time ?. I think firefox team help us to understand why the openH264 was not downloaded in time

Comment 13

[arun ganeshan]

you can use this site to check if the codec parameters are getting generated https://webrtc.github.io/samples/src/content/peerconnection/munge-sdp/

Comment 14

[Randell Jesup [:jesup] (needinfo me)]

Note: a fresh firefox profile won't have OpenH264 for a minute or so after starting... see Addons (about:addons) to see if the OpenH264 plugin is installed and not disabled.

If we don't have H264 we won't offer (or accept) it