Re-negotiated Chrome (audio only) offer after an offer of (audio+video) with Firefox (audio only) results in set remote sdp errors in Chrome's end

RESOLVED INVALID

Status

()

RESOLVED INVALID
2 years ago
2 years ago

People

(Reporter: leticia.choo, Unassigned)

Tracking

49 Branch
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(4 attachments)

(Reporter)

Description

2 years ago
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.35 Safari/537.36

Steps to reproduce:

1. Chrome creates an offer with audio+video tracks added.
2. Firefox sets the remote offer.
3. Firefox creates an answer with video only tracks added.
4. Chrome sets the remote answer.
6. Chrome creates an offer with this time round video tracks only added (audio track is removed).
7. Firefox sets the remote offer.
8. Firefox creates an answer that does not have ICE credentials in the m=audio line and selecting PCMU.
9. Chrome sets the remote answer and throws set remote sdp errors.


Actual results:

Testing it with Chrome to Firefox, it seems like Firefox does not keep the ICE credentials the second time it generates the offer.

First answer from Firefox where Chrome is sending audio:

v=0
o=mozilla...THIS_IS_SDPARTA-50.0 1061366343419570670 0 IN IP4 0.0.0.0
s=-
t=0 0
a=fingerprint:sha-256 7A:2D:94:AC:18:D6:23:32:C2:0E:F5:96:56:22:C9:45:48:B4:64:93:84:60:0B:73:16:D0:AD:14:0D:B4:D4:06
a=group:BUNDLE audio video data
a=ice-options:trickle
a=msid-semantic:WMS *
m=audio 9 UDP/TLS/RTP/SAVPF 111
c=IN IP4 0.0.0.0
a=recvonly
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=fmtp:111 useinbandfec=1;maxplaybackrate=48000;
a=ice-pwd:0d839b8266000edb85008becbad4b87c
a=ice-ufrag:f10564e8
a=mid:audio
a=rtcp-mux
a=rtpmap:111 opus/48000/2
a=setup:active
a=ssrc:1953225679 cname:{d0fcf8e5-39e3-a847-a3f3-cf82fcaa1338}
m=video 9 UDP/TLS/RTP/SAVPF 100
c=IN IP4 0.0.0.0
a=sendrecv
a=fmtp:100 max-fs=12288;max-fr=60
a=ice-pwd:0d839b8266000edb85008becbad4b87c
a=ice-ufrag:f10564e8
a=mid:video
a=msid:{43a54ee8-8c14-e847-ae23-9dceda3913d7} {56704641-ecae-214c-989e-eaeb4e67d4b4}
a=rtcp-fb:100 nack
a=rtcp-fb:100 nack pli
a=rtcp-fb:100 ccm fir
a=rtcp-fb:100 goog-remb
a=rtcp-mux
a=rtpmap:100 VP8/90000
a=setup:active
a=ssrc:2381522307 cname:{d0fcf8e5-39e3-a847-a3f3-cf82fcaa1338}
a=ssrc:2381522307 msid:{43a54ee8-8c14-e847-ae23-9dceda3913d7} {56704641-ecae-214c-989e-eaeb4e67d4b4}
a=ssrc:2381522307 mslabel:default
a=ssrc:2381522307 label:{56704641-ecae-214c-989e-eaeb4e67d4b4}
m=application 9 DTLS/SCTP 5000
c=IN IP4 0.0.0.0
a=sendrecv
a=ice-pwd:0d839b8266000edb85008becbad4b87c
a=ice-ufrag:f10564e8
a=mid:data
a=sctpmap:5000 webrtc-datachannel 256
a=setup:active
a=ssrc:318296785 cname:{d0fcf8e5-39e3-a847-a3f3-cf82fcaa1338}

Second answer from Firefox where Chrome re-negotiates without audio:

