Currently in Nightly (05/30), one is not able to successfully join an active room on conversat.io (or view other active party members); as in one will not see the other party on desktop or vice versa. Using Nightly (05/30) on desktop (my MacBook Air w/Facetime HD Camera), I established a room. On Android, I joined the room, accepted microphone and camera and did not see my laptop as an active member. -- HTC One (Android 4.1.2) Nightly (05/30)

Is this problem only between Android and Desktop, or also on Desktop->Desktop?

Using Chrome Beta on Android to join the same room, I see my device as an active party in Nightly on desktop; so in this case, Chrome works.

Desktop ↔ Desktop works. Using Chromium (Version 29.0.1523.0 (202839)) and Nightly (05/30) on OS X, they work as expected (albeit I'm testing one camera, I see the other party join and hear an audible sound).

Chromium ↔ Fennec, semi-works. On desktop, I get a black large black square in the middle of my screen from the Android party member, in Fennec, I do not see the other party member at all.

I hear the audible alert that parties have joined on Fennec (Android) and Fennec (Nightly), I just dont see either party visible on-screen on my device and on desktop.

Couple of questions: 1. Can you get a logcat with NSPR logs included with signaling:5,mtransport:5 specified the log modules on Android? 2. Does this same bug reproduce with http://apprtc.appspot.com/? 3. Was this bug reproduced in a 1 to 1 video chat (i.e. 2 people talking to each other)? Or are there more than 2 people involved?

(In reply to Jason Smith [:jsmith] from comment #6) See attached > 2. Does this same bug reproduce with http://apprtc.appspot.com/? This site does work although I dont know to what extent classifies as working 'correctly' without testing it some more. On desktop, Nightly, I do not see my device as an member of the room (split-view) as a second participant at all. This is easy to reproduce. Create a room on desktop and join it in Fennec ― that is all that is required. On my Android device, I do actually see myself alongside my desktop (in a split-view). In this case, Android seems to be working as expected. I would have expected to see a split view of my Android device, the second participant, in view on desktop as well. In addition, the site exposes a status bar with the message 'connecting...' status on the bottom bar if that means anything in this case. Easy to reproduce again; create a room on desktop, join it on Fennec. > 3. Was this bug reproduced in a 1 to 1 video chat (i.e. 2 people talking to > each other)? Or are there more than 2 people involved? I am just testing against my Galaxy S4/HTC One/Nexus 4 and Nightly on my MacBook Air, so 1:1. All devices expose the same issue here.

Randell - Any ideas why the call is failing given the log shown here?

Not a blocker for pref on because this isn't a problem with all apps, but we need to understand and potentially fix the issue before we ship on why this app isn't working for WebRTC calls.

Tried with gupshup between desktop and Nexus10 nightly 6/21 and it works. Haven't tried the other sites mentioned as not working yet

This definitely seems like a blocker to me. Just because it occasionally works...

Update Running Nightly (07/09) on desktop and Android with https://apprtc.appspot.com - this site is now working as intended. I can see both Android and Desktop on Android device and on desktop. Conversat.io, now talky.io still exhibits the original problem. I do not see any connected peers. I can hear audible tones as clients connect so that makes me suspect that it's a site content problem now. Can anyone confirm?

>Conversat.io, now talky.io still exhibits the original problem. I do not see any connected >peers. I can hear audible tones as clients connect so that makes me suspect that it's a site >content problem now. Can anyone confirm? talky.io just worked fine for me with today's Nightly build between my Nexus 10 and Macbook Pro. Could you try again and detail which build and hardware you're trying on Android?

I am using Nightly on Mac OS X (10.8.4) (07/12), and Nightly (07/12) on my Nexus 4 (Android 4.2.2), Samsung Galaxy S4 (Android 4.3), and HTC One (Android 4.2.2) and in all cases I never see any connected peers both on desktop and on mobile whatsoever when Firefox on desktop and Firefox on Android are connecting to each other. On all devices: When I connect Chrome (v.28) on desktop to Nightly on Android (07/12), I get a black-filled box from the connected peer on desktop and nothing shown in the mobile browser at all. When I connect Chrome (v.28) on mobile to Nightly (07/12) on desktop, I *do* see the connected mobile peer on desktop working correctly, but no connected peer in their mobile browser.

I have yet to see a working conversation seeing connected clients with each other in view other than between Chrome (v.28) connecting with Chrome (v.28) between desktop and mobile (Android).

Should I try pinging the developer of talky.io about this?

The JS code of talky.io is obfuscated, so we're not going to be able to diff what they're doing against apprtc. If they are interested in assisting in diagnosing what might be going on, that would be great.

I just emailed my contact to see if we can get help on what's failing on the talky.io side to cause the WebRTC call to fail.

I tried it with nightly (android) on an Nexus 10, and a inbound build on desktop. Slightly slow to show video on the N10, but connected. Tried again with nightly on a Samsung Galaxy S4 - worked fine (better than the N10 in fact). These are all behind the same firewall. My guess is it's a STUN/ICE issue with the wifi network and/or main nat it's behind, but that's just a guess. Aaron: are your devices on the same 192.168 network? Do two desktops connect well on that?

Can we get a wireshark capture on the desktop side at least? If you have the hardware/etc setup, can we get a capture of the wireless traffic? (Some type of wireless capture-all-traffic tool)

Comment on attachment 774811 [details] Desktop to Android Call Console Log - Initiator Side (Fails) NSPR_LOG_MODULES=signaling:5,mtransport:5 I assume Android is on the same subnet? If you're in MV, this may not be a given.

(In reply to Randell Jesup [:jesup] from comment #21) > Aaron: are your devices on the same > 192.168 network? Do two desktops connect well on that? Yes. No difference desktop (MacBook Air) ↔ desktop (MacBook Pro), running Nightly (07/12) on both - I can hear the client connect through their audible sound, no visuals on both ends beyond the self-preview.

Primary dev on Talky.io here. Happy to try to help. I've got a nexus 4 available what do you need me to do?

I'm seeing this code firing from the NSPR log shown: http://mxr.mozilla.org/mozilla-central/source/media/mtransport/transportlayerdtls.cpp#624 18140[f0f530]: Flow[70ac2ea74ce94e2d:1,rtcp(none)]; Layer[dtls]: Lower lower experienced an error That doesn't look friendly.

(In reply to henrik from comment #27) > Primary dev on Talky.io here. Happy to try to help. I've got a nexus 4 > available what do you need me to do? Sent you instructions over email on how to reproduce this. What would be helpful to know is that when you reproduce this bug, what part of the talky.io code is failing. Specifically, what WebRTC API call is failing (e.g. setRemoteDescription, setLocalDescription) in the talky.io code? Or generally, what failing behavior are you seeing on the talky.io side when this bug reproduces?

So, it actually worked for me: http://cl.ly/image/2g3c0E0T300V That's FF Nightly on Nexus 4 bottom right, Chrome Stable Left, FF Nightly (tried stable too) on the right. (pretty badass if you ask me) I think STUN is failing and thus not connecting. We're in the process of deploying a TURN server too, which should cover the cases where STUN fails.

Any way to confirm this?

Interesting point worth noting - so this works for me on when the phone and desktop machine are on the same wifi network. But it fails 100% for me when my phone is on 4G and my desktop machine is on wifi. I've also seen this reproduce on my home network, so I don't think this is a Mozilla Mt View office-like issue.

4G cell providers may block STUN. They also are very likely to use a symmetric NAT. If your other machine is behind a symmetric NAT, then it will fail 100% of the time. That would be an artifact of the network topology, not android vs desktop. The fact that it works then they're on the same wifi network strongly implicates NATs, not android vs desktop. If it's failing in a scenario that doesn't involve 4g (or 3g), try a laptop/desktop in place of the android phone (i.e. on the same network the android phone was on).

Aaron said he reproduced this on wifi, so I'll let him comment more on his network setup to see if it might be causing STUN to fail.

How would one check that? I'm also able to reproduce this with an Android device on LTE and a laptop on 3G (USB Stick). As well, laptop WiFi to Android LTE, and Android WiFi to laptop 3G, Android LTE to laptop WiFi. All the same result as I've mentioned.

Is this page using the default STUN servers, or providing their own? I.e., might this be a dup of bug 888274?

(In reply to Timothy B. Terriberry (:derf) from comment #37) > Is this page using the default STUN servers, or providing their own? I.e., > might this be a dup of bug 888274? From what I'm seeing, it looks they are providing their own. iceServers: [{"url": "stun:stun.l.google.com:19302"}] At: https://github.com/HenrikJoreteg/SimpleWebRTC/blob/master/simplewebrtc.bundle.js#L675

In that case, it's not going to work b/c of bug 888274

Original issue still exists on Nightly with patch from bug 888274

Did some regression range hunting on this - this reproduces before and after bug 888274. I think Ekr is right that this is a separate issue, potentially related to a comment I remember the developer mentioning about pushing a new deployment for talky.io. I'm going to open a separate bug for this.