when remb are sent?

[Emanuele Bizzarri]

Hi,
is it possible that REMB packets are sent only if the peerConnection is transmitting a local stream?
If I don't add a local stream to the peer connection, but I use it only for receiving, it seems that remb are not received from the transmitting side.
I also tried demo peerconnection/pc1 (webrtc samples) and from webrtc-internals I see that googAvailableReceiveBandwidth stay at 0 on tx side.
My expectation was that remb are trasmitted from rx to tx.







can you give me some information about this?

Thank you in advance

Emanuele

[emanuele bizzarri]

I'm using chrome Version 51.0.2704.63 m (64-bit)

And currently I understand that googAvailablereceiveBandwith is calculated on the receiving side, so the graph is correct on the tx side.

But I continue to not understand why I'm not receiving remb in my mcu if the browser doesn't transmit something.

From webrtc-internal is possible to see if remb are received? 

[Emanuele Bizzarri]

Sorry for the previous post, they are quite confused.
Currently the situation seems more clear to me.

googAvailableSendBandwidth if the right graph to look at.
And seems that googAvailableSendBandwidth is calculated in combination of both RR and REMB.
If mcu doesn't forward any of them the googAvailableSendBandwidth stay at 300k level (maybe the default).
If mcu forwards REMB and/or RR googAvailableSendBandwidth  starts changing.

And seems that chrome doesn't send REMB if the local stream is not added to the peerConnection.
Trying with firefox I receive REMB for receiving only peerconnections.

I don't know how to replicate this using webrtc samples.

Maybe someone could help on this.

Thank you

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/31afa668-a46c-4482-94aa-bed768e62650%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Lorenzo Miniero]

REMB definitely works for us (in Janus) for receive-only streams, or at least they did last time I checked. Not sure what we're doing to make this happen, though, apart from negotiating support for it in the SDP.

Lorenzo

[Emanuele Bizzarri]

Hi Lorenzo,
thank you for your response.
I discovered this implementing multi stream in a single peer connection, and I'm not sure if something is wrong in our implementation or in chrome.

In our old mcu, where we have one connection per stream (rx or tx), REMB are received correctly by mcu from rx only peerconnections.

The new mcu manages always the offer of sdp and it contains always:
a=sendrecv
a=rtcp-mux

On client side, I add the local stream only if the user has video/audio enabled.
What happens with chrome 51 is that the rx only client doesn't send REMB.
Maybe RR are enough for congestion and bandwidth control, because I see that on the tx side googAvailableSendBandwidth changes and the bitrate adapts quite well.
But my expectation is to see REMB from rx to tx.
And this is what I see using firefox.

So maybe have I to change dinamically:
a=sendrecv > a=recvonly
and viceversa?

Any suggestion could be useful

Thak you

Emanuele

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/c3eefd65-ff68-43ee-8cda-cd6af7bb62bd%40googlegroups.com.

[Lorenzo Miniero]

Ah, sorry, missed the part on multistream. We don't do that yet so I can't help there, sorry.

L.

[Alvaro Gil]

Emanuele, hi, you said you noticed REMB packages sent out from Firefox, I thought it was only a google feature with goog-remb sdp declaration, it is not?

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/d7baa11b-735d-5b4d-64eb-de47dda4e308%40gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

Alvaro

[Emanuele Bizzarri]

Let me double check

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/CAGM%2B_3YiMywde0iZkk0F8WvT_BsDcVUQbszJaMu25Qdy0adNMA%40mail.gmail.com.

[Emanuele Bizzarri]

Hi Alvaro,
yes you are right.
the direction of REMB I saw are chrome > mcu > firefox.
I forgot that in my implementation I don't remove the local stream on firefox side, but only disable tracks (because I have some issue with planB 2 unifiedPlan compatibility and firefox removeStream API).
So firefox always has the localStream attached to peerConnection, also if media are disabled.
But also in this case I see that chrome send REMB only if it has a local stream added to the peerConnection.
Enabling the video for chrome, REMB arrives to mcu, but they are coming from chrome and are relative to the black/silent stream sent by firefox.

Following is the SDP on chrome side (sent by mcu to the browser).
My doubt is about "sendrecv", maybe I have to manage it dinamically. When the client doesn't have a local stream, the mcu should send "sendonly" instead of "sendrecv".
I will try.

