Multistream - inactive track

[Mirko Brankovic]

Hi,
I have a weird case of DTLS/ICE failure on multistream branch, and hoping someone can help me bring it to some light or fire :)

So from client perspective we are  we are publishing (joinandconfigure request) Audio then Video but then depending which track we want to disable mid 0 or 1 we get a good stream or ICE failed/ DTLS alert. When ever we want to inactivate mid 0 janus instantly gives us alert and cleanup the publisher.

Example of good offer/answer:

https://pastebin.com/8KdpitHv

mid 1(video) was inactivated and can be seen in offer audio stream keeps flowing, and it doesn't matter if video is in mid0 it will keep working.

Example of DTLS alert:

https://pastebin.com/H6g36xs3

mid 0 was inactivated, in this case video and we got Alert in matter of miliseconds of sending Answer to client (before client managed to send new ICE candidates).

Note that Janus send answer with correct streams objects :

https://pastebin.com/rTphwpsr

I also noticed that Client (chrome) is adding candidates only to mid0 (even when 0 is inactive) wheres Janus adds them to active mid.

Can it be that we are missing a step on client side, like pc.restartIce() but I doubt that it is necessary when disabling track?

Thanks for any help.

mirko

[Mirko Brankovic]

Forgot to mention, maybe can be important, we use request: configure, when we want to inactivate/remove track. 

[Lorenzo Miniero]

In Janus media is always bundled on the first track, so invalidating that one invalidates the whole PC. That said, I remembered we added code to turn the port-0 to port-9 exactly to avoid that, but checking the code this seems to happen only when bundle-only is used for the SDP. That's a simple check you can make by forcing bundlePolicy:"max-bundle" when creating the PeerConnection, or by munging the SDP to add the attribute manually: that should keep the PeerConnection alive even when you invalidate that first track.

That said, since in Janus we *only* support bundling all streams, I guess I should change the logic to ensure that the port of the first track is always set to 9. If you let me know whether the test above works, I can make the change.

L.

[Mirko Brankovic]

Changing the bundlePolicy on client didn't affect anything, with any of the 3 possible enums.

I do see the flag in webrtc-internals passed to PC configuration but I don't see any difference in SDP in all 3 cases, which is a bit weird 

--
You received this message because you are subscribed to the Google Groups "meetecho-janus" group.
To unsubscribe from this group and stop receiving emails from it, send an email to meetecho-janu...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/meetecho-janus/3cc76bfd-931a-4691-b7d4-98dd2d0cd3d5n%40googlegroups.com.

--

Regards,

Mirko

[Lorenzo Miniero]

There should be a a=bundle-only attribute in the SDP.

Anyway, see if adding this:

                if(m->index == 0 && m->port == 0)
                        m->port = 9;

after this line

https://github.com/meetecho/janus-gateway/blob/a8a0b9306601077c58f55e43d0c878fbca8c9186/sdp.c#L62

helps. It's a quick hack to ensure we always treat the first m-line as a non-0 port, so deactivating the track shouldn't "break" it. If it works, I can commit and push it.

L.

[Mirko Brankovic]

Seems to be working if I add that port 9:

this:

diff --git a/sdp.c b/sdp.c
index 27669d8c..8c8112ba 100644
--- a/sdp.c
+++ b/sdp.c
@@ -59,6 +59,8 @@ janus_sdp *janus_sdp_preparse(void *ice_handle, const char *jsep_sdp, char *erro
                while(tempA) {
                        janus_sdp_attribute *a = (janus_sdp_attribute *)tempA->data;
                        if(a->name) {
+                               if(m->index == 0 && m->port == 0)
+                                       m->port = 9;
                                if(!strcasecmp(a->name, "bundle-only") && m->port == 0) {
                                        /* Port 0 but bundle-only is used, don't disable this m-line */
                                        m->port = 9;

[Lorenzo Miniero]

Ack, I'll push the change then.

L.

[Mirko Brankovic]

I noticed that when i inactivated mid 0 with audio i received 2 events, that my video substreams 0 and 1 stopped sending. 

Will check more on monday is it cause of something in sdp  answer or janus.

But at keast PC is alive and no dtls error ;)

Thanks

Mirko

To view this discussion on the web visit https://groups.google.com/d/msgid/meetecho-janus/ba3824e5-b8b9-4288-a0d2-5f71df7190f1n%40googlegroups.com.

[Mirko Brankovic]

The problem seems to be that inactive m= line is kept in a bundle by janus's answer and is removed in browser's offer:

https://pastebin.com/FLkRY3fm

I'm not sure what is the correct way, from reading some old threads on webrtc mailing list seems that inactive media tags shouldn't be part of bundle:

https://lists.w3.org/Archives/Public/public-webrtc/2017Aug/0076.html

[Lorenzo Miniero]

Are you stopping the transceiver, or just removing the track from it? You should do the latter.

L.

[Mirko Brankovic]

From what I can see on client side, it is a simple removeTrack() call:

        if (track) {
          await this.out.removeTrack(track);
        }

followed by a new sdp and configure request to janus.

I'll checked with colleague just in case...

Just was curious if inactive m tag sould or should not be in bundle tags, but it is more a question for webrtc list

[Mirko Brankovic]

I found that we have removeTrack() override that eventually does:

await transceiver.sender.replaceTrack(null);

which sounds plain wrong and could be messing with SDP bundle

Now I'll do the tests to see if it really is

[Mirko Brankovic]

I found the .stop(),

@lorenzo thanks for tip :)