TransEdit (and RS): force support for RTP-over-TCP

[userip]

Hi,

 

I know that DVBViewer with RS can use TCP, instead of TCP, for receiving the RTP stream. This is completly optional for the user. The question is:

 

- Can you add support for any SAT>IP server that supports RTP-over-TCP?

 

I hope you agree this suggestion.

[Griga]

RS / DVBViewer / TransEdit don't use RTP over TCP. They are sending / receiving a pure TS over TCP without RTP headers.

 

RTP provides means to compensate for UDP disadvantages, particularly a sequence number enabling packet reordering in case packets are arriving in the wrong order. TS over RTP over TCP is more or less a waste of bandwidth, because TCP does not need such measures.

 

Both the Recording Service as server and DVBViewer / TransEdit as client contain rudimentary support for RTP over TCP, but it is not really elaborated and tested.

[userip]

RS / DVBViewer / TransEdit don't use RTP over TCP. They are sending / receiving a pure TS over TCP without RTP headers.

 

RTP provides means to compensate for UDP disadvantages, particularly a sequence number enabling packet reordering in case packets are arriving in the wrong order. TS over RTP over TCP is more or less a waste of bandwidth, because TCP does not need such measures.

 

Both the Recording Service as server and DVBViewer / TransEdit as client contain rudimentary support for RTP over TCP, but it is not really elaborated and tested.

 

Hi Griga,

 

Thank you for explanation!

 

Regarding RTP-over-TCP, it's not a waste of bandwith, because: a) it's defined in a RFC and supported; you also transport a pure TS over TCP in your software, and carry the RTP header in the TCP stream it's irrelevant as it has less than the MTU size! Moreover, there are no SAT>IP servers that use any reliable (recovering or FEC) technique over the RTP channel. Therefore, add support to RTP-over-TCP is a simple and valuable option.

 

Futhermore, if you have included some rudimentary support inside RS, TE and DVBViewer... why not enable it for testing?

 

Finally, I like to decribe a realworld scenario where RTP-over-TCP has sense: a SAT>IP client connected over WIRELESS to a SAT>IP server, and the network has several noise but low congestion. And yes, RTP-over-TCP is complex, as when using it it's necessary to add support for buffering and resync. The reason is when the TCP connection is overloaded and it's needed to flush the buffer and restart the streaming in a new point.

 

However, please, think about include some minimal support for RTP-over-TCP.

Thank you!