[jitsi-dev] JVB: question about direction field in REST interface


#1

Hi all,

I checked the REST example recently updated using Brian Baldino's one: https://github.com/jitsi/jitsi-videobridge/blob/master/doc/rest-videobridge.md and I noticed that for the audio channel the direction is set to "sendrecv" in the first patch, then JVB answers "recvonly" for audio, and then in the new patch of this example I see "sendonly".

Why in this last patch a direction = "sendonly" is used?

I'm asking that because actually in our system we set always direction="sendrecv" in our PATCHes, and since sometimes we experienced this issue https://github.com/jitsi/jitsi-videobridge/issues/230 finally we found out that it was caused by this race:

  * ICE handshake successfully completed, so the streamTarget is set;
  * the PATCH reaches JVB before the first audio packet from the client, so the RtpChannel's setDirection method is called, the check (streamTarget.getDataAddress() != null) is true so the stream's direction is changed to sendrecv and the bridge starts sending audio too early.

Practically we have the issue every time the PATCH reaches JVB between terminating the ICE handshake and receiving the first audio packet from the client.
We solved that enforcing the condition in the setDirection method, ensuring that we already received audio before to change to sendrecv, but I wonder if maybe we're wrong in setting direction=sendrecv always.

Thanks,
Matteo


#2

I forgot to mention that we use only audio, with rtp-level-relay-type = mixer in this case.

Cheers,

Matteo

···

________________________________
From: Matteo Campana
Sent: Thursday, November 3, 2016 12:22 PM
To: Jitsi Developers
Subject: JVB: question about direction field in REST interface

Hi all,

I checked the REST example recently updated using Brian Baldino's one: https://github.com/jitsi/jitsi-videobridge/blob/master/doc/rest-videobridge.md and I noticed that for the audio channel the direction is set to "sendrecv" in the first patch, then JVB answers "recvonly" for audio, and then in the new patch of this example I see "sendonly".

Why in this last patch a direction = "sendonly" is used?

I'm asking that because actually in our system we set always direction="sendrecv" in our PATCHes, and since sometimes we experienced this issue https://github.com/jitsi/jitsi-videobridge/issues/230 finally we found out that it was caused by this race:

  * ICE handshake successfully completed, so the streamTarget is set;
  * the PATCH reaches JVB before the first audio packet from the client, so the RtpChannel's setDirection method is called, the check (streamTarget.getDataAddress() != null) is true so the stream's direction is changed to sendrecv and the bridge starts sending audio too early.

Practically we have the issue every time the PATCH reaches JVB between terminating the ICE handshake and receiving the first audio packet from the client.
We solved that enforcing the condition in the setDirection method, ensuring that we already received audio before to change to sendrecv, but I wonder if maybe we're wrong in setting direction=sendrecv always.

Thanks,
Matteo


#3

Hi !

I'm trying to change the call sound (incomingCall) with provisioning.

On manuel change, it's work, but not with provisioning, due to the eventType number.

Can you help me ?

···

--
Rocco Sette
netika Technicien Système & Réseau
3 rue de Sarrelouis - 67000 Strasbourg
rocco.sette@netika.net <mailto:rocco.sette@netika.net>
Hotline KaliLab : +33 (0)3 68 46 16 50
Accueil : +33 (0)3 68 46 16 28
Fax : +33 (0)3 88 52 82 02

Twitter <https://twitter.com/netika_france> LinkedIN <http://www.linkedin.com/company/netika-sarl> Viadeo <http://www.viadeo.com/v/company/netika>

La préservation de l'environnement est un exercice quotidien : n'imprimez ce mail que si nécessaire.


#4

