840728 - Implement advanced RTCPeerConnection session handling

Status: RESOLVED FIXED

(Core :: WebRTC: Signaling, defect)

Description

[Adam Roach [:abr]]

Currently, we have no logic for dealing with:

(1) Multiple calls to createOffer or createAnswer with different constraints, or
(2) Calls to createOffer or createAnswer in the middle of a session

In practice, this should probably be coded after we have generalized SDP handling (i.e., multiple m-line handling, multiple streams per m-line, etc), and the resolution of this is pending IETF RTCWEB WG agreement.

See also Bug 834038 and Bug 840344.

Comment 1

[Adam Ullman]

I got an error referring to this bug number ("Renegotiation of session description is not currently supported. See Bug 840728 for status.").

This error came up when setting a remoteDescription. I was actually establishing 2 PeerConnections at the same time, both got this error. Is it expected that you can't establish 2 PeerConnections at the same time? Is this what you mean by calling createOffer or createAnswer in the middle of a session? This test worked fine in Chrome.

Also the error name was "INVALID_STATE" the reasonName was and array with the following elements:
0
	"NO_ERROR"
	
1
	"INVALID_CONSTRAINTS_TYPE"
	
2
	"INVALID_CANDIDATE_TYPE"
	
3
	"INVALID_MEDIASTREAM_TRACK"
	
4
	"INVALID_STATE"
	
5
	"INVALID_SESSION_DESCRIPTION"
	
6
	"INCOMPATIBLE_SESSION_DESCRIPTION"
	
7
	"INCOMPATIBLE_CONSTRAINTS"
	
8
	"INCOMPATIBLE_MEDIASTREAMTRACK"
	
9
	"INTERNAL_ERROR"

Comment 2

[justin.dujardin]

I would really like to see this issue resolved.  It is a particularly painful thing to work around, produces more signal glare, and impacts prototyping/user-experience in a not-so-great kind of way.

Consider an example:

I want build an application with WebRTC that supports (n) mesh-connected users who can choose to share video/audio with their peers at any time by clicking toggle buttons.

I identify PeerConnection as the place to start, and make sure I understand how to communicate offer/answer objects between peers.  Once that is complete I add the ability for Peers to add/remove media streams from their PC at any time.  This works fine in Chrome, but now FireFox peers sometimes fail.  After some debugging (and Bug 964223) I find that this is the underlying problem.

I try to get around this limitation by negotiating all peers with A/V broadcast from the get-go, pausing the streams based on the toggle buttons.  This seems like a good compromise until I realize that the user's camera indicator is now permanently turned on.  This leads to conflicting user expectations, e.g. "why does my camera say it's on when your UI says I'm not sharing video?"

Seeing no other obvious options, I resort to tearing-down and creating new PeerConnections every time a user changes their A/V options.  This works as expected, and interops with FireFox/Opera/Chrome properly, but results in everyone's streams blipping whenever anyone changes their sharing options.

Not only has this prototype now taken me through multiple debugging/forum searching sessions, but it has added considerable complexity to my code.  I've had to implement a signaling mechanism to tell peers to renegotiate their connections, and build a sane factory for PeerConnection objects, just to have a cross-browser prototype for my (seemingly simple) use-case.  

-- 

Some of this is work I would have had to do eventually (e.g. signal glare), but I wouldn't expect to have to deal with it for a simple prototype.

Thanks for your consideration.

Comment 3

[ravindra]

I would also really like to this issue resolved.

Comment 4

[Wil Neeley]

Hear hear.

I'm building a p2p file sharing app and the renegotiation of PeerConnections has been nothing short of a nightmare as far as the additional complexity added to my app. I would be in much appreciation of resolution. Chrome works splendidly in this regard.

Comment 5

[Byron Campen [:bwc]]

So, as of bug 1091242 we have the ability to call createOffer/createAnswer as many times as we like. Renegotiation support is mostly done over in bug 1017888, which allows us to create offers/answers during a session. What else is in scope for this bug?

Comment 6

[Ugurcan]

Hi,

When I use createAnswer middle of a session, it sets sdp's port as 9, which is OK until all ice candidates are received. Unfortunately no candidates received, so that port never actually turns out a valid value. Should I report a new bug about this issue or is this bug related to creating new answer in middle of a session?

Comment 7

[Eric Rescorla (:ekr)]

Can you supply a test case for this?

Comment 8

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

(In reply to Ugurcan from comment #6)
> Hi,
> 
> When I use createAnswer middle of a session, it sets sdp's port as 9, which
> is OK until all ice candidates are received. Unfortunately no candidates
> received, so that port never actually turns out a valid value. Should I
> report a new bug about this issue or is this bug related to creating new
> answer in middle of a session?

I'd suggest creating a new bug for this (in Core::Webrtc Networking; if it turns out to be somehow not a bug we can resolve it at that point.

To byron's point, likely this should be closed/duped

Comment 9

[Byron Campen [:bwc]]

(In reply to Ugurcan from comment #6)
> Hi,
> 
> When I use createAnswer middle of a session, it sets sdp's port as 9, which
> is OK until all ice candidates are received. Unfortunately no candidates
> received, so that port never actually turns out a valid value. Should I
> report a new bug about this issue or is this bug related to creating new
> answer in middle of a session?

   I'm guessing this is in a bundled m-section? Go ahead and file a bug over in Core::Webrtc Signaling and I can give it a go.

Comment 10

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

Shall we close this bug?

Comment 11

[Byron Campen [:bwc]]

Yeah, I think so.