github-actions[bot]
commented
4 years ago Hello @space88man :wave: this issue is being automatically closed because it does not follow the issue template.
Open space88man opened 4 years ago
github-actions[bot]
commented
4 years ago Hello @space88man :wave: this issue is being automatically closed because it does not follow the issue template.
j1elo
commented
4 years ago Reopening; I think the template check action might be a bit overzealous here... will review that.
space88man
commented
4 years ago Can definitely see KMS consuming both sets of ICE attributes. This SDP has per-media ICE attributes. It seems that the second set overwrites the first set, no?
From m=audio
kmswebrtcsession.c:1012 gst_media_add_remote_candidates() Set remote media credentials OK (c3yo, v0tRtWuXvE0PeFjoq4VIcm).
From m=video
kmswebrtcsession.c:1012 gst_media_add_remote_candidates() Set remote media credentials OK (4zTf, 4P9K6pHpq6ugzUj8TwBAxX).Then we go into ICE checks and always the check for index=0 will fail as KMS uses index=1 credentials during the ICE exchange.
If I mangle the SDP so that both sets of ICE attributes are the same, then aiortc <--> KMS will work.
Is this enough information? If not, I will try to hack a script and my current setup is baroque..
space88man
commented
4 years ago This SDP will cause ICE to fail:
2020-05-29T22:31:19,858073 13995 0x00007f77a2b43700 info kmssdpsession kmssdpsession.c:95 kms_sdp_session_process_offer() <kmswebrtcsession5> Process SDP Offer:
v=0
o=- 3799751471 3799751471 IN IP4 0.0.0.0
s=-
t=0 0
a=group:BUNDLE 0 1
a=msid-semantic:WMS *
m=audio 44516 UDP/TLS/RTP/SAVPF 96 0 8
c=IN IP4 192.168.1.7
a=sendrecv
a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid
a=mid:0
a=msid:6b81ccd4-d3ee-4234-b25f-09678c972c6a 467e5788-92df-40fb-b5de-d5ea1707ff86
a=rtcp:9 IN IP4 0.0.0.0
a=rtcp-mux
a=ssrc:2668033814 cname:a92996e8-f7b7-474e-82e2-53013818d7b9
a=rtpmap:96 opus/48000/2
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=candidate:d3528481068ed87c99af586f1926906f 1 udp 2130706431 192.168.1.7 44516 typ host
a=candidate:11b689b4112f791f3859a4d254e61e25 1 udp 2130706431 192.168.125.1 47128 typ host
a=candidate:4928f5caa10844d454e97e1af3038bee 1 udp 2130706431 192.168.122.1 58246 typ host
a=candidate:653e4b9fd74e9451ff76d5b7d540707e 1 udp 2130706431 192.168.81.5 37729 typ host
a=end-of-candidates
a=ice-ufrag:c3yo
a=ice-pwd:v0tRtWuXvE0PeFjoq4VIcm
a=fingerprint:sha-256 61:8C:48:42:DD:08:41:10:30:A1:39:18:01:34:0C:68:50:35:B6:68:D9:51:F7:29:0C:30:87:64:3C:03:5B:4B
a=setup:actpass
m=video 51197 UDP/TLS/RTP/SAVPF 97 98 99 100 101 102
c=IN IP4 192.168.1.7
a=sendrecv
a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid
a=extmap:2 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=mid:1
a=msid:6b81ccd4-d3ee-4234-b25f-09678c972c6a 12ae90c7-d63b-468d-80f6-0e6c44ccaf3b
a=rtcp:9 IN IP4 0.0.0.0
a=rtcp-mux
a=ssrc-group:FID 2826579273 442286629
a=ssrc:2826579273 cname:a92996e8-f7b7-474e-82e2-53013818d7b9
a=ssrc:442286629 cname:a92996e8-f7b7-474e-82e2-53013818d7b9
a=rtpmap:97 VP8/90000
a=rtcp-fb:97 nack
a=rtcp-fb:97 nack pli
a=rtcp-fb:97 goog-remb
a=rtpmap:98 rtx/90000
a=fmtp:98 apt=97
a=rtpmap:99 H264/90000
a=rtcp-fb:99 nack
a=rtcp-fb:99 nack pli
a=rtcp-fb:99 goog-remb
a=fmtp:99 packetization-mode=1;level-asymmetry-allowed=1;profile-level-id=42001f
a=rtpmap:100 rtx/90000
a=fmtp:100 apt=99
a=rtpmap:101 H264/90000
a=rtcp-fb:101 nack
a=rtcp-fb:101 nack pli
a=rtcp-fb:101 goog-remb
a=fmtp:101 packetization-mode=1;level-asymmetry-allowed=1;profile-level-id=42e01f
a=rtpmap:102 rtx/90000
a=fmtp:102 apt=101
a=candidate:d3528481068ed87c99af586f1926906f 1 udp 2130706431 192.168.1.7 51197 typ host
a=candidate:11b689b4112f791f3859a4d254e61e25 1 udp 2130706431 192.168.125.1 42196 typ host
a=candidate:4928f5caa10844d454e97e1af3038bee 1 udp 2130706431 192.168.122.1 43481 typ host
a=candidate:653e4b9fd74e9451ff76d5b7d540707e 1 udp 2130706431 192.168.81.5 43135 typ host
a=end-of-candidates
a=ice-ufrag:4zTf
a=ice-pwd:4P9K6pHpq6ugzUj8TwBAxX
a=fingerprint:sha-256 61:8C:48:42:DD:08:41:10:30:A1:39:18:01:34:0C:68:50:35:B6:68:D9:51:F7:29:0C:30:87:64:3C:03:5B:4B
a=setup:actpass
Issue description
aiortc is the WebRTC peer; when it sends SDP with per-media ice-ufrag/ice-pwd (i.e., m=audio, m=video have different ICE attributes) KMS will use the second pair (i.e. from m=video) to do ICE checks for m=audio.
Reference: https://github.com/aiortc/aiortc/issues/370
aiortc states that KMS is in error as it should handle per-media ICE-attributes.
Context
aiortc --- openvidu for signalling aiortc --- KMS for RTP
How to reproduce?
For example:
Send this type of SDP to KMS (excerpted):
Expected & current behavior
Expected: ICE converges.
Current : The error is KMS -> aiortc ICE REQUEST fails as it uses the second set of ICE attributes when doing ICE checks for m=audio. When I dump the STUN packets, I see the KMS is using m=video ICE attributes for m=audio ICE candidates.
(Optional) Possible solution
Does KMS not handle per-media ICE attributes?
INFO about Kurento Media Server
INFO about your Application Server
INFO about end-user clients