Question about using ICE trickling

[Anand Sivaram]

Hello All,

I am writing a C program to talk to Janus Gateway (Video Call Plugin).

What I observed:

* Registered a user "user1" from the program, registered a user "user2" from Firefox.

* Now I am trying to call user2 (Firefox) from user1 (program).  Gathered the local NICE candidates and sending them as offer to Janus.

* I did not include "a=ice-options:trickle" in my offer SDP, but included all of the gathered candidates as "a=candidate" in my offer SDP.

* I could get a new call indication on user2 (Firefox) and accepted it.

* On the Janus call leg talking to my program, I could find the following log message.  Looks as if the call is accepted, and my program receives the JSON message that user2 (Firefox) has accepted the call.

[2356519772] Done! Ready to setup remote candidates and send connectivity checks...

[2356519772]   -- ICE Trickling is supported by the browser, waiting for remote candidates...

[2356519772] Sending event to transport...

Sending event to janus.transport.http (0x7f78240008c0)

Got a Janus API event to send (0x7f78240008c0)

  >> 0 (Success)

Pushing event: {

   "videocall": "event",

   "result": {

      "event": "accepted"

   }

}

* But, It is *not* loading the remote candidates supplied by my initial SDP offer, means the function janus_ice_setup_remote_candidates() is not getting called at all.

* Now, instead I use another Firefox as user1 and trying to call user2 on Firefox, I could get the following logs instead.

[568636380] Done! Ready to setup remote candidates and send connectivity checks...

[568636380]   -- bundle is supported by the browser, getting rid of one of the RTP/RTCP components, if any...

[568636380]   -- rtcp-mux is supported by the browser, getting rid of RTCP components, if any...

[568636380]   -- Processing 15 pending trickle candidates

...... <<My Comment>>.. Could see logs to load the trickle candidates, call janus_ice_setup_remote_candidates(), then the following logs ......

[568636380]   -- ICE Trickling is supported by the browser, waiting for remote candidates...

[568636380] Sending event to transport...

Sending event to janus.transport.http (0x7f2a180008c0)

Got a Janus API event to send (0x7f2a180008c0)

  >> 0 (Success)

Pushing event: {

   "videocall": "event",

   "result": {

      "event": "accepted"

   }

}

Questions:

  * Is it possible to disable ICE trickling?

  * Even though I am sending the candidates in the original SDP, why Janus is not loading it?

    But, at the same time replying as the call is accepted?

  * To try out, I just added the extra line "a=ice-options:trickle", in my original SDP, but keeping the candidates and other lines the same,

    but, the behaviour is the same as above.

Any idea?

Thanks and Regards

Anand

[Lorenzo Miniero]

Janus should support non-trickling clients just fine. To test it with a browser, just pass a trickle:false option when doing a createOffer or createAnswer.

Besides, don't trust the logs with respect to which candidates Janus is aware of, as we don't always print everything that happens or passes by: have a look at the Admin API instead and check the related handle info.

L.

[Anand Sivaram]

Thanks Lorenzo.  I will definitely take a look at the javascript to disable trickle.

I enabled Admin API, will try the same scenario with Admin API..

[Anand Sivaram]

Thanks Lorenzo.  I will definitely take a look at the javascript to disable trickle.

I enabled Admin API, will try the same scenario with Admin API..

Anand

On Tuesday, 8 March 2016 18:43:59 UTC+5:30, Lorenzo Miniero wrote:

[Lorenzo Miniero]

Nevermind, just tested and I could verify that indeed disabling trickle the ICE checks don't start in Janus. I think this was after some fixes we made to the ICE setup in Janus, that at the moment never make ICE start when trickle is disabled. I'll try to work on a fix ASAP.

L.

[Lorenzo Miniero]

This commit should have fixed the issue:

https://github.com/meetecho/janus-gateway/commit/0127efe135664d000333d91da5c035d18bb28bfd

If you're using janus.js for your tests, make sure you're using the new version, and specifying trickle:false when doing createOffer or createAnswer, e.g.:

echotest.createOffer(

{

trickle: false,   <---- SET THIS

success: function(jsep) {

// Success callback, send to Janus

},

error: function(error) {

// Error callback

}

});

If you're doing the communication yourself, instead, you'll have to add a trickle:false attribute to the jsep object you send to Janus (along with the already present type and sdp, that is). This new attribute, in fact, is needed to explicitly tell Janus you won't be trickling, something it cannot evince on its own by just looking at the SDP.

Lorenzo

