SLD Errors When Renegotiating

[kenny-house]

I've been working with jingle-media-session (through stanza.io) recently and while implementing adding and removing streams for ongoing sessions, I hit an error in Chrome / Chromium. I'm testing in Chrome Canary 50.0.2627.0, Chrome 47 and on a Chromium embedded application using Chromium 45. The same error occurs in both Canary, Chrome 47, and Chromium 45.

The error I'm hitting is: Failed to set local answer sdp: Failed to push down transport description: Offerer must use actpass value for setup attribute.

In my code base, I'm using the addStream2 method of jingle-media-session.

Depending on whether the peer connection adding / removing the stream was the initiator of the session, the results are different.

If the peer who initiated the session is adding / removing the stream, the flow is as follows for adding a stream (this is after the initial offer / answer succeeds):

Initiator:
  AddStream
  SRD with current remote description (setup:active)
  SLD with answer (setup:passive)
  SLD fails: Failed to set local answer sdp: Failed to push down transport description: Offerer must use actpass value for setup attribute.

No source-add is sent due to the SLD failure

If the peer who responded to the offer initially is adding / removing the stream, the flow is as follows for adding a stream (this is after the initial offer / answer succeeds):

Responder:
  AddStream
  SRD with current remote description (setup:actpass)
  SLD with answer (setup:active)
  Sends source-add
Initiator:
  SRD: (setup:active)
  onAddStream
  SLD with answer (setup:passive)
  SLD fails: Failed to set local answer sdp: Failed to push down transport description: Offerer must use actpass value for setup attribute.

Although SLD fails and there's quite a few errors printed in the console, onAddStream is called for the Initiator and it begins receiving the new stream just fine from the Responder.

Looking through jingle-media-session, the error makes sense given how jingle-media-session uses the current remote description as the sdp passed to handleOffer before sending the answer with the new stream information. This leads me to believe that I might be using the addStream2 function incorrectly?

Modifying the remote descriptions used in the handleOffer call in the addStream function (as well as onSourceAdd) to ensure that the setup is always actpass causes adding streams to work without errors (otalk:8f13fce...octovis:9eb6856).

Wanted to get thoughts on if this is indeed a bug, or if I'm just using the library incorrectly.