You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Calculate the maximum MTU size that can travel the entire path machine1<->machine2.
The easiest way is probably to craft heartbeat messages starting at the maximum value until they are successfully returned. Potentially listen to ICMP PacketTooBig
The text was updated successfully, but these errors were encountered:
SCTP RFC actually mentions RFC4821 which recommends using the heartbeat. It is an interesting approach. The current implementation does not fully support heartbeat. In WebRTC context, we have heartbeat at ICE layer, and I am not sure how critical it is not having heartbeat at SCTP layer..
I think we need to investigate how other WebRTC libraries deal with path MTU discovery.
I think we need to investigate how other WebRTC libraries deal with path MTU discovery.
AFAIK libwebrtc actually has the PMTU hard coded to a safe low value (I would have to lookup the exact value).
And yes the two options are either on the SCTP or the ICE level.
The ICE PMTU would have the advantage that the same information could get passed to the RTP stack as well.
But the problem is that for ICE there was only a draft for figuring out the PMTU, never an RFC. And AFAIK there is no other implementation which supports the ICE way.
The SCTP approach is way more interoperable.
Calculate the maximum MTU size that can travel the entire path machine1<->machine2.
The easiest way is probably to craft heartbeat messages starting at the maximum value until they are successfully returned. Potentially listen to ICMP PacketTooBig
The text was updated successfully, but these errors were encountered: