Should we open a gst ticket about changing this default then?

Generally for RTP the default of 1400 is fine and more optimal, especially if you just transmit it over Ethernet. Changing this default now would potentially cause problems for applications that assume this default.

It would make sense to change this to 1200 in webrtcbin but unfortunately it requires the payloaders outside itself so it doesn't really have control over the MTU. Changing all the webrtcbin examples would be a good idea though.

Interesting, what is the reason btw? Do VPNs add "wrapper" data around packets? If so, how do we know 1200 is safer? Also, what do you mean by "won't work"? Shouldn't packets be fragmented and reassembled eventually?

I'm completely OK with the patch by the way, just curious :)

You don't get the packets on the receiving side, in chromium it just does't show anything, with webrtcsrc I can see nooo RTP packets ever arrive. I am not sure why but I read a few places this is expected. 1200 is the commonly accepted value. I didn't find very good information about it but you can read https://stackoverflow.com/questions/47635545/why-webrtc-chose-rtp-max-packet-size-to-1200-bytes for example or https://groups.google.com/g/discuss-webrtc/c/gH5ysR3SoZI

While fragmentation works on the IP level, it rarely works over the internet with UDP. And even if it did work, splitting each 1400 byte packet into 1200 and 200 bytes is going to be less efficient than doing this at the payloader level.

Thanks for the links / info :) Merging