Thank you

type: offer, sdp: v=0
o=- 1341807817 2 IN IP4 127.0.0.1
s=-
t=0 0
a=group:BUNDLE audio video
a=msid-semantic: WMS
m=audio 1 RTP/SAVPF 111 103 104 0 8 106 105 13 126
c=IN IP4 0.0.0.0
a=rtcp:9 IN IP4 0.0.0.0
a=ice-ufrag:3438303030
a=ice-pwd:BzY6obIb1DvgB3j92C62rl
a=fingerprint:sha-256 1A:D1:74:C2:6C:99:6C:0E:CD:27:34:75:4F:15:D7:72:EB:62:22:2F:2E:86:33:5C:10:37:74:85:8F:1E:36:29
a=setup:actpass
a=mid:audio
b=AS:16
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=extmap:3 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=sendrecv
a=rtcp-mux
a=rtpmap:111 opus/48000/2
a=fmtp:111 minptime=10
a=rtpmap:103 ISAC/16000
a=rtpmap:104 ISAC/32000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:106 CN/32000
a=rtpmap:105 CN/16000
a=rtpmap:13 CN/8000
a=rtpmap:126 telephone-event/8000
a=maxptime:60
a=ssrc:123456 cname:fake-unified-plan-cname-audio
a=ssrc:123456 msid:fake-unified-plan-stream fake-unified-plan-audio
a=ssrc:123456 mslabel:fake-unified-plan-stream
a=ssrc:123456 label:fake-unified-plan-audio
a=ssrc:812659729 cname:312e3126c454ba210511852b471690428af012f1-1206-audio-cname
a=ssrc:812659729 msid:312e3126c454ba210511852b471690428af012f1-1206 312e3126c454ba210511852b471690428af012f1-1206-audio
a=ssrc:812659729 mslabel:312e3126c454ba210511852b471690428af012f1-1206
a=ssrc:812659729 label:312e3126c454ba210511852b471690428af012f1-1206-audio
a=candidate:2 1 udp 65535 93.57.86.154 48000 typ host
a=candidate:1 1 udp 65525 10.0.0.166 48000 typ host
m=video 1 RTP/SAVPF 100
c=IN IP4 0.0.0.0
a=rtcp:9 IN IP4 0.0.0.0
a=ice-ufrag:3438303030
a=ice-pwd:BzY6obIb1DvgB3j92C62rl
a=fingerprint:sha-256 1A:D1:74:C2:6C:99:6C:0E:CD:27:34:75:4F:15:D7:72:EB:62:22:2F:2E:86:33:5C:10:37:74:85:8F:1E:36:29
a=setup:actpass
a=mid:video
b=AS:1024
a=extmap:2 urn:ietf:params:rtp-hdrext:toffset
a=extmap:3 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=sendrecv
a=rtcp-mux
a=rtpmap:100 VP8/90000
a=rtcp-fb:100 ccm fir
a=rtcp-fb:100 nack
a=rtcp-fb:100 nack pli
a=rtcp-fb:100 goog-remb
a=ssrc:654321 cname:fake-unified-plan-cname-video
a=ssrc:654321 msid:fake-unified-plan-stream fake-unified-plan-video
a=ssrc:654321 mslabel:fake-unified-plan-stream
a=ssrc:654321 label:fake-unified-plan-video
a=ssrc:2039876183 cname:312e3126c454ba210511852b471690428af012f1-1206-video-cname
a=ssrc:2039876183 msid:312e3126c454ba210511852b471690428af012f1-1206 312e3126c454ba210511852b471690428af012f1-1206-video
a=ssrc:2039876183 mslabel:312e3126c454ba210511852b471690428af012f1-1206
a=ssrc:2039876183 label:312e3126c454ba210511852b471690428af012f1-1206-video
a=candidate:2 1 udp 65535 93.57.86.154 48000 typ host
a=candidate:1 1 udp 65525 10.0.0.166 48000 typ host

On 03/06/2016 16:12, Alvaro Gil wrote:

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/CAGM%2B_3YiMywde0iZkk0F8WvT_BsDcVUQbszJaMu25Qdy0adNMA%40mail.gmail.com.