1161485 - DTLS Handshake issue: Firefox 37 doesn't accept its own generated answer SDP

Status: RESOLVED DUPLICATE of bug 1161136

(Core :: WebRTC: Signaling, defect)

Description

[Dmitriy Kravchenko]

Attachment: Offer SDP and answer SDP

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:33.0) Gecko/20100101 Firefox/33.0
Build ID: 20141113143407

Steps to reproduce:

1. My WebRTC application sends offer SDP to Firefox 37 (FF37). My application uses libjingle to work with WebRTC.
2. My JavaScript code running on FF37 receives offer SDP and successfully executes mozRTCPeerConnection.setRemoteDescription for the offer.
3. My JavaScript code calls mozRTCPeerConnection.createAnswer method to generate answer SDP. The method succeeds.
4. My JavaScript code calls mozRTCPeerConnection.setLocalDescription for answer SDP generated on step 3. 

Here is a sample excerpt of the related JavaScript code (used for testing):

mediaConstraints = {
	optional: [],
	mandatory: {
		OfferToReceiveAudio: true,
		OfferToReceiveVideo: true
	}
};

createFireFoxAnswerer: function(offerSdp) {

var iceServers = {
	iceServers: [{
		url: 'stun:23.21.150.121'
	}]
},

this.answerer = new mozRTCPeerConnection(iceServers);

navigator.mozGetUserMedia({
	audio: true,
	fake: true
	}, $.proxy(function(stream) {
		console.log('offer sdp = ' + JSON.stringify(offerSdp));
		this.answerer.addStream(stream);
		this.answerer.setRemoteDescription(new mozRTCSessionDescription(offerSdp), function() { console.log('Successfully set remote description'); },
			function(error) { console.log('Failed to set remote description: ', error); });
		this.answerer.createAnswer($.proxy(function(answerSdp) {
			this.answerer.setLocalDescription(answerSdp, function() { console.log('Successfully set local description'); },
				function(error) { console.log('Failed to set local description: ', error); });
			}, this), function(error) { console.log('onSdpError', error); }, mediaConstraints);
		}, this),
	function(error) {
		console.log(error);
	}
);



Actual results:

Call on step 4 fails with error:

DOMError { name: "InvalidSessionDescriptionError", message: "mid specified for bundle transport in group attribute does not exist in the SDP. (mid=audio)" }



Expected results:

Call on step 4 should succeed and success callback should be called.

Comment 1

[Dmitriy Kravchenko]

Ouch, sorry, incorrect JS code in description. Since I was unable to find how to edit description, here's a corrected JS code:


createFireFoxAnswerer: function(offerSdp) {

var iceServers = {
	iceServers: [{
		url: 'stun:23.21.150.121'
	}]
},
mediaConstraints = {
	optional: [],
	mandatory: {
		OfferToReceiveAudio: true,
		OfferToReceiveVideo: true
	}
};

this.answerer = new mozRTCPeerConnection(iceServers);

navigator.mozGetUserMedia({
	audio: true,
	fake: true
	}, $.proxy(function(stream) {
		console.log('offer sdp = ' + JSON.stringify(offerSdp));
		this.answerer.addStream(stream);
		this.answerer.setRemoteDescription(new mozRTCSessionDescription(offerSdp), function() { console.log('Successfully set remote description'); },
			function(error) { console.log('Failed to set remote description: ', error); });
		this.answerer.createAnswer($.proxy(function(answerSdp) {
			this.answerer.setLocalDescription(answerSdp, function() { console.log('Successfully set local description'); },
				function(error) { console.log('Failed to set local description: ', error); });
			}, this), function(error) { console.log('onSdpError', error); }, mediaConstraints);
		}, this),
	function(error) {
		console.log(error);
	}
);

Comment 2

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

This appears to be the issue fixed in bug 1161136; once this is in a Nightly build (the patch has been made but it has not been reviewed or landed yet) you can try it.  We should be able to get this fix into 39; *maybe* into 38.0.5 

In the meantime, the easiest workaround is to avoid rejecting tracks.  Alternatively, you can edit the SDP to remove the mid from the bundle group for any rejected tracks in the offer (which is admittedly a pain).  Probably taking the bundle group and then text-searching the SDP for lines that are exactly "a=mid:<value>" and removing any items from the bundle where you don't find the line.  That sort of workaround should be safe and wouldn't change the operation of your site

And thanks for reporting the problem.  Your comments are why we found and fixed this.

Comment 3

[Byron Campen [:bwc]]

Actually, the way to avoid this bug is to not set remote offers with disabled m-sections whose mids are still in the bundle group:

From the offer SDP:
a=group:BUNDLE *audio* data
a=msid-semantic: WMS
m=audio *0* RTP/SAVPF 111 103 104 9 102 0 8 106 105 13 127 126
...
a=mid:*audio*

This offer SDP is invalid.

Comment 4

[Dmitriy Kravchenko]

(In reply to Randell Jesup [:jesup] from comment #2)
> This appears to be the issue fixed in bug 1161136; once this is in a Nightly
> build (the patch has been made but it has not been reviewed or landed yet)
> you can try it.  We should be able to get this fix into 39; *maybe* into
> 38.0.5 
> 

Thank you!


(In reply to Byron Campen [:bwc] from comment #3)
> Actually, the way to avoid this bug is to not set remote offers with
> disabled m-sections whose mids are still in the bundle group:
> 
> From the offer SDP:
> a=group:BUNDLE *audio* data
> a=msid-semantic: WMS
> m=audio *0* RTP/SAVPF 111 103 104 9 102 0 8 106 105 13 127 126
> ...
> a=mid:*audio*
> 
> This offer SDP is invalid.

Is there a possibility that such SDP will be rejected in the future, i.e. the call to mozRTCPeerConnection.setRemoteDescription will fail?

Btw, the offer SDP is generated by libjingle/WebRTC code from here: https://code.google.com/p/webrtc/. It's also used by Google Chrome, afaik. Though my version of that code (which was used here) is somewhat outdated now.

Comment 5

[Byron Campen [:bwc]]

> (In reply to Byron Campen [:bwc] from comment #3)
> > Actually, the way to avoid this bug is to not set remote offers with
> > disabled m-sections whose mids are still in the bundle group:
> > 
> > From the offer SDP:
> > a=group:BUNDLE *audio* data
> > a=msid-semantic: WMS
> > m=audio *0* RTP/SAVPF 111 103 104 9 102 0 8 106 105 13 127 126
> > ...
> > a=mid:*audio*
> > 
> > This offer SDP is invalid.
> 
> Is there a possibility that such SDP will be rejected in the future, i.e.
> the call to mozRTCPeerConnection.setRemoteDescription will fail?
> 
> Btw, the offer SDP is generated by libjingle/WebRTC code from here:
> https://code.google.com/p/webrtc/. It's also used by Google Chrome, afaik.
> Though my version of that code (which was used here) is somewhat outdated
> now.

   Yeah, we have a bunch of work to do on the validation code. There are lots of weird corner cases that need covering.

Comment 6

[Byron Campen [:bwc]]

(for this case, validation might prove fairly difficult, since with the introduction of a=bundle-only there's no telling when/if other similar attributes might be standardized that alter the meaning of port 0 on the m-line)

Comment 7

[Dmitriy Kravchenko]

(In reply to Randell Jesup [:jesup] from comment #2)
> This appears to be the issue fixed in bug 1161136; once this is in a Nightly
> build (the patch has been made but it has not been reviewed or landed yet)
> you can try it.  We should be able to get this fix into 39; *maybe* into
> 38.0.5 
> 

I'm sorry, but looks like this bug is still not fixed in FF 39. I'm still getting exactly the same error message in exactly the same place.