Does libsrtp support this scenarios? srtp1 and srtp2 with the same params for encryt, srtp3 decncryt the packet from srtp1 and srtp2 the same time. And I have tested it doesn't work, am i somewhere wrong?

[Bepartofyou]

test with this params

srtp_crypto_policy_set_aes_gcm_256_16_auth(&policy.rtp); srtp_crypto_policy_set_aes_gcm_256_16_auth(&policy.rtcp); if(inbound){ policy.ssrc.type = ssrc_any_inbound; }else{ policy.ssrc.type = ssrc_any_outbound; } srtp->policy.ssrc.value = 0; srtp->policy.key = (unsigned char *)key; srtp->policy.window_size = 1024; srtp->policy.allow_repeat_tx = 1; srtp->policy.next = NULL;

[paulej]

I'm not really sure what you mean by "srtp1" and "srtp2". Are you talking about two srtp crypto contexts (i.e., those things create by srtp_create()) or are you referring to two different streams (i.e., those things created with srtp_add_stream())? You can only have one default inbound OR outbound policy. However, you can have different policies for different SSRCs.

You can also have any number different SRTP "sessions" (via srtp_create()). Each one is independent of the other, so keys and policies do not conflict across sessions.

[Bepartofyou]

two srtp crypto contexts, and they have the same policy setting and only 'one and same' ssrc. so how to express...

Two real app client with the same code , so the policy ,the ssrc and the srtp context using the same method to create, and one real app server receive the former two app clients' packets meantime, and decrypt, error with status_err_auth. But if the server just receive any one of the app client's packets , it's OK.

[pabuhler]

@Bepartofyou If I understand you correctly then no this will not work. SRTP requires each packet with the same SSRC to have a unique sequence number and they need to be in increasing order with little or no gaps. If you have two sources generating RTP packets with same SSRC this will most likely not work. You could change the SSRC on one of the sources or add a second decoder and separate the receiving of the two streams.

[Bepartofyou]

@pabuhler @paulej thanks for reply me! Maybe I still haven't express exactly.

srtp contexts are the former setting, the two client with the same ssrc , also sequence is monotonous， for example, client_1 has '135' and client_2 has '246', and server decrypt '123456', that is the scenarios.

client ---> proxy ----->server, i describe the two clients are 'client' and 'proxy', proxy only decrypt some of the packets from client , handling(no changing the packets contents) and then cenrypt the 'decrypted packets' with the client same setting , relaying to server. So server can receive the packets from two srtp contexts. Does this work ?

[paulej]

So what you're saying is that srtp1 and srtp2 might be two different machines with, obviously, two different crypto contexts, but using the same ssrc, and srtp3 might be a receiving machine merging flows from srtp1 and srtp2 and using a single crypto context?

Do I understand the scenario correctly?

[Bepartofyou]

@paulej Yes. Is this work ?

[paulej]

In theory, yes. Libsrtp has no idea where packets come from. As long as the same key, salt, and ROC are used, it should work. However, my concern is that one of the transmitters might send at a higher rate than the other and the ROC values don't match. IMO, this is a risky design. Why not treat these as separate sources (SSRCs) with each having a distinct sequence number space?

[Bepartofyou]

this is used in webrtc tunnel， client->proxy->server，proxy has server‘s nack function， so it will receive client encrypted RTX RTP packets and send NACK RTCP packets to client，just like server’s nack function。And now i will decrypt encrypt all packets from client and server, so the client to proxy and proxy to server will have the one to one srtp contexts, it need some cpus for reduplicative work encyrpt and decrypt for all other unused packets ，but it works well

[paulej]

So what's the problem? If two senders are just splitting the computational work of sending a media flow, it should work. As i mentioned, libsrtp doesn't know where packets came from. You should be able to use the test code to prove that or to show there is a problem. Maybe in the context of the test code, the issue (if there is one) might be clearer.

[Bepartofyou]

@paulej thanks, i will do more tests and test with more version. i just used v2.0.0. issue close temporarily, and any progress will feedback here.

[Bepartofyou]

I do some tests on Mac OS, and the results is here. https://github.com/Bepartofyou/libsrtp.multi.context.test

the same code, just with different srtp context encrypt like former describe, and two encrypt srtp contexts will lead to error with only one decrypt srtp context. Test version 2.0 2.1 2.2 and master

[pabuhler]

Hi @Bepartofyou the link was a bit hard to follow, but I did see that you are also encrypting RTCP with two different contexts, this will not work with libsrtp. Each RTCP packet that is encrypted has an SRTCP index added to the packet, this index will need to be unique and increasing for each SSRC. If there is no synchronization between encryption contexts then this index will end up with duplicate or "old" values.

It maybe be possible that you can use just one context for RTCP while still splitting RTP across multiple contexts.

[Bepartofyou]

@pabuhler thanks for opinion. I'm not very familiar to libsrtp，so i try just use one to one pattern now.

[pabuhler]

@Bepartofyou ok, in that case I will close this issue for now. If you find and issue with libsrtp then please reopen it.