Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RFC8843 : Accept offer with a=group:BUNDLE line even if it has conflicting ice-ufrag values #2621

Closed
Odinvt opened this issue Nov 20, 2023 · 5 comments · Fixed by #2950
Closed
Labels
bug Something isn't working difficulty:moderate

Comments

@Odinvt
Copy link

Odinvt commented Nov 20, 2023

Your environment.

  • Pion Version: v3.2.14
  • PBX: Asterisk v18 (WebRTC mode)

What did you do?

Pion receives an SDP as offer which is then provided to SetRemoteDescription :

v=0
o=- 852496663 852496663 IN IP4 ...........
s=Asterisk
c=IN IP4 ................
t=0 0
a=group:BUNDLE audio-0 video-1 video-2
m=audio 11514 UDP/TLS/RTP/SAVPF 107 101
a=connection:new
a=setup:actpass
a=fingerprint:SHA-256 3E:E0:8A:06:36:56:73:9E:72:08:61:5D:13:38:C0:42:9A:25:3E:34:E7:03:7F:6E:F5:9F:B9:2C:7D:C7:02:C5
a=ice-ufrag:6992ba23181e294c0bd380af7ac57964
a=ice-pwd:7d1090fb4b82e27374cf42b8363b631d
a=candidate:H9387b5c9 1 UDP 2130706431 .............. 11514 typ host
a=candidate:Hd30485b5 1 UDP 2130706431 .............. 11514 typ host
a=rtpmap:107 opus/48000/2
a=fmtp:107 useinbandfec=1
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=maxptime:20
a=sendrecv
a=rtcp-mux
a=ssrc:2081773396 cname:43c36c43-de21-4f8b-8ab7-4580bac88350
a=mid:audio-0
m=video 16464 UDP/TLS/RTP/SAVPF 100
a=connection:new
a=setup:actpass
a=fingerprint:SHA-256 43:DC:6D:4D:8B:7E:FE:47:3C:F3:18:6B:B7:D8:B0:0A:1F:20:55:18:60:AF:2F:46:E9:1F:A6:FE:F5:E0:22:4B
a=ice-ufrag:287c549566e5ca694b2aaf053d484b35
a=ice-pwd:548946fd5d6c7cb068bbcfb656593bb8
a=candidate:H9387b5c9 1 UDP 2130706431 ................... 16464 typ host
a=candidate:Hd30485b5 1 UDP 2130706431 ................... 16464 typ host
a=rtpmap:100 VP8/90000
a=sendrecv
a=rtcp-mux
a=ssrc:181453472 cname:efb36874-07c8-46aa-93cf-82f2237ae446
a=mid:video-1
m=video 16690 UDP/TLS/RTP/SAVPF 100
a=connection:new
a=setup:actpass
a=fingerprint:SHA-256 6D:37:49:4E:43:C8:D0:1F:49:50:17:36:F6:1B:2D:62:2F:CC:6F:51:B3:8F:D3:28:AF:02:37:0D:08:EA:83:53
a=ice-ufrag:194467e75266fb7d26b5d08f2521c42c
a=ice-pwd:037f3c931c992e497733cb7401d07efe
a=candidate:H9387b5c9 1 UDP 2130706431 ......................... 16690 typ host
a=candidate:Hd30485b5 1 UDP 2130706431 ......................... 16690 typ host
a=rtpmap:100 VP8/90000
a=recvonly
a=rtcp-mux
a=ssrc:27453603 cname:69161142-12b4-4468-b0d2-51c7229292e2
a=mid:video-2

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:BUNDLE line. 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

@Odinvt
Copy link
Author

Odinvt commented Nov 21, 2023

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.

@Sean-Der Sean-Der added bug Something isn't working difficulty:moderate labels Apr 1, 2024
Sean-Der pushed a commit that referenced this issue Apr 8, 2024
Sean-Der pushed a commit that referenced this issue Apr 9, 2024
@diegomoreira001
Copy link

Hey guys! Any chance this may be reviewed and merged on to v3 any time soon?
@Sean-Der

We've implemented an SFU fully based on pion and this has became a blocker

@hernanliendo
Copy link

+1 Please merge

@stephanrotolante
Copy link
Contributor

@Odinvt @diegomoreira001 @hernanliendo

Anyway you can help me verify this change resolves your issue? I tested this with the SDP description provided in the example and it seems to be working

@nils-ohlmeier
Copy link

Hopefully #2950 will fix this soon.

Sean-Der pushed a commit to nils-ohlmeier/pion_webrtc that referenced this issue Nov 14, 2024
The way currently DTLS fingerprints and ICE credentials
are picked is causing interop issues as described in pion#2621

Peers which don't use Bundle can use different fingerprints
and credentials in each media section. Even though is
not (yet) supported by Pion, receiving an SDP offer from
such a peer is valid.

Additionally if Bundle is being used the group attribute
determines which media section is the master bundle section,
which establishes the transport. Currently Pion always
just uses the first credentials/fingerprint it can find
in the SDP, which results in not spec compliant behavior.

This PR attempts to fix the above issues and make
Pion more spec compliant and interoperable.

Fixes pion#2621
Sean-Der pushed a commit to nils-ohlmeier/pion_webrtc that referenced this issue Nov 14, 2024
The way currently DTLS fingerprints and ICE credentials
are picked is causing interop issues as described in pion#2621

Peers which don't use Bundle can use different fingerprints
and credentials in each media section. Even though is
not (yet) supported by Pion, receiving an SDP offer from
such a peer is valid.

Additionally if Bundle is being used the group attribute
determines which media section is the master bundle section,
which establishes the transport. Currently Pion always
just uses the first credentials/fingerprint it can find
in the SDP, which results in not spec compliant behavior.

This PR attempts to fix the above issues and make
Pion more spec compliant and interoperable.

Fixes pion#2621
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working difficulty:moderate
6 participants