About Voip Technology : RTP over TCP

[Guest]

Archived from groups: comp.dcom.voice-over-ip (More info?)

hello All

I am reading information about VoIP technology
For that i am concentrating on SIP (Session Initiation Protocol) and
RTP (Real Time Transport Protocol).

I am interested in implementing RTP over TCP
I found that there are some disadvantages of TCP, some are

1) TCP doesn't support multicasting.

2) Through TCP is reliable, it heavily depends on retransmission of


lost or corrupted packets. That increases Delay. Our aim is real


time delivery of packets not reliability.

3) TCP congestion control mechanism decreases the congestion window

when packet losses are detected.

Apart from these flaws i am interested in implementing RTP over TCP

Is it possible ?
What is feasibility of implementing RTP over TCP ?

One more point is What is feasibility of implementing RTP over TCP in

case of NAT (Network Address Translation) is there ?

Need your valuable suggestion.

Thank You !

Atul

 

[Guest]

Archived from groups: comp.dcom.voice-over-ip (More info?)

Atul wrote:
> hello All
>
> I am reading information about VoIP technology
> For that i am concentrating on SIP (Session Initiation Protocol) and
> RTP (Real Time Transport Protocol).
>
> I am interested in implementing RTP over TCP

It sounds like a bad idea.

> I found that there are some disadvantages of TCP, some are
>
> 1) TCP doesn't support multicasting.
>
> 2) Through TCP is reliable, it heavily depends on retransmission of
> lost or corrupted packets. That increases Delay. Our aim is real
> time delivery of packets not reliability.
>
> 3) TCP congestion control mechanism decreases the congestion window
> when packet losses are detected.
>
> Apart from these flaws i am interested in implementing RTP over TCP

Why?? The flaws you mentioned should be sufficient to discourage any
attempt of that kind!

> Is it possible ?

It makes no sense: RTP is a layer designed to run on top of unreliable
protocols, providing some of the benefist of reliable protocols (e.g.,
guaranteed ordering, achieved through timestamps) without the drawbacks
you mentioned.

> What is feasibility of implementing RTP over TCP ?

If you really want to send multimedia data over TCP, why don't you just
use plain TCP? That might work if your application is non-interactive
(e.g., A/V broadcasting rather than telephony) because aggressive
buffering may smooth over the gaps caused by retransmissions of lost
packets. That's what many current Internet media players and servers do
in alternative to RTSP+RTP or proprietary equivalent protocols; in
fact, they able to handle streaming content over HTTP, which is layered
on top of TCP.

> One more point is What is feasibility of implementing RTP over TCP in
> case of NAT (Network Address Translation) is there ?

Mostly, it will make things worse. There are NAT traversal techniques
("hole punching") that are much easier to implement with UDP than TCP.
Even old bad STUN is only for UDP (that's where the 'U' in "STUN" comes
from).

If all you need is to encapsulate existing RTP flows (posibly adding
security), I suggest you to use some VPN protocol such as PPTP. Or, if
you just need to add security to an application, consider using SRTP
(http://srtp.sourceforge.net/spec.html ).

Enzo

 

[Guest]

Archived from groups: comp.dcom.voice-over-ip (More info?)

My understanding is that voice runs over UDP and not TCP. UDP does not
re-order the packets if they arrive out of sequence hence the need to
run RTP which provides re-ordering of packets.

UDP does not have a congestion control mechanism, nor does it send
acknowledgements like TCP so there is are no retransmits.

SIP is an alternative to RTP, designed (originally) for voice over the
Internet

I could be wrong as I am not an expert and still learning. I'll be
interested to hear others comments on this.

Farouq.

 

[Guest]

Archived from groups: comp.dcom.voice-over-ip (More info?)

Farouq wrote:
> My understanding is that voice runs over UDP and not TCP. UDP does
> not re-order the packets if they arrive out of sequence hence the
> need to run RTP which provides re-ordering of packets.
>
> UDP does not have a congestion control mechanism, nor does it
> send acknowledgements like TCP so there is are no retransmits.
>
> SIP is an alternative to RTP, designed (originally) for voice over
> the Internet

Actually that's not true: SIP (Session Initiation Protocol) is used, as
its name says, for the initial establishment of the session, so that
the two peers can exchange their IP addresses, the UDP port numbers for
the RTP data packets, the codecs that they support etc.

Enzo