[jitsi-dev] rtcp-mux without bundle


#1

Hi, There

I'm using a gstreamer based endpoint which support rtcp-mux but not bundle. However jicofo always create conference endpoint without rtcp-mux if bundle suppport is not included in the jingle disco list. Can I enable rtcp-mux without bundle? if so how should I configure this in the jingle client?

thanks

Xiaoyong


#2

Hi Xiaoyong,

Hi, There

I'm using a gstreamer based endpoint which support rtcp-mux but not bundle. However�jicofo�always create conference endpoint without rtcp-mux if bundle suppport is not included in the jingle disco list. Can I enable rtcp-mux without bundle? if so how should I configure this in the jingle client?

That's an interesting question. Videobridge should support rtcp-mux without bundle, but so far we have always used the two together and jicofo always uses them together, so I am not sure that everything will work as expected. It will require some fiddling and experimentation.

With jicofo you should be able to get this to work by doing the following:
1. Remove support for bundle from the Jingle client[0]. This will make jicofo create a non-bundle and non-rtcp-mux offer.
2. Make sure that dynamic ports on the bridge work (you can access UDP/10001-20000 by default). It will generate candidates for both RTP and RTCP.
3. Modify the client to remove the RTCP candidates and insert rtcp-mux into the remote offer. This should result in the answer sent to jicofo to contain rtcp-mux.

When this rtcp-mux answer reaches the bridge, it should close it's ICE component for RTCP and enable rtcp-mux[1,2].

Regards,
Boris

[0] https://github.com/jitsi/lib-jitsi-meet/blob/master/modules/xmpp/xmpp.js#L103
[1] https://github.com/jitsi/jitsi-videobridge/blob/master/src/main/java/org/jitsi/videobridge/IceUdpTransportManager.java#L1281
[2] https://github.com/jitsi/jitsi-videobridge/blob/master/src/main/java/org/jitsi/videobridge/IceUdpTransportManager.java#L1300

···

On 24/05/2018 13:36, Xiaoyong Zhou wrote:


#3

Thanks a lot Boris, this looks promising, as I've tried 1 and 2 and it seems act as expected.

Another problem I'm struggling with is the gst webrtcbin current desn't include ssrc in the answer it created. jicofo seems rely on it to propagate source-add info to other participates, do you have some suggestions on whether I can work around it or better just try get the ssrc for sdp/jingle session info.

thanks

Xiaoyong

···

________________________________
From: Boris Grozev <boris@sip-communicator.org> on behalf of Boris Grozev <boris@jitsi.org>
Sent: Thursday, May 24, 2018 2:02:33 PM
To: Jitsi Developers; Xiaoyong Zhou
Subject: Re: [jitsi-dev] rtcp-mux without bundle

Hi Xiaoyong,

On 24/05/2018 13:36, Xiaoyong Zhou wrote:

Hi, There

I'm using a gstreamer based endpoint which support rtcp-mux but not
bundle. However jicofo always create conference endpoint without
rtcp-mux if bundle suppport is not included in the jingle disco list.
Can I enable rtcp-mux without bundle? if so how should I configure this
in the jingle client?

That's an interesting question. Videobridge should support rtcp-mux
without bundle, but so far we have always used the two together and
jicofo always uses them together, so I am not sure that everything will
work as expected. It will require some fiddling and experimentation.

With jicofo you should be able to get this to work by doing the following:
1. Remove support for bundle from the Jingle client[0]. This will make
jicofo create a non-bundle and non-rtcp-mux offer.
2. Make sure that dynamic ports on the bridge work (you can access
UDP/10001-20000 by default). It will generate candidates for both RTP
and RTCP.
3. Modify the client to remove the RTCP candidates and insert rtcp-mux
into the remote offer. This should result in the answer sent to jicofo
to contain rtcp-mux.

When this rtcp-mux answer reaches the bridge, it should close it's ICE
component for RTCP and enable rtcp-mux[1,2].

Regards,
Boris