Hey Matteo,
When doing audio mixing, the bridge wants to receive audio packets before
it will send any so it knows which format to use, therefore even if you
marked the channel as 'sendrecv' in the allocation request, it will be
marked as 'recvonly' (which is from the bridge's point of view) in the
response. Then you'll use that allocation response to build an offer to
the client. The next chunk (with the 'sendonly') is actually a typo in the
example...the 'sendonly' is from the client's answer (which is from the
client's perspective) and the directions need to be 'translated' to be from
the bridge's perspective, so you're right...it should read 'recvonly'
there. Now, even if you fix that, once the bridge receives a packet you'll
need to re-do the offer/answer with both sides saying 'sendrecv', so it's a
bit tricky. At Highfive we have some local patches to work around this and
have the bridge choose the preferred audio format from the offer (rather
than waiting for a packet) so we can avoid the awkward, temporary
'recvonly' situation. It's on our list to get a PR for this set up, but
I'm afraid we haven't gotten around to it yet.

I assume you do need the audio mixing? If not you can disable that (change
"rtp-level-relay-type": "mixer" in the channel allocation for the audio
channel to "rtp-level-relay-type": "translator") and avoid this whole
situation.

hope this helps,
brian

···

On Thu, Nov 3, 2016 at 4:22 AM, Matteo Campana <matteo.campana@qnective.com> wrote:

Hi all,

I checked the REST example recently updated using Brian Baldino's one:
https://github.com/jitsi/jitsi-videobridge/blob/master/
doc/rest-videobridge.md and I noticed that for the audio channel the
direction is set to "sendrecv" in the first patch, then JVB answers
"recvonly" for audio, and then in the new patch of this example I see
"sendonly".

Why in this last patch a direction = "sendonly" is used?

I'm asking that because actually in our system we set always
direction="sendrecv" in our PATCHes, and since sometimes we experienced
this issue https://github.com/jitsi/jitsi-videobridge/issues/230 finally
we found out that it was caused by this race:

   - ICE handshake successfully completed, so the streamTarget is set;
   - the PATCH reaches JVB before the first audio packet from the client,
   so the RtpChannel's setDirection method is called, the check (
   streamTarget.getDataAddress() != null) is true so the stream's
   direction is changed to sendrecv and the bridge starts sending audio too
   early.

Practically we have the issue every time the PATCH reaches JVB between
terminating the ICE handshake and receiving the first audio packet from the
client.
We solved that enforcing the condition in the setDirection method,
ensuring that we already received audio before to change to sendrecv, but I
wonder if maybe we're wrong in setting direction=sendrecv always.

Thanks,
Matteo

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#5

I'm trying to change the call sound (incomingCall) with provisioning.

On manuel change, it's work, but not with provisioning, due to the
eventType number.

You can provision the entire net.java.sip.communicator.impl.notifications section, then the eventTypes will be recognized. I'm not aware of any better way, sorry.

Can you help me ?

Ingo


#6

Hi Brian,

thanks for your answer.

Now I understand your example, I was confused by the 'sendonly' typo! Maybe when you have time you can fix the documentation.

We need audio mixing too, and as I said in our case we patch always with "sendrecv" so I think we save a round of offer/answer compared to your case, and we have a patch to ensure that we already received audio before to change the direction to sendrecv; this patch avoids the race that sometimes caused https://github.com/jitsi/jitsi-videobridge/issues/230 for us.

Cheers,

Matteo

···

________________________________
From: dev <dev-bounces@jitsi.org> on behalf of Brian Baldino <brian@highfive.com>
Sent: Monday, November 7, 2016 8:01 PM
To: Jitsi Developers
Subject: Re: [jitsi-dev] JVB: question about direction field in REST interface

Hey Matteo,
When doing audio mixing, the bridge wants to receive audio packets before it will send any so it knows which format to use, therefore even if you marked the channel as 'sendrecv' in the allocation request, it will be marked as 'recvonly' (which is from the bridge's point of view) in the response. Then you'll use that allocation response to build an offer to the client. The next chunk (with the 'sendonly') is actually a typo in the example...the 'sendonly' is from the client's answer (which is from the client's perspective) and the directions need to be 'translated' to be from the bridge's perspective, so you're right...it should read 'recvonly' there. Now, even if you fix that, once the bridge receives a packet you'll need to re-do the offer/answer with both sides saying 'sendrecv', so it's a bit tricky. At Highfive we have some local patches to work around this and have the bridge choose the preferred audio format from the offer (rather than waiting for a packet) so we can avoid the awkward, temporary 'recvonly' situation. It's on our list to get a PR for this set up, but I'm afraid we haven't gotten around to it yet.

I assume you do need the audio mixing? If not you can disable that (change "rtp-level-relay-type": "mixer" in the channel allocation for the audio channel to "rtp-level-relay-type": "translator") and avoid this whole situation.

hope this helps,
brian

On Thu, Nov 3, 2016 at 4:22 AM, Matteo Campana <matteo.campana@qnective.com<mailto:matteo.campana@qnective.com>> wrote:

