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