[0]
https://github.com/jitsi/lib-jitsi-meet/blob/master/modules/xmpp/xmpp.js#L103
[1]
https://github.com/jitsi/jitsi-videobridge/blob/master/src/main/java/org/jitsi/videobridge/IceUdpTransportManager.java#L1281
[2]
https://github.com/jitsi/jitsi-videobridge/blob/master/src/main/java/org/jitsi/videobridge/IceUdpTransportManager.java#L1300


#4

Hi Xiaoyong,

···

On 24/05/2018 16:32, Xiaoyong Zhou wrote:

Thanks a lot Boris, this looks�promising, as I've tried 1 and 2 and it seems act as expected.

Another problem I'm struggling with is the gst webrtcbin current desn't include ssrc in the answer it created. jicofo seems rely on it to propagate source-add info to other participates, do you have some suggestions on whether I can work around it or better just try get the ssrc for sdp/jingle session info.

If the other clients are web browsers you will need to propagate the SSRC to them (via source-add), otherwise they will simply not playback/render the streams.

Regards,
Boris


#5

that makes sense. thanks Boris

···

________________________________
From: Boris Grozev <boris@sip-communicator.org> on behalf of Boris Grozev <boris@jitsi.org>
Sent: Thursday, May 24, 2018 2:39:31 PM
To: Xiaoyong Zhou; Jitsi Developers
Subject: Re: [jitsi-dev] rtcp-mux without bundle

Hi Xiaoyong,

On 24/05/2018 16:32, Xiaoyong Zhou wrote:

Thanks a lot Boris, this looks promising, as I've tried 1 and 2 and it
seems act as expected.

Another problem I'm struggling with is the gst webrtcbin current desn't
include ssrc in the answer it created. jicofo seems rely on it to
propagate source-add info to other participates, do you have some
suggestions on whether I can work around it or better just try get the
ssrc for sdp/jingle session info.

If the other clients are web browsers you will need to propagate the
SSRC to them (via source-add), otherwise they will simply not
playback/render the streams.

Regards,
Boris


#6

Hi, Boris/Jitsi

Thanks for the prompt helps. I made a little bit progress on my integration of gstreamer and jitsi by incorporating changes that generate initial ssrc for an sdp answer. Now my jitsi meet browser client shows my gstreamer participant and shows they have two streams. However the content of the stream are not there yet.

It turns out the gst webrtc doesn't support re-negotiation so I cannot simply set remote offer again after getting source-add, instead I have to create a new webrtc pipeline which will have an new sdp answer. it is mostly same as the first sdp answer, however the ice configuration has changed so the ufrag/pwd has changed. Is there a way to propagate this change from a client to jvb through jicofo?

thanks

Xiaoyong

···

________________________________
From: Boris Grozev <boris@sip-communicator.org> on behalf of Boris Grozev <boris@jitsi.org>
Sent: Thursday, May 24, 2018 2:39:31 PM
To: Xiaoyong Zhou; Jitsi Developers
Subject: Re: [jitsi-dev] rtcp-mux without bundle

Hi Xiaoyong,

On 24/05/2018 16:32, Xiaoyong Zhou wrote:

Thanks a lot Boris, this looks promising, as I've tried 1 and 2 and it
seems act as expected.

Another problem I'm struggling with is the gst webrtcbin current desn't
include ssrc in the answer it created. jicofo seems rely on it to
propagate source-add info to other participates, do you have some
suggestions on whether I can work around it or better just try get the
ssrc for sdp/jingle session info.

If the other clients are web browsers you will need to propagate the
SSRC to them (via source-add), otherwise they will simply not
playback/render the streams.

Regards,
Boris


#7

Hi Xiaoyong,

Hi, Boris/Jitsi

Thanks for the prompt helps. I made a little bit progress on my�integration of gstreamer and jitsi�by incorporating changes that�generate initial ssrc for an sdp answer. Now my jitsi meet browser client shows my gstreamer participant and shows they have two streams. However the content of the stream are not there yet.

It turns out the gst webrtc doesn't support re-negotiation so I cannot simply set remote offer again after getting source-add,

Why do you need to do this? If gst is streaming, you only need to set the remote offer on the receiver side.

