[jitsi-dev] Playing streams from within the videobridge


#1

I am still struggling away trying to get the bridge to play a stream through a conference. My test system (which is one one machine) links two peerconnections from a browser to the bridge.

I have two experimental systems at the moment. They both aim to send an opus payload to the audiosession of the browser. One starts with the jitsi hammer rtpdump in opus format and the other tries to use the process engine to transcode from MP3 to opus (that is a bit optimistic really at this stage).

I had an interesting bug that crashed the browser when it sent the rtpdump data at the browser using the VP8 payload number rather than the opus payload number (on my implementation 100 and 111 respectively not that it matters that much). That crashed the browser media engine and everything stopped in terms of the view and audio.

What I am getting now, however, is that everything runs, but the new audio stream is reported with "failed to unprotect SRTP packet". I think that is probably because I am not sending it properly encrypted.

This may be because my output stream is an RTPConnectorUDPOutputStream rather than a TransformUDPOutputStream. I am guessing that the data is not properly encrypted which would be a good reason why unencryption would not really work.

First question, am right?

Second question (and linked) when the bridge is translating streams although it is not analysing the payload, but simply passing it on, I assume that it decrypts the streams and then re-encrypts them.
Where is that done?

I am tracking things in the Queue in RTPConnectorOutputStream and it appears that the stuff coming via the translator is not going through an encryption stage (probably because of having the wrong class for the connector).


#2

What I am getting now, however, is that everything runs, but the new audio
stream is reported with "failed to unprotect SRTP packet". I think that

is

probably because I am not sending it properly encrypted.

I'd like to be pedantic here. "failed to unprotect SRTP packet" doesn't
mean the encryption is wrong;
it means the authentication is wrong. (The encryption provides
confidentiality - no third party on the
network can make sense of the audio without the key. Authentication
ensures that no third party can
make changes to the audio without the changed packets being ignored.) If
you get the encryption
wrong, JVB will work just fine - it's just that what you hear is random
noise. (Please DAMHIKT.)

I've just grepped ice4j, jitsi-videobridge libjitsi and sdes4j, and the the
string "failed to unprotect"
does not occur. However it *does* occur in the source for WebRTC (in
srtpfilter.cc), just after it
has called into libsrtp to do the actual SRTP -> RTP transformation.

Martin

···

On 29 June 2017 at 13:25, John Hemming <john@hemming.email> wrote:


#3

An unencrypted RTP packet sent to chrome is likely to cause this error.

In libjitsi SRTP is implemented as part of the MediaStream's transform chain. All packets sent to chrome should go through this chain.

Boris

···

On 29/06/2017 08:27, John Hemming wrote:

Thanks for this. The message is a logging message from Chrome that I am getting at via Sawbuck on verbose. That is why it does not appear in any of the jitsi java code.

It raises a question as to whether errors with encryption would also cause errors with authentication.


#4

Thanks for this. The message is a logging message from Chrome that I am getting at via Sawbuck on verbose. That is why it does not appear in any of the jitsi java code.

It raises a question as to whether errors with encryption would also cause errors with authentication.

···

On 29/06/2017 13:37, Martin Bonner wrote:

On 29 June 2017 at 13:25, John Hemming <john@hemming.email> wrote:
> What I am getting now, however, is that everything runs, but the new audio
> stream is reported with "failed to unprotect SRTP packet". I think that is
> probably because I am not sending it properly encrypted.

I'd like to be pedantic here. "failed to unprotect SRTP packet" doesn't mean the encryption is wrong;
it means the authentication is wrong. (The encryption provides confidentiality - no third party on the
network can make sense of the audio without the key. Authentication ensures that no third party can
make changes to the audio without the changed packets being ignored.) If you get the encryption
wrong, JVB will work just fine - it's just that what you hear is random noise. (Please DAMHIKT.)

I've just grepped ice4j, jitsi-videobridge libjitsi and sdes4j, and the the string "failed to unprotect"
does not occur. However it *does* occur in the source for WebRTC (in srtpfilter.cc), just after it
has called into libsrtp to do the actual SRTP -> RTP transformation.

Martin

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

--

