Closed Bug 1507413 Opened 5 years ago Closed 5 years ago

Only 32 transceivers active simultaneously

Categories

(Core :: WebRTC: Signaling, defect, P2)

63 Branch
defect

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
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
Hi Nils,

Could you please also assign a component to this issue as you seem familiar with the subject? Thank you!
Flags: needinfo?(drno)
Rank: 15
Component: Untriaged → WebRTC: Signaling
Flags: needinfo?(drno)
Product: Firefox → Core
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)
I think that would be fine.
Flags: needinfo?(docfaraday)
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
https://hg.mozilla.org/mozilla-central/rev/240b08a258e9
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla65
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: