Asterisk SFU Video Conferencing


#1

Hi,

I am testing WebRTC video conferencing using the asterisk confbridge application in SFU mode.
It is working fine when the parties get added to the conference but when a party adds new track like screen share stream the client is sending Invite for renegotiation to asterisk for which asterisk is responding back but it is not sending the update streams to the other parties in the conference.

Why is it not sending it to other parties the updated new streams ?

thanks


#2

How exactly are you adding the track? Are you removing the webcam video track? The SFU only currently forwards a single stream, although there is a patch up[1] to change this.

[1] https://gerrit.asterisk.org/#/c/asterisk/+/10818/


#3

Hi jcolp,

On the client side i am using JsSIP.
I am calling getusermedia to get the screen stream. After getting the stream i am calling RTCPeerconnection addtrack method for all the tracks in the stream and wait for Negotiation needed event. Once I get the event and isReadyToReOffer is true i am calling renegotiate method of JsSIP.

I am enclosing the asterisk trace for the same. I am testing with Firefox two tabs in the same machine.

thanks…

asteriskTrace.txt (67.6 KB)


#4

You can only currently send a single video track to Asterisk to act as a source of video. Are you removing the webcam one?

I also don’t know if anyone has tested with Firefox in that scenario.


#5

I am not removing webcam one as i will need both the streams for the other parties to see…

Will the patch suggested by you in the link before resolve this issue ?? or asterisk can only support one video stream even after that patch ?

thanks…


#6

The patch was written to do such a thing from what I remember.


#7

Hi jcolp,

Hope you are doing fine. i have tried with the patch you suggested but its not working.
asterisk is not generating new invite to others parties :frowning:

thanks…


#8

The code may not be recognizing it as a new stream, as it appears it replaced an existing stream that was being used to send video to the browser - instead of adding a new one. That scenario hasn’t been tested out for this usage.


#9

The renegotiate is not support by the patch. The patch only works if you add two video tracks before first joining the meeting.

I think you can try to add two video track at the beginning, but with one video track disabled, then enable the track when you needed to work around with the situation.

By the way, the problem is caused by the server do not update the video stream during the renegotiate, seems a little bit complicate.


#10

Thanks chenxiemin.
We will try this method. Right now i have tried with only one stream at a time using the replaceTrack method and it is working fine. As my requirement is two have two stream i will try your suggested method.

While testing i am getting these errors…

[Jan 18 15:59:21] WARNING[23786][C-00000003]: res_srtp.c:493 ast_srtp_protect: SRTP protect: replay check failed (index too old)
[Jan 18 15:59:21] WARNING[23786][C-00000003]: res_srtp.c:493 ast_srtp_protect: SRTP protect: replay check failed (index too old)
[Jan 18 15:59:21] WARNING[23786][C-00000003]: res_srtp.c:493 ast_srtp_protect: SRTP protect: replay check failed (index too old)
[Jan 18 15:59:21] WARNING[23786][C-00000003]: res_srtp.c:493 ast_srtp_protect: SRTP protect: replay check failed (index too old)
[Jan 18 15:59:21] WARNING[23786][C-00000003]: res_srtp.c:493 ast_srtp_protect: SRTP protect: replay check failed (index too old)
[Jan 18 15:59:21] WARNING[23786][C-00000003]: res_srtp.c:493 ast_srtp_protect: SRTP protect: replay check failed (index too old)
[Jan 18 15:59:22] WARNING[23786][C-00000003]: res_srtp.c:493 ast_srtp_protect: SRTP protect: replay check failed (index too old)
[Jan 18 15:59:22] WARNING[23786][C-00000003]: res_srtp.c:493 ast_srtp_protect: SRTP protect: replay check failed (index too old)

and

== SRTP unprotect failed on SSRC 1463710576 because of authentication failure 160
== SRTP unprotect failed on SSRC 1463710576 because of authentication failure 160
== SRTP unprotect failed on SSRC 1463710576 because of authentication failure 160
== SRTP unprotect failed on SSRC 1463710576 because of authentication failure 160
== SRTP unprotect failed on SSRC 1463710576 because of authentication failure 160
== SRTP unprotect failed on SSRC 1463710576 because of authentication failure 160
== SRTP unprotect failed on SSRC 1463710576 because of authentication failure 160

sometimes because of which Video is not working once this error starts coming.

thanks in advance


#11

HI,

Can anyone give me some pointers how to fix this errors and when do they occur ?

thanks in advance…


#12

I’ve seen this happen when out of order old packets arrive, but it may be in your case the use of replaceTrack. Are you seeing them when you aren’t doing any track/stream manipulation?


#13

Hi jcolp,

I was having this problem even without replaceTrack. When such situation comes how can we correct it ?

thanks and regards,


#14

There is no answer to that because you have to dig into things to understand precisely what is going on in the scenario. It’s either a bug in libsrtp, a bug in Asterisk, or somehow a bug in the browser.


#15

oh ok…

i was wondering did such inquiry came before or is it new issue.

thanks and regards


#16

Is it anything related to rtcp mux ? hope asterisk supports it right…

thanks and regards


#17

No, the message would state SRTCP if it were a problem in that regard.


#18

Does the asterisk conf bridge support Bundle-only ?
Right now i see it is not working even though bundle=yes in pjsip.conf. do we need to configure anything additional in asterisk to support it ?

Thanks and Regards


#19

The ConfBridge part doesn’t care about bundle or have knowledge of it. For WebRTC you should set the “webrtc” option to yes. Otherwise you’ll need to be more specific about the scenario.


#20

Hi jcolp,

i am adding two local video stream to the RTCPeerConnection. The firefox browser is constructing the SDP with m=video xxx and other with m=video 0 with a=bundle-only as per the WebRTC JSEP standard
“If the m= section is marked as bundle-only, then the port value
MUST be set to 0.”

in return when asterisk is sending back m=video 0… without any attributes, firefox browser is treating RTCRTPTransceiver as closed as per the standard again
“The stop method stops an RtpTransceiver. This will cause future
calls to createOffer to generate a zero port for the associated m=
section.”

So my second stream Transceiver is getting closed and i am not able to use it.

So i was wondering bundle-only + zero port combination probably requires different behavior from the asterisk.

Thanks and Regards,