-
Notifications
You must be signed in to change notification settings - Fork 2.5k
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
[1.0.1] Multiple Janus side candidates when NAT 1-1 is being used #2997
Comments
There's no bug. You clearly have at least two interfaces active in Janus, each of them resulting in a different candidate (and so port), both of which Janus will put the nat-1-1 address you specified on, since it obviously doesn't know which one it should stick to unless you tell it. If you just want one, disable the other in |
I bag to differ, please read carefully the issues here. What is the configuration of janus.jcfg that will cause Janus-Gateway not to give 2 candidates in this case ? Cause this looks like a good way to overcome this problem. |
No, that only means that Janus will advertise a single address, but the actual addresses behind that are more than one. This is evident from the snippets you shared, where two different candidates have been gathered, one with address Again, if you just want one candidate, then you have to programmatically disable one of the two interfaces, which means you have to tell Janus if it only needs to gather addresses on the interface with address |
o.k., now I'm sure there is a real issue.
|
Will you PLEASE stop using this gigantic font to write your messages? I can't explain why it's not an issue better than I already did. If you don't want to make an effort to read and understand my explainations, then I'm afraid there's nothing more I have to add. |
What will happen is that ICE protocol should do its job, that is finding working candidate pairs, either notified or discovered.
I strongly disagree, the reason for most ICE failures is the misconfiguration of network in WebRTC deployments (setting up firewalls, available ports, TURN server in clients etc.).
I don't understand what you mean by "mapping interfaces by ports". As Lorenzo explained, setting NAT-1-1 will just overwrite the address of any gathered local candidate with the one specified in the NAT-1-1. |
You miss my meaning, media servers don't need different ports for different candidates. This is not a requirement of the ICE. In the logs we can clearly see that each of the candidate is assigned, by Janus-Gateway with different port. Now, the question is what does Janus do with it : Maybe what is missing here in the support for all ICE plan, but it seems like something is wrong. |
We're done here. |
The phenomenon we get is the we receive multiple candidates from Janus due to some reason, no idea what ahs changed, when we use the NAT 1-1 settings.
To my understanding this is a BUG as NAT 1-1 means Janus "knows" the public endpoint, an certainly there is no reason whatsoever to give 2 candidates which are the very same ones, with 2 different ports. This can also cause issues as the range of ports can be exhausted fast in that way (for 1 subscriber and 1 publisher we will get 4 ports being used for connectivity check). It also doesn't make much sense, as the assumption is that all the port range is opened in the same way.
I've marked the issue
[218008902809326] There are 0 audio, 1 video and 0 data m-lines
[218008902809326] We have 2 candidates for Stream #1, Component #1
[218008902809326] Public IP specified and 1:1 NAT mapping enabled (198.208.11.78), using that as host address in the candidates
[218008902809326] Address: 10.126.180.30:33045
[218008902809326] Priority: 2015363327
[218008902809326] Foundation: 1
[218008902809326] 1 1 udp 2015363327 198.208.11.78 33045 typ host
[218008902809326] Public IP specified and 1:1 NAT mapping enabled (198.208.11.78), using that as host address in the candidates
[218008902809326] Address: 10.173.0.1:34176
[218008902809326] Priority: 2015363583
[218008902809326] Foundation: 2
[218008902809326] 2 1 udp 2015363583 198.208.11.78 34176 typ host
v=0
o=- 4803130522175137613 1654756009 IN IP4 198.208.11.78
s=VideoRoom 6
t=0 0
a=group:BUNDLE 0
a=ice-options:trickle
a=fingerprint:sha-256 A2:7A:01:A8:D1:6D:73:98:85:5C:DC:00:B5:AD:09:37:2E:47:53:ED:B7:DC:4D:59:66:F8:70:99:4E:EB:46:EC
a=extmap-allow-mixed
a=msid-semantic: WMS janus
m=video 9 UDP/TLS/RTP/SAVPF 102 121
c=IN IP4 198.208.11.78
a=recvonly
a=mid:0
a=rtcp-mux
a=ice-ufrag:0/tg
a=ice-pwd:4wqyZGCB+qBw9zQmqo8vVe
a=ice-options:trickle
a=setup:active
a=rtpmap:102 H264/90000
a=rtcp-fb:102 ccm fir
a=rtcp-fb:102 nack
a=rtcp-fb:102 nack pli
a=rtcp-fb:102 goog-remb
a=rtcp-fb:102 transport-cc
a=fmtp:102 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42001f
a=extmap:1 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01
a=rtpmap:121 rtx/90000
a=fmtp:121 apt=102
a=msid:janus janus0
a=ssrc:1746293785 cname:janus
a=ssrc:0 cname:janus
a=candidate:1 1 udp 2015363327 198.208.11.78 33045 typ host
a=candidate:2 1 udp 2015363583 198.208.11.78 34176 typ host
a=end-of-candidates
Ad you can see in the pasted text from Janus log.
I can supply the full log, of course.
The text was updated successfully, but these errors were encountered: