Odinvt
commented
7 months ago For anyone interested in a workaround for this for the moment :
If you're sure the originator of the offer supports Bundling and an attribute a=group:BUNDLE is included in the offer, you just need to hack the SDP using pion/sdp package for Pion to accept it. Mainly :
1/ Copy the same values of ice-ufrag, ice-pwd and fingerprint from the first media description to all the others
2/ Set each media description's port to the port of the first media description (MediaDescriptions[i].MediaName.Port = MediaDescriptions[0].MediaName.Port)
3/ Replace all media description's candidates with the candidate list from the first media description
4/ Generate the answer
if you need proper ice-lite functionality in the answer, setting it to true in the Settings Engine is not enough. You need to also hack the resulting answer to :
1/ Include your IP in Origin and all the ConnectionInformation lines.
2/ Wait for the host candidate you're interested in from Pion.
3/ Plug that same candidate in all the Media Descriptions
4/ Take that candidate's port and Set each media description's port to that port (mediaDesc.MediaName.Port = sdp.RangedPort{Value: int(candidate.Port)})
And you're set ! Your peer connection should be connected and ice connectivity should be properly established as mine did.
diegomoreira001
hernanliendo
Your environment.
What did you do?
Pion receives an SDP as offer which is then provided to SetRemoteDescription :
What did you expect?
I expect Pion to follow the RFC8843 and accept that offer even if it has conflicting ice-ufrag values because it has the
a=group:BUNDLEline. Then choose which stream's transport it wants to use (typically the first one but the RFC allows to choose any one). And respond with an answer with bundling enabled for the chosen transport.What happened?
Error : SetRemoteDescription called with multiple conflicting ice-ufrag values