Closed
Bug 1507413
Opened 5 years ago
Closed 5 years ago
Only 32 transceivers active simultaneously
Categories
(Core :: WebRTC: Signaling, defect, P2)
Tracking
()
RESOLVED
FIXED
mozilla65
Tracking | Status | |
---|---|---|
firefox65 | --- | fixed |
People
(Reporter: sergio.garcia.murillo, Assigned: dminor)
Details
Attachments
(1 file)
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.102 Safari/537.36 Steps to reproduce: I create 34 transceivers send only with tracks from canvas/audio context, negotiate SDP O/A with my server. Actual results: The first 32 transceivers work, the 33rd (mid=32) and 34 (mid=33) does't. The local description after the SDP O/A shows that only the first 32 are added to the bundle group (and have a non cero port) while the mid=32 and 33 are missing from the bundle group and the port is 0. There is no data sent in that transceivers. If I stop any of the transcivers (mid<31) and perform an SDP O/A then the next mid is added to the group. Note that the sdp created by the createOffer has all the mids in the bundle group and ports = 0, and after the SLD is where the mids are removed and the ports changed. Here is a sample (with dummy o/a so you don't have to rely on my server) to reproduce the issue. It creates all the transceivers and do the sdp o/a and prints the local description in html. https://murillo128.github.io/firefox-transceivers-issue-test/ Expected results: All 34 transceivers are enabled
Comment 1•5 years ago
|
||
Dan, this is the bug we briefly talked about. Could you please have a look if you have free cycles?
Assignee: nobody → dminor
Status: UNCONFIRMED → NEW
Ever confirmed: true
Priority: -- → P2
Comment 2•5 years ago
|
||
Hi Nils, Could you please also assign a component to this issue as you seem familiar with the subject? Thank you!
Flags: needinfo?(drno)
Assignee | ||
Updated•5 years ago
|
Rank: 15
Component: Untriaged → WebRTC: Signaling
Flags: needinfo?(drno)
Product: Firefox → Core
Assignee | ||
Comment 3•5 years ago
|
||
It turns out that there is a limit on the media streams allowed by the C sdp parser here [1] which is enforced while parsing attribute groups here [2] which prevents the last two transceivers from being added to the bundle group. Increasing that from 32 to say 64 allows for more transceivers. There also appears to be a limit on the maximum line length allowed by the sdp parser at [2] which will presumably also cause problems at some point. As far as I can tell, the rust sdp parser does not have any limit on the number of groups or a maximum line length. :bwc, do you see any harm in increasing the constants at [1] (and maybe [3])? Thanks! [1] https://searchfox.org/mozilla-central/rev/55895c49f55073d82d977cb74ec1d3a71ae4b25f/media/webrtc/signaling/src/sdp/sipcc/sdp.h#571 [2] https://searchfox.org/mozilla-central/rev/55895c49f55073d82d977cb74ec1d3a71ae4b25f/media/webrtc/signaling/src/sdp/sipcc/sdp_attr.c#3783 [3] https://searchfox.org/mozilla-central/rev/55895c49f55073d82d977cb74ec1d3a71ae4b25f/media/webrtc/signaling/src/sdp/sipcc/sdp.h#574
Flags: needinfo?(docfaraday)
Assignee | ||
Comment 5•5 years ago
|
||
This also removes SDP_MAX_LINE_LEN which is unused.
Pushed by dminor@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/240b08a258e9 Increase number of media streams supported by sipcc; r=bwc
Comment 7•5 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/240b08a258e9
Status: NEW → RESOLVED
Closed: 5 years ago
status-firefox65:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla65
You need to log in
before you can comment on or make changes to this bug.
Description
•