New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 8 users
Status: Available
Owner: ----
Cc:
Components:
NextAction: ----
OS: ----
Pri: 3
Type: Bug



Sign in to add a comment
Browser sending RR when there is no audio
Reported by jpu...@tokbox.com, Sep 30 2014 Back to list
What steps will reproduce the problem?
1. Create a peer connection using "audio: false" as constraints in getUserMedia
2. The other entity is an MCU that is only receiving the media (recvonly) and it is sending no RTCP traffic back to the browser.

What is the expected result?
The browser should not send any RR

What do you see instead?
The browser is sending a RR with no report blocks (RC = 0) and SSRC (length field = 1) around every 5 seconds.

What version of the product are you using? On what operating system?
Chrome 37.0.2062120 (64 bit) on Ubuntu 14.04

Please provide any additional information below.
This happens only if the media has no audio track. If I call getUserMedia enabling the audio, no RR are sent

This is the SDP sent from the browser to the MCU:
type: offer, sdp: v=0
o=- 7502352074017402667 2 IN IP4 127.0.0.1
s=-
t=0 0
a=group:BUNDLE audio video
a=msid-semantic: WMS J3gHJ46TQ98ZmBAwOZhb0fi3rioT8Bx827U5
m=audio 1 RTP/SAVPF 111 103 104 0 8 106 105 13 126
c=IN IP4 0.0.0.0
a=rtcp:1 IN IP4 0.0.0.0
a=ice-ufrag:IG/QuwsLs67nyKtc
a=ice-pwd:eXOwa+kCxGwBlJUxxZQ+1H43
a=ice-options:google-ice
a=mid:audio
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=recvonly
a=rtcp-mux
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:3V31VKA3CRoIyQcY8AO19lYkTFM6HrTIwS8cLaC1
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
m=video 1 RTP/SAVPF 100 116 117 96
c=IN IP4 0.0.0.0
a=rtcp:1 IN IP4 0.0.0.0
a=ice-ufrag:IG/QuwsLs67nyKtc
a=ice-pwd:eXOwa+kCxGwBlJUxxZQ+1H43
a=ice-options:google-ice
a=mid:video
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=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:3V31VKA3CRoIyQcY8AO19lYkTFM6HrTIwS8cLaC1
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=rtpmap:116 red/90000
a=rtpmap:117 ulpfec/90000
a=rtpmap:96 rtx/90000
a=fmtp:96 apt=100
a=ssrc-group:FID 1609808400 515740625
a=ssrc:1609808400 cname:mF4Yh/nlfwYtoa5q
a=ssrc:1609808400 msid:J3gHJ46TQ98ZmBAwOZhb0fi3rioT8Bx827U5 abc87c49-0d57-42de-84f8-c775bfc773f1
a=ssrc:1609808400 mslabel:J3gHJ46TQ98ZmBAwOZhb0fi3rioT8Bx827U5
a=ssrc:1609808400 label:abc87c49-0d57-42de-84f8-c775bfc773f1
a=ssrc:515740625 cname:mF4Yh/nlfwYtoa5q
a=ssrc:515740625 msid:J3gHJ46TQ98ZmBAwOZhb0fi3rioT8Bx827U5 abc87c49-0d57-42de-84f8-c775bfc773f1
a=ssrc:515740625 mslabel:J3gHJ46TQ98ZmBAwOZhb0fi3rioT8Bx827U5
a=ssrc:515740625 label:abc87c49-0d57-42de-84f8-c775bfc773f1