v=0
o=mozilla...THIS_IS_SDPARTA-50.0 1061366343419570670 1 IN IP4 0.0.0.0
s=-
t=0 0
a=fingerprint:sha-256 7A:2D:94:AC:18:D6:23:32:C2:0E:F5:96:56:22:C9:45:48:B4:64:93:84:60:0B:73:16:D0:AD:14:0D:B4:D4:06
a=group:BUNDLE video data
a=ice-options:trickle
a=msid-semantic:WMS *
m=audio 0 UDP/TLS/RTP/SAVPF 0
c=IN IP4 0.0.0.0
a=inactive
a=rtpmap:0 PCMU/8000
m=video 9 UDP/TLS/RTP/SAVPF 100
c=IN IP4 0.0.0.0
a=sendrecv
a=fmtp:100 max-fs=12288;max-fr=60
a=ice-pwd:0d839b8266000edb85008becbad4b87c
a=ice-ufrag:f10564e8
a=mid:video
a=msid:{43a54ee8-8c14-e847-ae23-9dceda3913d7} {56704641-ecae-214c-989e-eaeb4e67d4b4}
a=rtcp-fb:100 nack
a=rtcp-fb:100 nack pli
a=rtcp-fb:100 ccm fir
a=rtcp-fb:100 goog-remb
a=rtcp-mux
a=rtpmap:100 VP8/90000
a=setup:active
a=ssrc:2381522307 cname:{d0fcf8e5-39e3-a847-a3f3-cf82fcaa1338}
a=ssrc:2381522307 msid:{43a54ee8-8c14-e847-ae23-9dceda3913d7} {56704641-ecae-214c-989e-eaeb4e67d4b4}
a=ssrc:2381522307 mslabel:default
a=ssrc:2381522307 label:{56704641-ecae-214c-989e-eaeb4e67d4b4}
m=application 9 DTLS/SCTP 5000
c=IN IP4 0.0.0.0
a=sendrecv
a=ice-pwd:0d839b8266000edb85008becbad4b87c
a=ice-ufrag:f10564e8
a=mid:data
a=sctpmap:5000 webrtc-datachannel 256
a=setup:active
a=ssrc:318296785 cname:{d0fcf8e5-39e3-a847-a3f3-cf82fcaa1338}

This results on Chrome's end to throw the following error:

DOMException: Failed to set remote answer sdp: Failed to push down transport description: Local and Remote description must be set before transport descriptions are negotiated


Expected results:

From my understanding, the Firefox answer session description should still contain the ICE credentials negotiated earlier and not switch to PCMU. Is there any reasons or specs for this?
(Reporter)

Updated

2 years ago
Component: Untriaged → WebRTC
Product: Firefox → Core
(Reporter)

Comment 1

2 years ago
Created attachment 8808123 [details]
chrome-to-firefox-first-answer-sdp.txt
(Reporter)

Comment 2

2 years ago
Created attachment 8808124 [details]
chrome-to-firefox-second-answer-sdp.txt
(Reporter)

Comment 3

2 years ago
Created attachment 8808125 [details]
chrome-to-chrome-first-answer-sdp.txt
(Reporter)

Comment 4

2 years ago
Created attachment 8808127 [details]
chrome-to-chrome-second-answer-sdp.txt
Component: WebRTC → WebRTC: Signaling
Can you tell if this is real?
Flags: needinfo?(drno)
Whiteboard: [need info drno 2016-11-11]
Chrome should not care about attributes or the codec on that rejected m=audio section. That error message doesn't really tell me what Chrome is unhappy about, though.
I think we are looking at two things here:

1) Firefox setting the audio m-line to inactive. BTW I'm guessing that Chrome actually offered in its second offer PCMU again so switching codecs would be totally acceptable in that case. But Byron is right that Chrome should not care about the codec on a reject and inactive m-line. If they do it's a bug on their end.

2) The bundeling of the transports has changed. The audio m-line is no longer part of the bundle. But since the video and application m-line still have ICE crendetials I don't see why Chrome is unhappy with the answer.

Although I'm wondering if that fact that the audio m-line got unbundled means that Chrome tries to setup a new ICE transport for that m-section even though it is inactive?!
Flags: needinfo?(drno)
Byron pointed out correctly that an inactive m-section would require an ICE transport. In that case ICE credentials would be needed. But since Firefox rejects the m-line with port 0 no ICE transport is needed. Therefore I think this is purely a Chrome bug (feel free to reference the Chrome ticket if you open one and we can chime in on the ticket if needed).
Status: UNCONFIRMED → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → INVALID
Whiteboard: [need info drno 2016-11-11]
https://bugs.chromium.org/p/webrtc/issues/detail?id=6280 discusses a very, very similar error.
(In reply to Philipp Hancke from comment #9)
> https://bugs.chromium.org/p/webrtc/issues/detail?id=6280 discusses a very,
> very similar error.

Yeah I think that is pretty much the same problem. Leticia might be interesting/worth checking which bundle policy you use and if changing that helps in your case.
It's a very similar issue. The problem here, in short, is that once Chrome has negotiated bundling, it doesn't like when the answerer BUNDLE-tag changes. Here it's changing from "audio" to "video" because the audio m= section is rejected.
You need to log in before you can comment on or make changes to this bug.