Subject: [AVT] eCRTP - does it work well over wireless links?

From: [email-masked]
Date: Wed, 7 Aug 2002 14:21:59 -0500

Hello,

A question about enhanced compression of RTP (eCRTP).  Can someone please summarize what are the primary improvements over RFC 2508 (CRTP)?  Are those improvements added in order to enable operation over wireless (e.g. cellular) radio links, or is it just to correct some known problems with CRTP?

Any strong technical reasons why eCRTP should not be used (compared to something like ROHC RTP)?  I seem to remember that CRTP has some inefficiences when used over links with delay and non-trivial packet loss characteristics (mostly designed for wireline networks) so it implies that there could be big changes needed to get it to work well over wireless links.

Have there been any testing/generation of results for eCRTP over wireless links?

Rgds,
Chris Clanton
Nokia Research Center 

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

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 9 Aug 2002 10:01:58 -0700

> A question about enhanced compression of RTP (eCRTP).  Can someone 
> please summarize what are the primary improvements over RFC 2508 
> (CRTP)?  Are those improvements added in order to enable operation 
> over wireless (e.g. cellular) radio links, or is it just to correct 
> some known problems with CRTP?

CRTP works link-by-link.  That is, CRTP works between two routers,
and both routers are involved in the compression/decompression of
the RTP/UDP/IP headers.

ECRTP works end-to-end over some kind of tunneling protocol.  That 
is, ECRTP works between two systems which do the compression, and 
the ECRTP packets are tunneled over a network of multiple routers.  
The multiple routers are not involved in the compression/decompression
of the RTP/UDP/IP headers -- rather, only the two systems at the
edges are involved in the compression/decompression.

So, they have completely different design goals.  ECRTP doesn't
replace CRTP, and CRTP doesn't replace ECRTP.  For example, CRTP
expects the link to be relatively lossless; ECRTP expects the
tunnel to be relatively lossy.  ECRTP sends occasional "key 
frame"; CRTP doesn't.  CRTP allows the receiver to ask the
sender to retransmit a frame that was lost; ECRTP doesn't (the
round-trip expected for the expected use of ECRTP [over 
multiple router hops] makes such a request meaningless for 
realtime audio or video).  CRTP expects packets will never
be misordered (because they never get out of order over a 
link); ECRTP expects some packets to be misordered (because
they could be misordered over an IP network).

> Any strong technical reasons why eCRTP should not be used (compared 
> to something like ROHC RTP)? 

Not to my eyes.

> I seem to remember that CRTP has some 
> inefficiences when used over links with delay and non-trivial packet 
> loss characteristics (mostly designed for wireline networks) so it 
> implies that there could be big changes needed to get it to work well 
> over wireless links.

That's correct regarding CRTP.

Those "big changes" were done to ECRTP.  ECRTP may well be very applicable
to wireless links, as their characteristics are similar to a high-loss
and high-delay wired network.

-d