This is the answer from the MCU to the browser:
type: answer, sdp: v=0
o=- 2406547980 1616806932 IN IP4 127.0.0.1
s=-
c=IN IP4 127.0.0.1
t=0 0
a=group:BUNDLE audio video
m=audio 43116 RTP/SAVPF 111 0 8 106 105 13 126
c=IN IP4 127.0.0.1
a=rtpmap:111 opus/48000/2
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=rtcp:43116
a=inactive
a=ice-ufrag:wv9kLGVAFxJJPWlo
a=ice-pwd:PsHpQK1b5i41IKoA+A8uxr
a=candidate:1796272311 1 UDP 2130706431 127.0.0.1 43116 typ host generation 0
a=candidate:1796272311 2 UDP 2130706430 127.0.0.1 43116 typ host generation 0
a=mid:audio
a=rtcp-mux
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=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:DAGCGQdcIpcaFDX+iYSqjz/XLg+1+d3HvlB2ABHQ
m=video 43116 RTP/SAVPF 100 116 117
c=IN IP4 127.0.0.1
a=rtpmap:100 VP8/90000
a=rtpmap:116 red/90000
a=rtpmap:117 ulpfec/90000
a=rtcp:43116
a=recvonly
a=ice-ufrag:wv9kLGVAFxJJPWlo
a=ice-pwd:PsHpQK1b5i41IKoA+A8uxr
a=candidate:1796272311 1 UDP 2130706431 127.0.0.1 43116 typ host generation 0
a=candidate:1796272311 2 UDP 2130706430 127.0.0.1 43116 typ host generation 0
a=mid:video
a=rtcp-mux
a=extmap:2 urn:ietf:params:rtp-hdrext:toffset
a=extmap:3 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=rtcp-fb:100 ccm fir
a=rtcp-fb:100 nack 
a=rtcp-fb:100 nack pli
a=rtcp-fb:100 goog-remb
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:ZwZnm+z7wznKCz0de2oibKv5ldx1I4/xYHhtHCnz


 
Comment 1 by jpu...@tokbox.com, Oct 1 2014
Some additional information: the SSRC in the RR sent by the browser in the given setup is different than the RTP packets or the SR, as opposed to the case where a BYE packet is sent in a compound packet [RR, SDES, BYE], where the SSRC is the same as the one in the RTP packets.
Project Member Comment 2 by braveyao@webrtc.org, Oct 3 2014
Owner: braveyao@webrtc.org
Yes this should be as expected. Since you set recvonly at chrome side, then we would start sending RR report. And there is no stream from MCU, so the SSRC inside RR is unavailable.
I suppose you could try to remove audio section from chrome SDP(or set it to inactive), then there would be no more RR.
Comment 3 by jpu...@tokbox.com, Oct 3 2014
I see what you say. One point here: since the answer from the MCU to the browser for the audio is "a=inactive", shouldn't it make the audio track in the browser side to have no RTCP traffic?
Project Member Comment 4 by braveyao@webrtc.org, Oct 6 2014
Cc: braveyao@webrtc.org juberti@webrtc.org
Owner: stefan@webrtc.org
@stefan, now as long as a voe channel is created, RtpRtcpModule would start to send RR, no matter if receiving is started on that channel or not. What's the point of such a implementation? Please help to comment!
Project Member Comment 5 by stefan@webrtc.org, Oct 6 2014
I think the right behavior would be to send RR whenever packets have been received. In this case no packets have been received, and therefore no RR should be sent.
Project Member Comment 6 by braveyao@webrtc.org, Oct 6 2014
Status: Available
Thanks for the comments!
Comment 7 by jpu...@tokbox.com, Oct 6 2014
Thanks for information!
Project Member Comment 8 by stefan@webrtc.org, Oct 13 2014
Owner: braveyao@webrtc.org
Project Member Comment 9 by braveyao@webrtc.org, Oct 14 2014
Cc: -braveyao@webrtc.org stefan@webrtc.org
@stefan, according to your comment#5, I suppose there should be coding job in RtpRtcp module. Is that right? Please help to suggest!
Comment 10 by juberti@google.com, Oct 14 2014
FWIW, a=recvonly or a=inactive only stops RTP, not RTCP. Therefore sending RR/SR, while perhaps not very useful, is still permitted.

Does this actually cause a problem?
Project Member Comment 11 by stefan@webrtc.org, Oct 14 2014
If we decide to change this behavior, I would start by looking in the RTP module, yes. I can't point out the exact places to change though.
Comment 12 by vrk@webrtc.org, Oct 14 2014
Labels: Area-Network
Project Member Comment 13 by braveyao@webrtc.org, Oct 17 2014
Who is best to make such a decision?
I prefer the behavior in comment #5. Maybe I could help on a solution?
Comment 14 by vrk@webrtc.org, Oct 28 2014
Cc: braveyao@webrtc.org
Labels: -Area-Network Area-Audio
Owner: ----
Project Member Comment 15 by tina.legrand@webrtc.org, Dec 3 2014
Labels: -Area-Audio Area-PeerConnection
Project Member Comment 16 by pthatcher@webrtc.org, Dec 11 2014
Labels: EngTriaged IceBox
Project Member Comment 17 by pthatcher@webrtc.org, Nov 8 2016
Labels: Pri-3
Sign in to add a comment