1495569 - SDP offers without a=mid get rejected after creating an answer (Local descriptions must have a=mid attributes)

Status: RESOLVED FIXED

(Core :: WebRTC: Signaling, defect, P2)

Description

[Zamar Ac]

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.

Comment 1

[Zamar Ac]

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.

Comment 2

[Zamar Ac]

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.

Comment 3

[Michael Froman [:mjf]]

Nils, who should take a look at this?

Comment 4

[Andreas Pehrson [:pehrsons]]

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)

Comment 5

[Zamar Ac]

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

Comment 6

[Nils Ohlmeier [:drno]]

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

Comment 7

[Zamar Ac]

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 ++++++++

Comment 8

[Zamar Ac]

Attachment: TextNow_WebRTC1.jpg

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

Comment 9

[Zamar Ac]

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

Comment 10

[Zamar Ac]

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

Comment 11

[Zamar Ac]

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.

Comment 12

[Nils Ohlmeier [:drno]]

(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.

Comment 13

[Nils Ohlmeier [:drno]]

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?

Comment 14

[Zamar Ac]

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.

Comment 15

[Zamar Ac]

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

Comment 16

[Zamar Ac]

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.

Comment 17

[Nils Ohlmeier [:drno]]

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?

Comment 18

[Nils Ohlmeier [:drno]]

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

Comment 19

[Kohei Yoshino]

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.

Comment 20

[Zamar Ac]

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.

Comment 21

[Byron Campen [:bwc]]

(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.

Comment 22

[Nils Ohlmeier [:drno]]

(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

Comment 23

[Nils Ohlmeier [:drno]]

(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.

Comment 24

[Zamar Ac]

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.

Comment 25

[Jean-Yves Avenard [:jya]]

(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?

Comment 26

[Byron Campen [:bwc]]

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

Comment 27

[Byron Campen [:bwc]]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=27ebfabd15b46967955162872ba4ec4fb2511883

Comment 28

[Kohei Yoshino]

Wrong bug reference.

Comment 29

[Byron Campen [:bwc]]

Attachment: Bug 1495569: Create answers with a=mid even if the offer did not have a=mid

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

Comment 30

[Kohei Yoshino]

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

Comment 31

[Pulsebot]

Pushed by [e-mail]:
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

Comment 32

[Zamar Ac]

@David Durst
status-firefox63: affected → wontfix

Why firefox63 - wontfix? Many people use FF Beta.

Comment 33

[Nils Ohlmeier [:drno]]

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.

Comment 34

[Byron Campen [:bwc]]

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

Comment 35

[Nils Ohlmeier [:drno]]

(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 36

[Byron Campen [:bwc]]

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.

Comment 37

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

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

Comment 38

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

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

Comment 39

[Pascal Chevrel:pascalc]

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 40

[Pascal Chevrel:pascalc]

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:

Comment 41

[Eliza Balazs [:ebalazs_]]

https://hg.mozilla.org/mozilla-central/rev/19b1ad6ceade

Comment 42

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Upstream PR merged

Comment 43

[justin.graham49]

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.

Comment 44

[Byron Campen [:bwc]]

(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.

Comment 45

[justin.graham49]

(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!

Comment 46

[Zamar Ac]

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.

Comment 47

[Byron Campen [:bwc]]

(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.

Comment 48

[Byron Campen [:bwc]]

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...

Comment 49

[Byron Campen [:bwc]]

Downloaded beta with a fresh profile works for me too.

Comment 50

[justin.graham49]

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.

Comment 51

[Zamar Ac]

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! :)

Comment 52

[Kohei Yoshino]

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

Comment 53

[justin.graham49]

(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 54

[Pascal Chevrel:pascalc]

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.

Comment 55

[Allan Kristensen]

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...

Comment 56

[Zamar Ac]

(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 )?

Comment 57

[Byron Campen [:bwc]]

(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.

Comment 58

[Allan Kristensen]

(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

Comment 59

[Allan Kristensen]

 >    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?

Comment 60

[Byron Campen [:bwc]]

(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 ([e-mail]) if you don't want to post it publicly.

Comment 61

[Zamar Ac]

(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.

Comment 62

[Allan Kristensen]

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.

Comment 63

[Allan Kristensen]

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 ([e-mail]) if you don't want to
> post it publicly.

Comment 64

[Byron Campen [:bwc]]

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