Hi all,

I checked the REST example recently updated using Brian Baldino's one: https://github.com/jitsi/jitsi-videobridge/blob/master/doc/rest-videobridge.md and I noticed that for the audio channel the direction is set to "sendrecv" in the first patch, then JVB answers "recvonly" for audio, and then in the new patch of this example I see "sendonly".

Why in this last patch a direction = "sendonly" is used?

I'm asking that because actually in our system we set always direction="sendrecv" in our PATCHes, and since sometimes we experienced this issue https://github.com/jitsi/jitsi-videobridge/issues/230 finally we found out that it was caused by this race:

  * ICE handshake successfully completed, so the streamTarget is set;
  * the PATCH reaches JVB before the first audio packet from the client, so the RtpChannel's setDirection method is called, the check (streamTarget.getDataAddress() != null) is true so the stream's direction is changed to sendrecv and the bridge starts sending audio too early.

Practically we have the issue every time the PATCH reaches JVB between terminating the ICE handshake and receiving the first audio packet from the client.
We solved that enforcing the condition in the setDirection method, ensuring that we already received audio before to change to sendrecv, but I wonder if maybe we're wrong in setting direction=sendrecv always.

Thanks,
Matteo

_______________________________________________
dev mailing list
dev@jitsi.org<mailto:dev@jitsi.org>
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#7

Hi !

Thank's for the response, can you give me an example with a basic path ?

Regards,

···

Le 04/11/2016 à 12:19, Ingo Bauersachs a écrit :

I'm trying to change the call sound (incomingCall) with provisioning.

On manuel change, it's work, but not with provisioning, due to the
eventType number.

You can provision the entire net.java.sip.communicator.impl.notifications section, then the eventTypes will be recognized. I'm not aware of any better way, sorry.

Can you help me ?

Ingo

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

--
Rocco Sette
netika Technicien Système & Réseau
3 rue de Sarrelouis - 67000 Strasbourg
rocco.sette@netika.net <mailto:rocco.sette@netika.net>
Hotline KaliLab : +33 (0)3 68 46 16 50
Accueil : +33 (0)3 68 46 16 28
Fax : +33 (0)3 88 52 82 02

Twitter <https://twitter.com/netika_france> LinkedIN <http://www.linkedin.com/company/netika-sarl> Viadeo <http://www.viadeo.com/v/company/netika>

La préservation de l'environnement est un exercice quotidien : n'imprimez ce mail que si nécessaire.


#8

Hi again !

Someone can help me ? :confused:

Regards,

···

Le 04/11/2016 à 13:00, Rocco Sette a écrit :

Hi !

Thank's for the response, can you give me an example with a basic path ?

Regards,

Le 04/11/2016 à 12:19, Ingo Bauersachs a écrit :

I'm trying to change the call sound (incomingCall) with provisioning.

On manuel change, it's work, but not with provisioning, due to the
eventType number.

You can provision the entire net.java.sip.communicator.impl.notifications section, then the eventTypes will be recognized. I'm not aware of any better way, sorry.

Can you help me ?

Ingo

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

--
Rocco Sette
netika Technicien Système & Réseau
3 rue de Sarrelouis - 67000 Strasbourg
rocco.sette@netika.net <mailto:rocco.sette@netika.net>
Hotline KaliLab : +33 (0)3 68 46 16 50
Accueil : +33 (0)3 68 46 16 28
Fax : +33 (0)3 88 52 82 02

Twitter <https://twitter.com/netika_france> LinkedIN <http://www.linkedin.com/company/netika-sarl> Viadeo <http://www.viadeo.com/v/company/netika>

La préservation de l'environnement est un exercice quotidien : n'imprimez ce mail que si nécessaire.

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

--
Rocco Sette
netika Technicien Système & Réseau
3 rue de Sarrelouis - 67000 Strasbourg
rocco.sette@netika.net <mailto:rocco.sette@netika.net>
Hotline KaliLab : +33 (0)3 68 46 16 50
Accueil : +33 (0)3 68 46 16 28
Fax : +33 (0)3 88 52 82 02

Twitter <https://twitter.com/netika_france> LinkedIN <http://www.linkedin.com/company/netika-sarl> Viadeo <http://www.viadeo.com/v/company/netika>

La préservation de l'environnement est un exercice quotidien : n'imprimez ce mail que si nécessaire.