otalk / jingle-media-session Goto Github PK

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.

I've run into an issue where calling addStream2 multiple times in a row synchronously causes problems, since it triggers multiple, parallel renegotiation operations. This results in not all the streams being added to the session.

I've solved it in my application by adding an async queue (specifically using d3-queue

I'm wondering if jingle-media-session should handle this, or if I'm missing something? As I understand it, any operations which trigger a renegotiation either all have to happen before renegotiation starts (and then only one renegotiation is required), or each operation needs to be queued until the previous renegotiation completes.

Thoughts @xdumaine @legastero @fippo ?

If calling removeStream or switchStream with a stream to be removed, and that stream is not a local stream on the peerconnection, pc.removeStream(stream) will basically just silently do nothing - we should maybe check that the stream exists in pc.getLocalStreams() before trying to remove it, and error otherwise.

I think this was discussed previously, but I thought it would be good to have an issue open - now that firefox supports multistream, supporting it should be a (not so simple) matter of SDP interop described in Firefox multistream hacks.

The recent change to the webrtc proposal seems to be chopping us out at the knees. Everything will be track related rather than stream related (https://www.w3.org/standards/history/webrtc). Is there a migration plan for this?

on talky we were seeing very rare errors where setLocalDescription failed without any apparent effect. Here is what happened:

• remote sent session-initiate without any streams.
• setRemoteDescription is called. createAnswer (1) is called. Processing of remote actions resumes. PeerConnection is in have-remote-offer state.
• remote sent source-add. SRD is called. createAnswer (2) is called. PeerConnection is transitioning have-remote-offer -> have-remote-offer
• createAnswer (1) returns. setLocalDescription is called. PeerConnection goes into stable state. Things work.
• createAnswer (2) returns. setLocalDescription is called even though state is stable. Boom. But no bad things happened.

Proposed solution (other than continuing to work on the green spinning vortex of processing doom) is to ignore SLD when the state is stable.

The behavior I'm seeing is that a switchStream sends a source remove for the old stream, but then sends a source-add containing both streams.
I believe the offending code may be this, from switchStream. Or, perhaps, pc.removeStream doesn't work quite right?

var audioTracks = oldStream.getAudioTracks();
if (audioTracks.length) {
    newStream.addTrack(audioTracks[0]);
}

@fippo @legastero any ideas?

I would like to broadcast my stream to another user without receiving his stream. I can set offerToReceiveAudio|Video to false, but how can I get this information on the other side? Or is there an other way to achieve this, because offerToReceiveAudio is completely gone from the spec.

https://github.com/otalk/jingle-media-session/blob/master/index.js#L315

var audioTracks = oldStream.getAudioTracks();
if (audioTracks.length) {
    newStream.addTrack(audioTracks[0]);
}

I find this behavior very... confusing. I'm trying to use switchStream to swap out a stream, but it's causing me to hold onto audio tracks. It's especially confusing when I'm swapping streams because the user chose a new microphone.

A couple potential solutions:

1. Deprecate add/remove/switch streams in favor of add/remove/switch tracks.
2. Don't do the above unless explicitly named (i.e., pass in opts to this method in order to decide which tracks by kind (audio/video) are saved from the previous stream). Thoughts @fippo @legastero