john.hemming.name <http://john.hemming.name>


#5

I think that is what is happening. I need to have a good look at what is happening. I think I may be using the wrong RTPConnectors.

···

On 29/06/2017 16:09, Boris Grozev wrote:

On 29/06/2017 08:27, John Hemming wrote:

Thanks for this. The message is a logging message from Chrome that I am getting at via Sawbuck on verbose. That is why it does not appear in any of the jitsi java code.

It raises a question as to whether errors with encryption would also cause errors with authentication.

An unencrypted RTP packet sent to chrome is likely to cause this error.

In libjitsi SRTP is implemented as part of the MediaStream's transform chain. All packets sent to chrome should go through this chain.

Boris

--

john.hemming.name <http://john.hemming.name>


#6

I think I have solved this, but I won't know until I have actually tried the changes which I will do on Monday.

I am bodging the Payload Type (from 100-111), but after encrypting the packet and adding the authentication tag. That does not affect the encryption, but does mean that the authentication tag is wrong.

This would create the initial symptoms of the packets passing authentication, but crashing the browser media engine and cause the failure of authentication once the PT is changed to 111. The obvious solution is to get the Payload Type right in the first instance.

···

On 29/06/2017 16:09, Boris Grozev wrote:

On 29/06/2017 08:27, John Hemming wrote:

Thanks for this. The message is a logging message from Chrome that I am getting at via Sawbuck on verbose. That is why it does not appear in any of the jitsi java code.

It raises a question as to whether errors with encryption would also cause errors with authentication.

An unencrypted RTP packet sent to chrome is likely to cause this error.

In libjitsi SRTP is implemented as part of the MediaStream's transform chain. All packets sent to chrome should go through this chain.

Boris

--

john.hemming.name <http://john.hemming.name>


#7

In fact that did solve this. I then managed to modify the other bits of code to add the new stream to the client and was rather sad to find that there was no sound when I tried playing hammer-opus.rtpdump. I therefore decided to experiment (wondering if in fact it is silent anyway) with narwhals (narwhals-audio.rtpdump) assuming it was opus and it did play (whether it was transcoding or not I have not bothered to check - I assume it is in opus format because the rtpdump mediadevice seems quite rudimentary).

Whilst I felt I was on a roll I simply tried to play "Monster" by "The Automatic" from an MP3 file trancoding to opus and lo and behold it played. (I had previously got it to play simply as an audio player through the speakers). I did a small number of bodges to FMJ to acheive this (there are some odd casting errors and that problem with output formats being null) as well as writing something that looked like it might work as a mediadevice of some form. It was a bit tinny and I have not checked what is happening to the stereo or anything like that, but I was quite pleased to hear the tune playing. When I play it just as an ordinary jmf/fmj player it plays with much more audio depth (again I am not checking whether it is stereo or not).

In the end I have not written a class to decode MP3 using ffmpeg, but am relying on the JavaSoundthingy.

I am quite pleased with this so will make my self a nice cup of tea and play Monster a few times (not through the transcoding though).

···

On 01/07/2017 20:41, John Hemming wrote:

I think I have solved this, but I won't know until I have actually tried the changes which I will do on Monday.

I am bodging the Payload Type (from 100-111), but after encrypting the packet and adding the authentication tag. That does not affect the encryption, but does mean that the authentication tag is wrong.

This would create the initial symptoms of the packets passing authentication, but crashing the browser media engine and cause the failure of authentication once the PT is changed to 111. The obvious solution is to get the Payload Type right in the first instance.

On 29/06/2017 16:09, Boris Grozev wrote:

On 29/06/2017 08:27, John Hemming wrote:

Thanks for this. The message is a logging message from Chrome that I am getting at via Sawbuck on verbose. That is why it does not appear in any of the jitsi java code.

It raises a question as to whether errors with encryption would also cause errors with authentication.

An unencrypted RTP packet sent to chrome is likely to cause this error.

In libjitsi SRTP is implemented as part of the MediaStream's transform chain. All packets sent to chrome should go through this chain.

Boris

--

john.hemming.name <http://john.hemming.name>

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

--

john.hemming.name <http://john.hemming.name>