[xiph-rtp] Fragmenting in RTP versus letting UDP fragment

[Ken Linder (kc7rad)]

TNX Phil,
I have been doing MP3 streaming with IceCast and Shoutcast for some time, 
but this is the first time I am getting into the thick-of-things.

My constraints are a little more difficult to get around.  My packet only 
has a max of 256 bytes in the payload.  I am not dealing with TCP or IP or 
any 'wired' protocol.  I am looking into using the AX.25 (Amateur packet 
radio) spec to stream.  goto www.tapr.org for more info on AX.25

Further, the highest speed normally used for this is 9600 bps!  Most users 
still use 1,200 bps.  There are commercial modems that will go up to 56k and 
a few experimenters have gotten up to about 128k.  Unfortunately, 9600 is 
probably the bare minimum for my purposes using SPEEX.

There is also a sort of multicast with AX.25 and the spec takes care of 
rearranging the out-of-order packets.  Lost packets are simply lost.  There 
is a way to accept packets that do not validate but that can cause problems.

TNX
Ken - KC7RAD
----- Original Message ----- 
From: "Phil Kerr" <phil at plus24.com>
To: "Ken Linder (kc7rad)" <kc7rad at radstream.com>
Cc: <xiph-rtp at xiph.org>
Sent: Tuesday, November 02, 2004 10:25 AM
Subject: Re: [xiph-rtp] Fragmenting in RTP versus letting UDP fragment


> Hi Ken,
>
> Yes, RTP uses UDP as the container so there is no 'built-in' retry 
> mechanism.
>
> The maximum, theoretical, size of an UDP packet is just under 64k but due 
> to differing platform implementations of TCP/IP stacks it's generally 
> accepted that the largest UDP  packet size you can have without having 
> fragmentation is 576 octets (as defined in RFC 791), but as layer 2 MTU is 
> often set at 1500 octets this is the practical max.
>
> Fragmentation reassembly is taken care of by the TCP/IP stack (or raw 
> frame stack if at layer 2) and should be transparent to applications, it 
> does cause a bit of processing overhead and therefore reduces throughput.
>
> Detecting lost, and out-of-sequence, packets is taken care of by the 
> sequence IDs and timestamps and how this event is handled is then left to 
> the application.
>
> Having our own fragmentation mechanism allows us to detect if a received 
> packet is part of a multi-packet block and if one of those packets is lost 
> we can detect this.
>
> Have a look at the "Packet Loss" section of the Vorbis I-D to see how this 
> works.
>
> -P
>
>
> On 2 Nov 2004, at 15:29, Ken Linder (kc7rad) wrote:
>
>> Pardon my ignorance, or not, as the case may be (newbie here).  It is my 
>> understanding that RTP normally rides on UDP packets.  That being the 
>> case, there could be no retries...  right?
>>
>> Now, if the RTP was riding on TCP, then there are built-in retries.  Of 
>> course, using TCP throws away many advantages of UDP/multicasting.
>>
>> Now, how the heck can I fin get real time SPEEX data to fit in a 256 byte 
>> packet, eh?  :-)
>>
>> Ken
>> KC7RAD
>> ----- Original Message ----- From: "Jack Moffitt" <jack at xiph.org>
>> To: <xiph-rtp at xiph.org>
>> Sent: Sunday, October 31, 2004 9:07 PM
>> Subject: Re: [xiph-rtp] Fragmenting in RTP versus letting UDP fragment
>>
>>
>>>> No, RTP is a real time protocol. There are no retries at all. If
>>>> something does not arrive it is simply not played.
>>>
>>> You have some time to retry even if it is realtime.  It's not 'one shot
>>> only'.  After all, the packets aren't guarunteed to arrive in order
>>> anyway.
>>>
>>> jack.
>>
>>
>> _______________________________________________
>> xiph-rtp mailing list
>> xiph-rtp at xiph.org
>> http://lists.xiph.org/mailman/listinfo/xiph-rtp
>>
>
>
>
>