Using Kurento server for WebRTC without ICE
168 views
Skip to first unread message
Bill Rogers
Jun 1, 2022, 6:34:55 AM6/1/22
to kurento
The Kurento documentation section on NAT traversal
includes discussion of RTC connection without ICE.
I have been trying to adapt the Hello World Kurento Example
to use this capability, but so far without success. Does
anyone know of a Kurento example which demonstrates this feature?
Bill
Juan Navarro
Jun 2, 2022, 6:28:56 AM6/2/22
to kur...@googlegroups.com
I just checked and what happens is that this got implemented just
for RTP connections (i.e. the RtpEndpoint). WebRTC still needs to do
all the STUN and/or TURN dance, for ICE.
Alternatively, you can install Kurento on a cloud instance, open up the ports in the security group or firewall, and configure in WebRtcEndpoint.conf.ini the externalIPv4 parameter. This way the Kurento server itself won't need to use a STUN or TURN server. Note however, you'll still need a STUN or TURN server for all the clients (web browsers or mobile apps) that connect to it, if they are behind a NAT firewall (like 99.99% are, with domestic routers)
Regards
Alternatively, you can install Kurento on a cloud instance, open up the ports in the security group or firewall, and configure in WebRtcEndpoint.conf.ini the externalIPv4 parameter. This way the Kurento server itself won't need to use a STUN or TURN server. Note however, you'll still need a STUN or TURN server for all the clients (web browsers or mobile apps) that connect to it, if they are behind a NAT firewall (like 99.99% are, with domestic routers)
Regards
--
You received this message because you are subscribed to the Google Groups "kurento" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kurento+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kurento/aa67042a-44c3-472b-8471-f884efa8f259n%40googlegroups.com.
Bill Rogers
Jun 2, 2022, 6:55:57 AM6/2/22
to kurento
Hi Juan,
Many thanks for the helpful response. It is disappointing that I can't avoid ICE in the client. I have been dealing with multiple streams/tracks and the ICE process gets repeated for each, giving long connection times. I hadn't really appreciated that these were distinct RTC and WebRTC end points. You say that ICE free connection was only implemented for RTC. Does this mean that it might be possible to implement it for WebRTC? If so, I might be interested in working on the implementation.
Cheers
Bill
Juan Navarro
Jun 2, 2022, 10:07:51 AM6/2/22
to kur...@googlegroups.com
Hi,
the "COMEDIA" mode was added for plain RTP, there is no such thing as standalone "RTC". I guess the implementation could be promoted from the final class (RtpEndpoint) to the common ancestor in the inheritance tree, BaseRtpEndpoint, from which both RtpEndpoint and WebRtcEndpoint derive.
However, in any case, I doubt this would work at all. Every WebRTC client out there will expect to use ICE for WebRTC, and this mean exchanging ICE candidates with the media server. Other WebRTC media servers do similar to Kurento, and implement COMEDIA for plain RTP (such as mediasoup), but it just doesn't make sense for WebRTC.
Anyway, unless you are dealing with clients that are able to have a direct connection with the internet (no intermediary hardware), you would need ICE anyways. And I cannot think of what type of clients would these be. Every home or office connection will be placed behind a router or firewall. Most if not all mobile phone devices are behind a CGNAT. It's just not common being able to connect directly to the internet.
Regarding the ICE process for each track: most client use the BUNDLE mechanism by default, which transmits both video and audio over the same UDP ports, thus requiring only one single ICE process instead of how it traditionally was done, once for each media type. I'm afraid that's the extent of the optimizations done in WebRTC; you still need to allocate a send-recv UDP port for every stream, but that's normal because at the architecture level, every participant's media is basically its own independent and isolated flow of data.
If top speed is a priority for you, and you don't need all the media processing and recording abilities that Kurento provides, you might be interested in mediasoup. It is a very low-level, lightweight media server, which does just the minimum required to route media between participants, and the benefits of that is that everything is much much faster than with Kurento...
On the other hand, have a look at the pre-release builds of the upcoming Kurento 6.18. We had a contribution that speeded up quite a bit the connection establishment time:
https://doc-kurento.readthedocs.io/en/latest/project/relnotes/v6_18_0.html#webrtc-dtls-quick-connection
Regards
the "COMEDIA" mode was added for plain RTP, there is no such thing as standalone "RTC". I guess the implementation could be promoted from the final class (RtpEndpoint) to the common ancestor in the inheritance tree, BaseRtpEndpoint, from which both RtpEndpoint and WebRtcEndpoint derive.
However, in any case, I doubt this would work at all. Every WebRTC client out there will expect to use ICE for WebRTC, and this mean exchanging ICE candidates with the media server. Other WebRTC media servers do similar to Kurento, and implement COMEDIA for plain RTP (such as mediasoup), but it just doesn't make sense for WebRTC.
Anyway, unless you are dealing with clients that are able to have a direct connection with the internet (no intermediary hardware), you would need ICE anyways. And I cannot think of what type of clients would these be. Every home or office connection will be placed behind a router or firewall. Most if not all mobile phone devices are behind a CGNAT. It's just not common being able to connect directly to the internet.
Regarding the ICE process for each track: most client use the BUNDLE mechanism by default, which transmits both video and audio over the same UDP ports, thus requiring only one single ICE process instead of how it traditionally was done, once for each media type. I'm afraid that's the extent of the optimizations done in WebRTC; you still need to allocate a send-recv UDP port for every stream, but that's normal because at the architecture level, every participant's media is basically its own independent and isolated flow of data.
If top speed is a priority for you, and you don't need all the media processing and recording abilities that Kurento provides, you might be interested in mediasoup. It is a very low-level, lightweight media server, which does just the minimum required to route media between participants, and the benefits of that is that everything is much much faster than with Kurento...
On the other hand, have a look at the pre-release builds of the upcoming Kurento 6.18. We had a contribution that speeded up quite a bit the connection establishment time:
https://doc-kurento.readthedocs.io/en/latest/project/relnotes/v6_18_0.html#webrtc-dtls-quick-connection
Regards
To view this discussion on the web visit https://groups.google.com/d/msgid/kurento/20949750-ab41-4ad4-a6be-b2d7d2e29036n%40googlegroups.com.
Bill Rogers
Jun 2, 2022, 12:10:56 PM6/2/22
to kurento
Hi Juan,
Many thanks for your explanation. I'll look into the alternatives you suggest.
Cheers
Bill
Reply all
Reply to author
Forward
0 new messages