User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:63.0) Gecko/20100101 Firefox/63.0 Build ID: 20180927143327 Steps to reproduce: Open TextNow website (https://www.textnow.com/) on a Windows 10 64-bit PC in latest Firefox 63, login to your phone account, enable use of an attached USB or built-in microphone. If you don't have a free phone account, sign up and get free North American phone number, unlimited Windows web browser and/or Android app calling and texting. Try to dial your another mobile, VoIP, or landline local number. Then try to dial your new TextNow number from another phone. The Call Received popup shows up, but clicking Accept button results in connection with no audio. Actual results: The phone rings, but when picked app, the browser doesn't connect to webrtc audio stream, the mic and speaker signals are not received by the parties. It get broken in latest 1-2 weeks Firefox 63 beta releases, but worked before. Expected results: Upon receiving or sending ring, and accepting the call, the parties should hear each other. It works on Chrome and MS Edge with the same system and Firewall settings.

To clarify, you login to the site and dial any local number from TextNow webpage, and get connected without audio in and out. Or, you login to TextNow, and then dial your TextNow number from any other phone, click Accept in the popup window, and get half "ass" connected without audio in and out. Was working well until a week ago.

WebRTC in Firefox and Microphone are both enabled as I checked, without it the TextNow website can't get "Ready" to send and receive calls.

Nils, who should take a look at this?

It's not clear to me whether this is a Firefox bug. You might get more traction by filing this issue on https://webcompat.com/. (And I cannot attempt to repro because it's unavailable in europe)

Reported on webcompat, bug https://webcompat.com/issues/19443

Can you please provide us with a copy of about:webrtc after such failed call?

The above bug may or may not be related to WebRTC. I'm not an expert on this. Will post several logs here: 1. Call to TextNow number from another phone. Had to hangup due to no normal call connection. Default log: (registry/INFO) insert 'ice' (registry) succeeded: ice (registry/INFO) insert 'ice.pref' (registry) succeeded: ice.pref (registry/INFO) insert 'ice.pref.type' (registry) succeeded: ice.pref.type (registry/INFO) insert 'ice.pref.type.srv_rflx' (UCHAR) succeeded: 0x64 (registry/INFO) insert 'ice.pref.type.peer_rflx' (UCHAR) succeeded: 0x6e (registry/INFO) insert 'ice.pref.type.host' (UCHAR) succeeded: 0x7e (registry/INFO) insert 'ice.pref.type.relayed' (UCHAR) succeeded: 0x05 (registry/INFO) insert 'ice.pref.type.srv_rflx_tcp' (UCHAR) succeeded: 0x63 (registry/INFO) insert 'ice.pref.type.peer_rflx_tcp' (UCHAR) succeeded: 0x6d (registry/INFO) insert 'ice.pref.type.host_tcp' (UCHAR) succeeded: 0x7d (registry/INFO) insert 'ice.pref.type.relayed_tcp' (UCHAR) succeeded: 0x00 (registry/INFO) insert 'stun' (registry) succeeded: stun (registry/INFO) insert 'stun.client' (registry) succeeded: stun.client (registry/INFO) insert 'stun.client.maximum_transmits' (UINT4) succeeded: 7 (registry/INFO) insert 'ice.trickle_grace_period' (UINT4) succeeded: 5000 (registry/INFO) insert 'ice.tcp' (registry) succeeded: ice.tcp (registry/INFO) insert 'ice.tcp.so_sock_count' (INT4) succeeded: 0 (registry/INFO) insert 'ice.tcp.listen_backlog' (INT4) succeeded: 10 (registry/INFO) insert 'ice.tcp.disable' (char) succeeded: \000 +++++++ END ++++++++

2. Default session log. It looks like no audio candidates selected

That was calling from a TextNow number to another phone number.

3. WebRTC lo in Debug Mode: empty file 0KB

Important thing is - it was working well for the last 2 years until a week or two ago. Not sure, whether it was the website or FF changes that triggered the bug, since both keeps evolving.

(In reply to arnymars from comment #11) > Important thing is - it was working well for the last 2 years until a week > or two ago. Not sure, whether it was the website or FF changes that > triggered the bug, since both keeps evolving. Do you know if it is still working with Firefox 62 (Release)? I'm asking because we had to make some things more strict in Firefox 63 (Beta), which caused problems with other services. Although from the logs you provided it doesn't look like that is the problem here.

Looks like your Firefox is not providing any ICE candidates, which is odd. Did you by any chance install an add blocker like Ghostery etc, or made settings in an existing add blocker more strict?

I use FF 63 beta for awhile, and it was always working well with TextNow. I've uBlock Origin installed, but its switched off on TextNow page. I also tried to delete uBlock and "Disable WebRTC" addons, but no improvement. Both were installed for a long time, never affected calls. You ask me for more info, but you can try it yourself too. Even if you leave in Europe, try getting 2 TextNow free numbers, and call from FF to Chrome using these 2 numbers.

Or just get one TextNow number, and call from FF any toll free US number 1800...

TextNow service is very important, as its about the only one in North America providing free numbers, calling and texting within USA and Canada, plus using WebRTC for privacy.

This is the remote offer which gets set by TextNow: v=0 o=Flashphoner 0 1538801489728 IN IP4 10.2.40.36 s=- t=0 0 a=sendrecv m=audio 46454 RTP/SAVPF 111 0 101 3 c=IN IP4 10.2.40.36 a=candidate:2 1 udp 2130706431 10.2.40.36 46454 typ host a=candidate:2 2 udp 2130706431 10.2.40.36 46454 typ host a=candidate:1 1 udp 1694498815 34.199.140.44 46454 typ srflx raddr 10.2.40.36 rport 46454 a=candidate:1 2 udp 1694498815 34.199.140.44 46454 typ srflx raddr 10.2.40.36 rport 46454 a=sendrecv a=end-of-candidates a=fingerprint:sha-256 20:10:60:4E:E0:43:85:E1:40:44:90:7E:6D:8A:F1:94:03:39:B6:3A:00:67:D0:A4:33:C3:F1:73:FE:38:E6:5A a=fmtp:101 0-16 a=ice-pwd:2r36ulqejrncmgg7o097iv1orp a=ice-ufrag:RTC-549a57d2-43c6-1237-b58b-0cc47abdbe02cc7u51cp3relph a=ptime:20 a=rtcp:46454 IN IP4 10.2.40.36 a=rtcp-mux a=rtpmap:111 opus/48000/2 a=rtpmap:0 PCMU/8000 a=rtpmap:101 telephone-event/8000 a=rtpmap:3 gsm/8000/1 a=setup:actpass a=ssrc:956968218 cname:rtp/audio/RTC-549a57d2-43c6-1237-b58b-0cc47abdbe02 As you can see it's missing a=mid. Firefox then creates this answer: v=0 o=mozilla...THIS_IS_SDPARTA-63.0 1348683840975801450 0 IN IP4 0.0.0.0 s=- t=0 0 a=fingerprint:sha-256 39:51:DE:85:56:59:33:EF:0B:0B:78:EE:71:98:2A:C7:40:A2:FA:70:30:EA:70:FC:0A:80:81:FE:5B:75:51:C7 a=ice-options:trickle a=msid-semantic:WMS * m=audio 9 RTP/SAVPF 111 101 c=IN IP4 0.0.0.0 a=sendrecv a=fmtp:111 maxplaybackrate=48000;stereo=1;useinbandfec=1 a=fmtp:101 0-15 a=ice-pwd:e01597aa7dea3f4df0ce2264e6357e97 a=ice-ufrag:14aed990 a=msid:{8a7a9a28-9f2a-c742-8b0d-2baee381532b} {0e712840-d4d8-b943-b7ba-98ced8a9980b} a=rtcp-mux a=rtpmap:111 opus/48000/2 a=rtpmap:101 telephone-event/8000/1 a=setup:active a=ssrc:432832615 cname:{3762dc06-9a26-9043-8f0a-ee44fa0c1033} It is missing an MID as well. Then setLocalDescription() fails here https://searchfox.org/mozilla-central/rev/807a37c670c093b6e5201841a7c5315ba67ba8d5/media/webrtc/signaling/src/jsep/JsepSessionImpl.cpp#1743 So anymars the easiest solution would be to reach out to TextNow and ask them to read this bug report here. There SDP offer is not (and never was) spec compliant. They simply need to add 'a=mid:0' to their SDP offer. Byron, do you think we should simply create an MID on our end in case the offer m-section is missing one?

Tried to notify TextNow via Twitter https://twitter.com/nilsohlmeier/status/1048440542135115776

Is this related to Bug 1476600 which I have already posted at https://www.fxsitecompat.com/en-CA/docs/2018/rtcrtptransceiver-mid-now-returns-media-id-without-prefix/ ? I’ll update the note if the issue is clear.

But why TextNow works OK with Chrome and MS Edge? I like FF more now, but it sounds strange, if TextNow offer is not compliant. I'll try to reach to their devs.

(In reply to Nils Ohlmeier [:drno] from comment #17) > > Byron, do you think we should simply create an MID on our end in case the > offer m-section is missing one? We should be doing this already, and I thought we had a test that verified this. I'll look into it on Tuesday.

(In reply to Kohei Yoshino [:kohei] from comment #19) > Is this related to Bug 1476600 which I have already posted at > https://www.fxsitecompat.com/en-CA/docs/2018/rtcrtptransceiver-mid-now- > returns-media-id-without-prefix/ ? I’ll update the note if the issue is > clear. Similar, but a different bug in this case https://bugzilla.mozilla.org/show_bug.cgi?id=1483338

(In reply to arnymars from comment #20) > But why TextNow works OK with Chrome and MS Edge? I like FF more now, but it > sounds strange, if TextNow offer is not compliant. I'll try to reach to > their devs. Because Chrome and Edge are not fully spec compliant either (in fact none of the browsers enforces all aspects of the specs yet). And most likely the TextNow folks develop against Chrome. And obviously they don't test against Firefox Nightly or Beta like all WebRTC services should, since we add new functionality all the time as you pointed out initially.

Got it. I opened a ticket today with TextNow Support, sent to their dev, and urge to support Firefox. It feels much lighter now compare to Chrome, less RAM hungry. All major browsers have their pros and cons.

(In reply to Byron Campen [:bwc] from comment #21) > (In reply to Nils Ohlmeier [:drno] from comment #17) > > > > Byron, do you think we should simply create an MID on our end in case the > > offer m-section is missing one? > > We should be doing this already, and I thought we had a test that verified > this. I'll look into it on Tuesday. any updates?

This looks like a fairly easy fix, although some test-cases will need to be added.

Wrong bug reference.

Bug 1495569 - Part 1: Ensure that answers are created with the transceiver's mid when the offer did not have a mid.

Posted site compatibility note: https://www.fxsitecompat.com/en-CA/docs/2018/webrtc-sdp-offer-now-requires-mid-property/

Pushed by bcampen@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/19b1ad6ceade Create answers with a=mid even if the offer did not have a=mid r=mjf,jib

@David Durst status-firefox63: affected → wontfix Why firefox63 - wontfix? Many people use FF Beta.

While the pages which stop working are at fault here, because they violate the spec, this used to work to in Firefox and I would argue it is a regression which we introduced via bug 1483338.

This is a pretty small change, so maybe would be fine for a late uplift.

(In reply to Byron Campen [:bwc] from comment #34) > This is a pretty small change, so maybe would be fine for a late uplift. Yes, I think we should at least request it, to either still get into 63 or be on the list for a 63 dot release ride along. Byron: Can you please request the uplift just in case

Comment on attachment 9017512 [details] Bug 1495569: Create answers with a=mid even if the offer did not have a=mid [Beta/Release Uplift Approval Request] Feature/Bug causing the regression: Bug 1483338 User impact if declined: Some site-compat problems for sites that use webrtc. Is this code covered by automated tests?: Yes Has the fix been verified in Nightly?: Yes Needs manual test from QE?: No If yes, steps to reproduce: List of other uplifts needed: None Risk to taking this patch: Low Why is the change risky/not risky? (and alternatives if risky): It just fleshes out a corner case a bit, and adds a couple of non-release assertions. String changes made/needed: None.

Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/13587 for changes under testing/web-platform/tests

Upstream web-platform-tests status checks passed, PR will merge once commit reaches central.

Comment on attachment 9017512 [details] Bug 1495569: Create answers with a=mid even if the offer did not have a=mid Not taking for 63 as this is coming too late for rc2 and isn't even landed in nightly yet. I am marking this bug as tracking+affected for 63 to keep it on my radar as a potential ride-along if we have a dot release, thanks.

Comment on attachment 9017512 [details] Bug 1495569: Create answers with a=mid even if the offer did not have a=mid [Beta/Release Uplift Approval Request] Feature/Bug causing the regression: None User impact if declined: Is this code covered by automated tests?: Yes Has the fix been verified in Nightly?: Yes Needs manual test from QE?: Yes If yes, steps to reproduce: List of other uplifts needed: None Risk to taking this patch: Low Why is the change risky/not risky? (and alternatives if risky): String changes made/needed:

Upstream PR merged

I'm not sure why the 'a=mid:' field is required, based on the SDPs in Nils Ohlmeier's comment. I may be missing something, but according the RFC 5888: > Use of "group" and "mid" > All of the "m" lines of a session description that uses "group" MUST > be identified with a "mid" attribute whether they appear in the group > line(s) or not. Looking at the SDPs in Nils' comment, they all seem to have one media stream: m=audio 46454 RTP/SAVPF 111 0 101 3 and m=audio 9 RTP/SAVPF 111 101 Is there another part of the spec that I'm missing? As I understand these SDPs shouldn't require an mid to group the media streams.

(In reply to justin.graham49 from comment #43) > I'm not sure why the 'a=mid:' field is required, based on the SDPs in Nils > Ohlmeier's comment. > > I may be missing something, but according the RFC 5888: > > > Use of "group" and "mid" > > > All of the "m" lines of a session description that uses "group" MUST > > be identified with a "mid" attribute whether they appear in the group > > line(s) or not. > > > Looking at the SDPs in Nils' comment, they all seem to have one media > stream: > > m=audio 46454 RTP/SAVPF 111 0 101 3 > and > m=audio 9 RTP/SAVPF 111 101 > > > Is there another part of the spec that I'm missing? As I understand these > SDPs shouldn't require an mid to group the media streams. draft-ietf-rtcweb-jsep requires the use of a=mid in initial offers.

(In reply to Byron Campen [:bwc] from comment #44) > (In reply to justin.graham49 from comment #43) > > I'm not sure why the 'a=mid:' field is required, based on the SDPs in Nils > > Ohlmeier's comment. > > > > I may be missing something, but according the RFC 5888: > > > > > Use of "group" and "mid" > > > > > All of the "m" lines of a session description that uses "group" MUST > > > be identified with a "mid" attribute whether they appear in the group > > > line(s) or not. > > > > > > Looking at the SDPs in Nils' comment, they all seem to have one media > > stream: > > > > m=audio 46454 RTP/SAVPF 111 0 101 3 > > and > > m=audio 9 RTP/SAVPF 111 101 > > > > > > Is there another part of the spec that I'm missing? As I understand these > > SDPs shouldn't require an mid to group the media streams. > > draft-ietf-rtcweb-jsep requires the use of a=mid in initial offers. Thank you!

The bug is shown as Fixed. But my Firefox beta get updated today to 64.0b3 , and the issue persists on Textnow website. No change, meaning the mic and speaker signals are not received by the parties upon a phone call completed connection.

(In reply to arnymars from comment #46) > The bug is shown as Fixed. But my Firefox beta get updated today to 64.0b3 , > and the issue persists on Textnow website. No change, meaning the mic and > speaker signals are not received by the parties upon a phone call completed > connection. It seems you are encountering a separate issue. From what I can tell, it seems that after Firefox successfully creates the answer, textnow closes the PeerConnection, which hints that there is something about the answer textnow doesn't like.

Hmm. A fresh build of nightly works fine for me, but my personal-use nightly (with the latest updates) does not. uBlock/privacy badger don't seem to be the culprits. Looking further...

Downloaded beta with a fresh profile works for me too.

I wonder if you guys are encountering a caching issue. The code was updated to fix remote SDPs before giving them to the peer connection. I've tried incoming calls on TextNow with the current beta version (64.0b3) and it seems to work fine.

Clearing cache didn't do it for me. I Refreshed FF64 profile, and TextNow started working again. Reinstalled all previous addons, selected the same browser Options, and it still works OK. Great! :)

Have seen one question on SUMO so far: Webrtc SDP getting error , "Local descriptions must have a=mid attributes" while setting SDP into setLocalDescription https://support.mozilla.org/en-US/questions/1234227

(In reply to Kohei Yoshino [:kohei] (Bugzilla UX) (FxSiteCompat) from comment #52) > Have seen one question on SUMO so far: > > Webrtc SDP getting error , "Local descriptions must have a=mid attributes" > while setting SDP into setLocalDescription > https://support.mozilla.org/en-US/questions/1234227 The code is updated on the website and the change was rolled out this week. I believe the code is being cached on the user's browser, as the SDP should be being re-written to include the a=mid attributes before the peerConnection is made.

Comment on attachment 9017512 [details] Bug 1495569: Create answers with a=mid even if the offer did not have a=mid We haven't had new reports of regressions in the past 4 weeks and the identified affected sites were fixed upstream so let's let it ride the 64 train.

We still see this problem FF 63 and 64beta9 when a second SDP is received. We use it for SIP (with JsSIP). In our case we use Early Media receiving first SDP in 183 Progress, which works fine. But when call is answered (200 OK)that contains a new SDP, it's being rejected with: "InvalidSessionDescriptionError: Local descriptions must have a=mid attributes" I'm not sure why, but it worked fine in FF62. If you need more info let me know...

(In reply to Allan Kristensen from comment #55) > We still see this problem FF 63 and 64beta9 when a second SDP is received. Did you Refresh FF 64 profile ( https://support.mozilla.org/en-US/kb/refresh-firefox-reset-add-ons-and-settings )?

(In reply to Allan Kristensen from comment #55) > We still see this problem FF 63 and 64beta9 when a second SDP is received. > We use it for SIP (with JsSIP). > In our case we use Early Media receiving first SDP in 183 Progress, which > works fine. But when call is answered (200 OK)that contains a new SDP, it's > being rejected with: > "InvalidSessionDescriptionError: Local descriptions must have a=mid > attributes" > > I'm not sure why, but it worked fine in FF62. If you need more info let me > know... The bugfix here was to ensure that we created answers with mids even when the offer did not. As long as JS doesn't remove the mids before applying the answer, things should be fine. However, if JS removes mids from a local description (offer or answer) before calling setLocalDescription, this error will still occur. If this is not what is going on, I would need more information about the offer/answer exchange, or some steps to reproduce.

(In reply to arnymars from comment #56) > (In reply to Allan Kristensen from comment #55) > > We still see this problem FF 63 and 64beta9 when a second SDP is received. > Did you Refresh FF 64 profile ( > https://support.mozilla.org/en-US/kb/refresh-firefox-reset-add-ons-and- > settings )? Yes, I cleared everything as part of the upgrade process from 63 -> 64b

> The bugfix here was to ensure that we created answers with mids even when > the offer did not. As long as JS doesn't remove the mids before applying the > answer, things should be fine. However, if JS removes mids from a local > description (offer or answer) before calling setLocalDescription, this error > will still occur. If this is not what is going on, I would need more > information about the offer/answer exchange, or some steps to reproduce. I can provide you with a capture of the whole session with the SDP in question, if you can provide me with a destination to send it to?

(In reply to Allan Kristensen from comment #59) > > The bugfix here was to ensure that we created answers with mids even > when > > the offer did not. As long as JS doesn't remove the mids before applying the > > answer, things should be fine. However, if JS removes mids from a local > > description (offer or answer) before calling setLocalDescription, this error > > will still occur. If this is not what is going on, I would need more > > information about the offer/answer exchange, or some steps to reproduce. > > I can provide you with a capture of the whole session with the SDP in > question, if you can provide me with a destination to send it to? You can use my email address (docfaraday@gmail.com) if you don't want to post it publicly.

(In reply to Allan Kristensen from comment #58) > Yes, I cleared everything as part of the upgrade process from 63 -> 64b Cleared browsing data or deleted the profile folder? You must Refresh the profile by following the above linked article, as it invokes resetting many settings in about:config and other in xml files one can't access through FF Settings.

Yes, I used the refresh link and followed the procedure in FF (In reply to arnymars from comment #61) > (In reply to Allan Kristensen from comment #58) > > > Yes, I cleared everything as part of the upgrade process from 63 -> 64b > Cleared browsing data or deleted the profile folder? You must Refresh the > profile by following the above linked article, as it invokes resetting many > settings in about:config and other in xml files one can't access through FF > Settings.

Hello Byron, I have sent you logs. From what I see, the createOffer() doesn't return an SDP with any mid attributes (if this was the intention?). So when calling setLocalDescription(offer) it throws an error. Let me know if I can be of any further help. /Allan (In reply to Byron Campen [:bwc] from comment #60) > (In reply to Allan Kristensen from comment #59) > > > The bugfix here was to ensure that we created answers with mids even > > when > > > the offer did not. As long as JS doesn't remove the mids before applying the > > > answer, things should be fine. However, if JS removes mids from a local > > > description (offer or answer) before calling setLocalDescription, this error > > > will still occur. If this is not what is going on, I would need more > > > information about the offer/answer exchange, or some steps to reproduce. > > > > I can provide you with a capture of the whole session with the SDP in > > question, if you can provide me with a destination to send it to? > > You can use my email address (docfaraday@gmail.com) if you don't want to > post it publicly.

Ok, so this is a problem with local reoffers I guess, as opposed to local answers. I will open a new bug.