- This topic has 0 replies, 1 voice, and was last updated 16 years, 3 months ago by Alex McGregor.
26th January 2005 at 09:36 #28797Alex McGregorGuest
Not strictly VoIP, but I would imagine similar factors apply:
I work in IT support for a college that uses VBrick(www.vbrick.com) MPEG-2 video codecs to stream real-time video and audio between remote sites. Our local interface is 100MBit switched ethernet, and we have an ethernet WAN link limited to 34MBit between sites. The broadcasting site has 150 VoIP telephones adding to the data traffic.
We have had consistent problens with reception at the remote site of the streamed video – huge delay, dropped frames, MPEG artefacts etc, which are not exhibited if monitored on the LAN – only after transmission.
A network consultant used a packet sniffer and identified lots of fragmented packets across the WAN originating from our encoding VBrick. He suggested we may like to look at the configured MTU or frame size. This turned out to be a little over 4000 bytes, which he suggested was an appropriate rame size for ATM rather than Ethernet, which should have a max frame size of 1500 bytes.
We changed the MTU value as advised which appears to have fixed the problem.
However the installers of our AV system maintain that 4000 is the appropriate size, that this is what they use at other sites, and that our ‘fix’ may just be masking the real problem. My IT manager also would like to understand more about the technicalities of the situation and so here I appeal for any advice, conformation or negation of our thinking, links to white papers etc which would help to clarify how our codecs should be configured, and tell us why we had so much fragmentation.
Many thanks in anticipation…