Status

()

defect
RESOLVED DUPLICATE of bug 1528352
4 months ago
4 months ago

People

(Reporter: jimmy.xu, Unassigned)

Tracking

(4 keywords)

65 Branch
Points:
---

Firefox Tracking Flags

(firefox-esr60 unaffected, firefox65 wontfix, firefox66 ?, firefox67 ?)

Details

Attachments

(7 attachments)

Reporter

Description

4 months ago

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_6) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/12.0 Safari/605.1.15

Steps to reproduce:

  1. use WebRTC peer connection to establish a call
  2. Send INVITE with the SDP created by WebRTC
  3. Set remote SDP when receive SDP from server side

Actual results:

Call is connected by there's no audio. Firefox report "ICE failed, add a TURN server and see about:webrtc for more details".

SDP send to server:

v=0

o=mozilla...THIS_IS_SDPARTA-65.0.1 6417442376257969630 0 IN IP4 0.0.0.0

s=-

t=0 0

a=sendrecv

a=fingerprint:sha-256 E7:EA:7D:D7:68:78:88:7D:47:BB:6F:85:62:CD:F6:70:5C:81:96:3E:C1:08:35:EF:91:A2:E9:AD:46:F6:CD:37

a=group:BUNDLE 0

a=ice-options:trickle

a=msid-semantic:WMS *

m=audio 47120 UDP/TLS/RTP/SAVPF 109 0 8 101

c=IN IP4 98.124.135.226

a=candidate:0 1 UDP 2122252543 10.32.60.23 60862 typ host

a=candidate:0 2 UDP 2122252542 10.32.60.23 60863 typ host

a=candidate:1 1 UDP 1686052863 98.124.135.226 47120 typ srflx raddr 10.32.60.23 rport 60862

a=candidate:1 2 UDP 1686052862 98.124.135.226 56400 typ srflx raddr 10.32.60.23 rport 60863

a=sendrecv

a=end-of-candidates

a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level

a=extmap:2/recvonly urn:ietf:params:rtp-hdrext:csrc-audio-level

a=extmap:3 urn:ietf:params:rtp-hdrext:sdes:mid

a=fmtp:109 maxplaybackrate=48000;stereo=1;useinbandfec=1

a=fmtp:101 0-15

a=ice-pwd:a6999e6ef47117e0744b3e7ac26a7312

a=ice-ufrag:e1a7be1d

a=mid:0

a=msid:{e6bd40d3-f365-4976-bc30-f39c852f8b1c} {28878434-93cf-4f59-9e13-0aa288933757}

a=rtcp:56400 IN IP4 98.124.135.226

a=rtcp-mux

a=rtpmap:109 opus/48000/2

a=rtpmap:0 PCMU/8000

a=rtpmap:8 PCMA/8000

a=rtpmap:101 telephone-event/8000

a=setup:actpass

a=ssrc:1495750153 cname:{2f75ef64-104c-4e65-878b-a57c0f9388cb}

SDP return by server:

v=0

o=- 3963804552 3803115332 IN IP4 10.74.3.85

s=SmcSip

c=IN IP4 10.74.3.85

t=0 0

m=audio 23998 RTP/SAVPF 109 101

a=rtpmap:109 OPUS/48000/2

a=fmtp:109 useinbandfec=1

a=rtpmap:101 telephone-event/8000

a=fmtp:101 0-15

a=sendrecv

a=rtcp:23998

a=rtcp-mux

a=setup:active

a=fingerprint:sha-1 C4:82:F6:92:D0:C1:67:62:9E:98:EB:1E:2D:B7:B2:41:E2:3D:69:0D

a=ice-ufrag:dyI5BnB3

a=ice-pwd:9C0rLcPUEtc5eKlldGmapuL7uD

a=candidate:sWFW0Eme6NuVFdCy 1 UDP 2130706431 10.74.3.85 23998 typ host

Expected results:

Call should be connected and user can hear voice.
This issue is NOT always reproducible. The chance to reproduce it is about 1/6
This issue is occurred on Firefox 65 Windows. We also try with Firefox 62 but cannot reproduce it.
This issue cannot be reproduced on Safari or Chrome.

Reporter

Comment 1

4 months ago

Comment 2

4 months ago

(In reply to Jimmy from comment #0)

This issue is occurred on Firefox 65 Windows. We also try with Firefox 62 but cannot reproduce it.

It would be very useful if you could find the regression range.
https://mozilla.github.io/mozregression/quickstart.html

Has Regression Range: --- → no
Component: Untriaged → WebRTC: Networking
Product: Firefox → Core

Actually, with an intermittent failure like this, finding a regression range can be very tricky. What would help me more is a wireshark capture of the network traffic.

Flags: needinfo?(jimmy.xu)
Reporter

Comment 4

4 months ago

I tried with regression range.

It target to build: c35dea45. build time 2018-11-29 05:38:13.

Flags: needinfo?(jimmy.xu)
Reporter

Comment 5

4 months ago
Posted image regression-gui.jpg
Reporter

Comment 6

4 months ago

(In reply to Byron Campen [:bwc] from comment #3)

Actually, with an intermittent failure like this, finding a regression range can be very tricky. What would help me more is a wireshark capture of the network traffic.

The SIP messages are transmitted via WSS. I think it's a issue when processing remote SDP. I've commented the build version above. Maybe you can check if there're anything changed in that commit relate to ICE negotiation.

Thanks

Regards
Jimmy

Jimmy, thank you for running the regression tool. Unfortunately, it looks like you got a bad result, commit c35dea45 enabled some tests in our CI and could not have caused the problem you are seeing. Could you please attempt to get some wireshark logs? Thanks!

Flags: needinfo?(jimmy.xu)

Comment 8

4 months ago

I see another "bad" revision in the screenshot on autoland, which is webrtc related:

https://hg.mozilla.org/mozilla-central/log?rev=7d539c01

For the most part, this change only loosened some packet filtering restrictions, so I would not expect it to cause any problem. I would need to see a packet capture to have a better idea of what is happening here.

Reporter

Comment 9

4 months ago
Flags: needinfo?(jimmy.xu)
Reporter

Comment 10

4 months ago
Reporter

Comment 11

4 months ago

(In reply to Byron Campen [:bwc] from comment #8)

I see another "bad" revision in the screenshot on autoland, which is webrtc related:

https://hg.mozilla.org/mozilla-central/log?rev=7d539c01

For the most part, this change only loosened some packet filtering restrictions, so I would not expect it to cause any problem. I would need to see a packet capture to have a better idea of what is happening here.

Hi Byron,

Thanks for look into it. It's occasional bug. But I'm almost certain one commit between 11/29 - 11/30 cause it. I've update a new log file together with PCAP file again. Please have a look

Thanks
Regards

Jimmy

In the PCAP file, I see Firefox being sent a STUN request, and sending a response, which then gets an ICMP error. This is pretty unusual, and hints that there is some problem with the network (either a NAT is not allowing UDP return traffic at all, or maybe there's a firewall getting in the way, or there is only one-way routeability between the two networks).

I do not see a retransmission of the request, which may be a bug in the implementation on the other end.

I also do not see Firefox sending any ICE checks of its own, which hints that this STUN transaction occurs before the answer has been set on Firefox. Bug 1507700, which landed in the date range you mention in comment 11, is a change that allows pre-answer requests to reach the ICE stack in Firefox. Before that change, the STUN request would have been dropped.

It is possible there is some bug in the handling of pre-answer requests. Could you attach the output of the "Save Page" button at the top of about:webrtc for the failure case?

Flags: needinfo?(jimmy.xu)
Reporter

Comment 13

4 months ago

info in about:webrtc for failure case

Flags: needinfo?(jimmy.xu)
Reporter

Comment 14

4 months ago

pcap for failure case

Unfortunately, I'm not seeing a whole lot that is illuminating in that logfile. It is possible that you're hitting bug 1528352, which just had a fix landed and should be in the next nightly build. If you want to try the build from the testing infrastructure with the fix, that'll be:

Win32: https://queue.taskcluster.net/v1/task/TKz8E11IQPySS9tYUdd_0A/runs/0/artifacts/public/build/install/sea/target.installer.exe

Win64: https://queue.taskcluster.net/v1/task/QFpE17YkQw-SSUVsBsqxfQ/runs/0/artifacts/public/build/install/sea/target.installer.exe

Updated

4 months ago
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(jimmy.xu)

The fix for bug 1528352 is in nightly now, too.

Reporter

Comment 17

4 months ago

Sorry for the delayed response. I was on vocation last week.

Tried today with Win32: https://queue.taskcluster.net/v1/task/TKz8E11IQPySS9tYUdd_0A/runs/0/artifacts/public/build/install/sea/target.installer.exe

Cannot reproduce anymore.

Thank you guys for observing this issue!

Flags: needinfo?(jimmy.xu)
Status: NEW → RESOLVED
Closed: 4 months ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1528352

Thanks for confirming!

You need to log in before you can comment on or make changes to this bug.