[Anand Sivaram]

Lorenzo,

I sincerely appreciate your prompt attention and fix of this issue.

Will definitely give a try as soon as possible..

Thanks and Regards

Anand

[Anand Sivaram]

Hello Lorenzo,

I pulled the latest code and tried out your fixes.  It is working.  This is what I found.

1. On Firefox browser, disabled trickle in JavaScript.

Call is going through. When trickle is disabled, Firefox is sending the gathered local audio/video candidates in the offer SDP itself.  But, I noticed that the below line is always added in the offer SDP regardless of trickle is enabled or disabled.

a=ice-options:trickle

2. Using my program:

Included "trickle":false in the JSEP object as you suggested and the call got connected.

Another observation:

I understood the rationale behind using "trickle:false in the JSEP, but I was thinking that it could be deduced from the initial offer itself.

As per this draft, https://tools.ietf.org/html/draft-ietf-mmusic-trickle-ice-02

1) a=ice-options:trickle line is needed when the caller supports ICE trickling.

(section 4 and 5.1 in the above draft)

This line could be avoided when the caller does not support trickle / does not want to use trickle.

But, as per my observation with Firefox above, this line is included regardless.  (Not sure it is like that or it is a bug)

2) Once all candidates are sent to the remote, Firefox is including the below line

a=end-of-candidates

(section 9.3 in the above draft)

I saw this as part of the original offer SDP when trickle is disabled.  Did not see it while using unmodified Janus supporting trickle.

Also I could not find any reference to the end of candidate line in Janus code.

Any thought?

Thanks and Regards

Anand

[Lorenzo Miniero]

Il giorno mercoledì 9 marzo 2016 13:32:48 UTC+1, Anand Sivaram ha scritto:

Hello Lorenzo,

I pulled the latest code and tried out your fixes.  It is working.  This is what I found.

1. On Firefox browser, disabled trickle in JavaScript.

Call is going through. When trickle is disabled, Firefox is sending the gathered local audio/video candidates in the offer SDP itself.  But, I noticed that the below line is always added in the offer SDP regardless of trickle is enabled or disabled.

a=ice-options:trickle

It's because Firefox does indeed support Trickle, even though you chose to wait for all candidates.

 

2. Using my program:

Included "trickle":false in the JSEP object as you suggested and the call got connected.

Good.

 

Another observation:

I understood the rationale behind using "trickle:false in the JSEP, but I was thinking that it could be deduced from the initial offer itself.

As per this draft, https://tools.ietf.org/html/draft-ietf-mmusic-trickle-ice-02

1) a=ice-options:trickle line is needed when the caller supports ICE trickling.

(section 4 and 5.1 in the above draft)

This line could be avoided when the caller does not support trickle / does not want to use trickle.

But, as per my observation with Firefox above, this line is included regardless.  (Not sure it is like that or it is a bug)

Yes, that's why we stopped relying on that for detecting trickle support, and the need for an out-of-band explicit indicator (our new trickle attribute in the Janus API)

 

2) Once all candidates are sent to the remote, Firefox is including the below line

a=end-of-candidates

(section 9.3 in the above draft)

I saw this as part of the original offer SDP when trickle is disabled.  Did not see it while using unmodified Janus supporting trickle.

 

Also I could not find any reference to the end of candidate line in Janus code.

Yes, we're not adding it, I guess it might be a good idea to do so. Not sure if Chrome does too.

L.

[Anand Sivaram]

Hello Lorenzo,

I disabled trickle in javascript for the video call plugin and tried calling from Firefox, Google Chrome and Chromium.

Looking at the log, I realize that it is better to keep out-of-band trickle indicator, as you did now.

Firefox:

Including both "a=ice-options:trickle" once in the beginning

and "a=end-of-candidates" three times each for audio, video and data.

Google Chrome/Chromium:

Does *not* include "a=ice-options:trickle" or "a=end-of-candidates"

at all.

All 3 offer SDP messages are there in the following pastebin.

http://pastebin.com/HUPb75kg

This is my system information:

OS: Debian GNU/Linux Sid 64bit

Firefox: IceWeasel Native on Debian 64bit: Mozilla Iceweasel 44.0.2

Google Chrome: 64bit Google Chrome 49.0.2623.87

Chromium: 64bit Chromium 49.0.2623.75 built on Debian stretch/sid

Thanks and Regards

Anand

[Lorenzo Miniero]

Thanks for running these tests: we'll keep the out-of-band trickle indicator for the time being, then.

Lorenzo