Subject: Re: [AVT] RTP w/ TCP, RTP w/o RTCP ...

From: Peter Westerink <[email-masked]>
Date: Tue, 3 Dec 2002 14:07:36 -0500

Hello Ron,

If I read your thoughts correctly, you suggest to have a framing format
that is the same for RTP/RTCP over RTSP, RTP/RTCP over TCP, or separate RTP
over TCP and RTCP over TCP. Sounds like a good idea and it allows all those
options with the same format. I am also not too worried about the extra 2
bytes overhead (the $ and the channel number).

      Peter

                      Ron Frederick                                                                                    
                      <[email-masked]        To:       Peter Westerink/Watson/IBM@IBMUS                              
                      m>                       cc:                                                                     
                                               Subject:  Re: [AVT] RTP w/ TCP, RTP w/o RTCP ...                        
                      12/03/2002 01:47                                                                                 
                      PM                                                                                               

Hi Peter...

In message
<[email-masked]
m> you write:
> The reason I "like" the RTP over TCP is because it is very simple. In my
> experience it is actually more complicated to implement RTP over RTSP.
The
> reason is that server and client now have to be enabled to having
multiple
> listeners and/or senders on the RTSP port instead of a single one. Also,
> we're mixing the control system with the data system, which may have been
> or may preferably be designed separated. But if there's an interest in
RTP
> over TCP, regardless of the reasons (like complexity), isn't that a
reason
> to consider this?
You raise a good point about it not always being appropriate/convenient to
do full interleaving of control & data on a single connection. In some
applications, it may be easier architecturally to keep them running over
independent TCP connections. Even so, though, I'd argue that the RTSP-style
framing for the data makes sense, as it allows you to run RTP & RTCP over
the
same channel. So, in that case, you'd have _only_ these $-encapsulated
packets on a "data-only" TCP connection, but the channel numbers would
still
be useful. You also get a bit of a sanity check that you're not getting out
of sync by being able to test for the '$'. While you can sort of doing that
by testing for the RTP 'version=2' bits in the simpler encoding, that's not
as much protection.

In rare cases, I could imagine an application which wanted to keep all of
the control, RTP, and RTCP in completely separate threads of control, with
some very minimal communication on the RTP/RTCP side to provide the
necessary
info like packet & byte counts and timestamps. However, that's really
starting
to stretch things. I've written several RTP-based applications on a wide
variety of platforms ranging from embedded hardware to standard UNIX apps,
and I've never run into a case where it would have been difficult to let
an RTP and RTCP sender share a socket... Even if that did happen, there's
nothing preventing you from using the 4-byte style headers and opening up
independent sockets for all of the streams. In that case, I'll admit that
the extra two bytes don't buy you much beyond the extra framing check, but
they also don't cost very much.
--
Ron Frederick
[email-masked]

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: Ron Frederick <[email-masked]>
Date: Tue, 03 Dec 2002 11:38:40 -0800

> bytes overhead (the $ and the channel number).
Yes, that's right. Basically, using the RTSP-style framing, you could choose
to run your control & all your data streams over a single TCP connection as
RTSP does, or you could open a new TCP connection just for data but still use
this framing to multiplex RTP/RTCP over it, or if you really wanted to you
could send RTP & RTCP over independent TCP connections, but to keep things
simple you'd still using the same framing even in that case.
--
Ron Frederick
[email-masked]