[xiph-rtp] Difficulties with several RTP streams for a Vorbisstream.

[Silvia.Pfeiffer at csiro.au]

The reason the IETF RTP working group are pushing for sending setup information (such as codebooks for codecs) via http and out-of-band of rtp is that rtp packets have not guarantee of arriving and are not being re-sent if lost. Therefore, information as fundamental as the setup needs to be transported reliably out-of-band. While some payload formats have ignored this general push, it is part of the core design of RTP.

Another thing I meant to mention in this discussion: we seem to be mixing up the design of existing media frameworks (such as DirectShow and JMF), which have been designed to receive interleaved media streams with everything inband (such as via http or from a local, potentially downloaded file) with the transport mechanisms of the real-time RTP protocol, which has originally been designed for live video conference type situations. 
RTP is now being used also for streaming interleaved media streams, which creates much conflict in the IETF working group, as it undermines many of the basic principles of design of the RTP/RTSP/RTCP/SDP protocol family. One of these things is the reliable transport of setup information out-of-band of RTP, and one RTP connection transporting only one stream of media (i.e. audio and video being transported over 2 distinct RTP connections). Just be aware that these principles may not have been taken into account by existing media framework implementations, which may be able to decode RTP sessions, but only those that transport everything in-band.

Cheers,
Silvia.

-----Original Message-----
From:	xiph-rtp-bounces at xiph.org on behalf of Ramón García
Sent:	Mon 11/1/2004 9:27 AM
To:	xiph-rtp at xiph.org
Cc:	
Subject:	Re: [xiph-rtp] Difficulties with several RTP streams for a Vorbisstream.

> Is it less "surprising" for the media framework to read the setup header
> from an http url?"
That is always posible. The depacketizer can create a socket and open
a connection to a server on its own.

>  I checked the Java Media Framework and it seems as if
> the depacketizer has no access at all to the session descriptor, so it
> wouldn't be able to decode the stream at all if not all necessary info
>  is sent in-band.

That would make it imposible to have any format specific  data in the 
session descriptor. I will check.
 
Sending the codebook data in the RTP data stream is scalable. As it is
sent once to all clients, thus it is not degraded with the number of
clients. It is correct that it is sent to more clients than necessary,
but they way multicasting works that does not degrade server
performance, it is the job of routers to replicate packets until they
reach clients. The issue of redundant sending to all clients also
happens with your method, unless a different IP multicast address is
used for the RTP session that sends codebooks, which would be too much
administrative burden (just acquire a new multicast IP address to
support Vorbis). If the same IP address is used for both sessions, the
packets with the codebooks would be send to all clients, as all of
them are suscribed to the IP multicast address (although the packets
would be thrown away by the operating system of the clients as no
process is listening that port).

Ramon
_______________________________________________
xiph-rtp mailing list
xiph-rtp at xiph.org
http://lists.xiph.org/mailman/listinfo/xiph-rtp