instead I have to create a new webrtc pipeline which will have an new sdp answer. it is mostly same as the first sdp answer, however the ice configuration has changed so the ufrag/pwd has changed. Is there a way to propagate this change from a client to jvb through jicofo?

This would be very tricky. If the ufrag/pwd changed there is nothing in jitsi-videobridge that you can re-use -- you will need a complete new session.

Regards,
Boris

···

On 01/06/2018 13:46, Xiaoyong Zhou wrote:


#8

Thanks Boris

yes, ideally I would like to just set the remote offer again on my webrtcbin. It is currently modeled after peerconnection in browser so is both sender and receiver.

I will try to fiddle with gstreamer a little more and see whether I can reuse the niceagent there

thanks

Xiaoyong

···

________________________________
From: Boris Grozev <boris@sip-communicator.org> on behalf of Boris Grozev <boris@jitsi.org>
Sent: Friday, June 1, 2018 12:46:42 PM
To: Xiaoyong Zhou; Jitsi Developers
Subject: Re: [jitsi-dev] rtcp-mux without bundle

Hi Xiaoyong,

On 01/06/2018 13:46, Xiaoyong Zhou wrote:

Hi, Boris/Jitsi

Thanks for the prompt helps. I made a little bit progress on
my integration of gstreamer and jitsi by incorporating changes
that generate initial ssrc for an sdp answer. Now my jitsi meet browser
client shows my gstreamer participant and shows they have two streams.
However the content of the stream are not there yet.

It turns out the gst webrtc doesn't support re-negotiation so I cannot
simply set remote offer again after getting source-add,

Why do you need to do this? If gst is streaming, you only need to set
the remote offer on the receiver side.

instead I have
to create a new webrtc pipeline which will have an new sdp answer. it is
mostly same as the first sdp answer, however the ice configuration has
changed so the ufrag/pwd has changed. Is there a way to propagate this
change from a client to jvb through jicofo?

This would be very tricky. If the ufrag/pwd changed there is nothing in
jitsi-videobridge that you can re-use -- you will need a complete new
session.

Regards,
Boris


#9

Hi, Boris

Just an update, I finally make simple gstreamer webrtcbin video/audio connecting to jicofo/jvb works. As we discussed last week its actually just ice issue. I have to make sure using same nice agent and ice candidates pairs.

thanks

Xiaoyong

···

________________________________
From: Xiaoyong Zhou
Sent: Friday, June 1, 2018 1:49:48 PM
To: Boris Grozev; Jitsi Developers
Subject: Re: [jitsi-dev] rtcp-mux without bundle

Thanks Boris

yes, ideally I would like to just set the remote offer again on my webrtcbin. It is currently modeled after peerconnection in browser so is both sender and receiver.

I will try to fiddle with gstreamer a little more and see whether I can reuse the niceagent there

thanks

Xiaoyong

________________________________
From: Boris Grozev <boris@sip-communicator.org> on behalf of Boris Grozev <boris@jitsi.org>
Sent: Friday, June 1, 2018 12:46:42 PM
To: Xiaoyong Zhou; Jitsi Developers
Subject: Re: [jitsi-dev] rtcp-mux without bundle

Hi Xiaoyong,

On 01/06/2018 13:46, Xiaoyong Zhou wrote:

Hi, Boris/Jitsi

Thanks for the prompt helps. I made a little bit progress on
my integration of gstreamer and jitsi by incorporating changes
that generate initial ssrc for an sdp answer. Now my jitsi meet browser
client shows my gstreamer participant and shows they have two streams.
However the content of the stream are not there yet.

It turns out the gst webrtc doesn't support re-negotiation so I cannot
simply set remote offer again after getting source-add,

Why do you need to do this? If gst is streaming, you only need to set
the remote offer on the receiver side.

instead I have
to create a new webrtc pipeline which will have an new sdp answer. it is
mostly same as the first sdp answer, however the ice configuration has
changed so the ufrag/pwd has changed. Is there a way to propagate this
change from a client to jvb through jicofo?

This would be very tricky. If the ufrag/pwd changed there is nothing in
jitsi-videobridge that you can re-use -- you will need a complete new
session.

Regards,
Boris