1023394 - Connection issues using Loop - no media, or no connection established

Status: RESOLVED INCOMPLETE

(Core :: WebRTC, defect)

Description

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

Attachment: newest_about_webrtc

I tried a series of calls in a local (opt) inbound pull made this morning on Linux, talking to a Win32 Nightly 6/10 (with loop). 

Note: I may have mis-remembered a call or two attempted in here; I tried a number of calls.

I clicked on a loop link from the win32 side.
I got no connection. No request for camera (and no icon in the URLbar).  about:webrtc showed nothing (no peerconnections).  Connection Logs there did show entries and what appeared to be responses

On wireshark, I saw DNS traffic, and then STUN/TURN traffic, then nothing.

I restarted, and I tried again.  Similar, but it appears I had DNS traffic but no stun/turn traffic, and these in the logs:
Skipping SOURCE-ADDRESS
Skipping CHANGED-ADDRESS
Translating obsolete XOR-MAPPED-ADDRESS type

Happened a couple of times.

After a break, I reversed things, and generated a URL to be clicked on by the other side.  This worked.  A/V in both directions.  I ended it and tried a new URL generated at the win32 side. Clicked on it in linux, worked this time.

The Timecards for the failed ones look like this:
Timecard created 1402412723.787786

 Timestamp   | Delta       | Event                          | File                         | Function                 
=======================================================================================================================
    0.000028 |    0.000028 | Constructor Completed          | PeerConnectionImpl.cpp:509   | PeerConnectionImpl       
    0.000417 |    0.000389 | Initializing PC Ctx            | PeerConnectionImpl.cpp:818   | Initialize               
    0.003276 |    0.002859 | Done Initializing PC Ctx       | PeerConnectionImpl.cpp:824   | Initialize               
    0.003694 |    0.000418 | Generating DTLS Identity       | PeerConnectionImpl.cpp:864   | Initialize               
    0.058869 |    0.055175 | Done Generating DTLS Identity  | PeerConnectionImpl.cpp:867   | Initialize               
    0.065955 |    0.007086 | Ice gathering state: gathering | PeerConnectionImpl.cpp:2042  | IceGatheringStateChange_m
    0.384223 |    0.318268 | Ice gathering state: complete  | PeerConnectionImpl.cpp:2045  | IceGatheringStateChange_m
   13.417936 |   13.033713 | Destructor Invoked             | PeerConnectionImpl.cpp:515   | ~PeerConnectionImpl

Comment 1

[Byron Campen [:bwc]]

This is what I would expect to happen if nothing ever called createOffer or setRemoteDescription. We start gathering candidates as soon as the PC is created, and the STUN traffic you saw was almost certainly binding requests sent to gather server reflexive candidates, and probably also allocate requests to gather relay candidates.

Comment 2

[Mark Banner (:standard8)]

I suspect this is due to failures in the SDK. Unfortunately we're not reporting those to the user at the moment (bug 1023394), and you need to look in the web console (or possibly browser console, if you're receiving the call) to get the errors from there.

Comment 3

[Mark Banner (:standard8)]

(In reply to Mark Banner (:standard8) from comment #2)
> I suspect this is due to failures in the SDK. Unfortunately we're not
> reporting those to the user at the moment (bug 1023394), and you need to
> look in the web console (or possibly browser console, if you're receiving
> the call) to get the errors from there.

That's meant to be bug 1023507