[Live-devel] Client issue with large IP packets during interrop tests

[DAVID SAHUC]

Agreed, in a general case, MTU is 1500; but for network owners (with control of routers), or for point to point applications, control/use of this parameter is flexible (helped sometimes by "path MTU discovery").


Sorry if I was not clear enough, I was not talking of the Sink but MultiFramedRTPSource.cpp's BufferedPacket: if you do not modify MAX_PACKET_SIZE, there is loss of data on the client side for packets sizes above the defined 10000 bytes "out of the box" (since we're just using it as is for interop tests). I guess that would also apply if one increase TRANSPORT_PACKETS_PER_NETWORK_PACKET above 53 in Live555 server(s) and use openRTSP as a client.

Since we're just in our case using Live555 for interop tests, one option live555 could also use to avoid having another server (than Live555's) sending too big IP packets is the RTSP "Blocksize" to restrict to its defined MAX_PACKET_SIZE: http://tools.ietf.org/html/rfc2326#page-47

David.


----- Original Message ----
From: Ross Finlayson <finlayson at live555.com>
To: LIVE555 Streaming Media - development & use <live-devel at ns.live555.com>
Sent: Mon, April 12, 2010 8:29:33 PM
Subject: Re: [Live-devel] Client issue with large IP packets during interrop tests

IP fragmentation is a very bad idea, and should be avoided.  (The reason for this is that if any IP fragment is lost, the whole IP packet will be discarded, even if the remaining fragments happened to contain useful data.)  Instead, RTP/UDP/IP packets should always be small enough to fit within a network's MTU (even if the theoretical maximum size of an IP packet is much larger).  For almost all networks, the MTU will be at least 1500 bytes, which is why we set the maximum RTP packet size - by default - to 1448 bytes.  Note the call to
    setPacketSizes(1000, 1448);
in "MultiFramedRTPSink.cpp".

If you want to increase this number (i.e., for a larger MTU), then you can do this by calling "setPacketSizes()" on your "MultiFramedRTPSink" (subclass) object.  Note that you *do not* need to modify the existing supplied source code to do this.

It is true, however, that we currently 'hardwire' a 7 Transport-Packets-per-RTP-packet limit when streaming Transport Stream data - i.e., the definition of "TRANSPORT_PACKETS_PER_NETWORK_PACKET" in "MPEG2TransportFileServerMediaSubsession.cpp".  This is one case where you would need to modify the supplied code if you wanted to change this.
-- 
Ross Finlayson
Live Networks, Inc.
http://www.live555.com/
_______________________________________________
live-devel mailing list
live-devel at lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel