Subject: RTP over ATM ?

From: Peter Hoermann <[email-masked]>
Date: Tue, 28 Apr 1998 18:41:30 +0200

Hi,

is anybody out there working on 'RTP over ATM' (NOT: 'RTP over UDP over
ATM'), i.e. directly packing the AV data in ATM cells ? I came across
this because RTP/RTCP is not linked to a certain protocol stack and I'm
working on Audio/Video over ATM, trying to avoid the overhead of e.g.
the TCP/IP stack.

Many thanx in advance

Peter

---

From: Melinda Shore <[email-masked]>
Date: Tue, 28 Apr 1998 13:13:59 -0400

> working on Audio/Video over ATM, trying to avoid the overhead of e.g.

H.323 Annex C describes a mechanism for carrying RTP in AAL5
frames, but it's got some problems with header overhead,
even without IP.  Francois Audet at Nortel has done some
analysis and made some packetization recommendations to
much improve the situation, but not really fix it.

K.K. Ramakrishnan sent several contributions to the ATM
Forum RMOA WG describing a mechanism for sending compressed
RTP over AAL5, using the U-U byte for indicating header
info.  It's rather nice.

Melinda Shore
Only briefly at Cornell University
[email-masked]

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 28 Apr 1998 20:24:28 +0200 (MET DST)

> working on Audio/Video over ATM, trying to avoid the overhead of e.g.

There is no TCP in RTP, so there is no TCP overhead to avoid.
Avoiding the header overhead of IP, UDP, and RTP is best done using IP
header compression and compressed RTP.
Avoiding the (now really significant) overhead of AAL5 is best done
using AAL2 (the new one).
The remaining work is defining a mapping of IP/IP header
compression/CRTP on AAL2 VCs.
There have been some hallway discussions about this at the Spring IETF.

Let's do it (says he who didn't even finish the existing homework from
that IETF).  Any people from industry who would be interested?

Direct RTP over ATM (AAL5) sounds like a remnant of very, very old
thinking. 

Gruesse, Carsten

---

From: Melinda Shore <[email-masked]>
Date: Tue, 28 Apr 1998 15:13:00 -0400

> using AAL2 (the new one).

That really depends, and it's highly situational.  It's
certainly possible to argue that if you're using, say, a 5ms
packet encoded using G.711, you've no overhead since you'd
have 8 unused bytes in the cell payload, anyway.  A more
immediate concern is that AAL2 is being perceived as most
suitable for trunking, and I expect that it will be quite
some time before we see AAL2 support in NIC SARs.

Melinda Shore
Temporarily at Cornell University
[email-masked]

---

From: "K. K. Ramakrishnan" <[email-masked]>
Date: Wed, 29 Apr 1998 06:59:23 -0400

We have recently proposed that the ideas of header compression
for RTP/UDP/IP be used when carrying RTP payloads over ATM
using AAL5.
If you "model" and ATM VC as a point to point virtual link, then
you can carry the compressed header in the AAL5 trailer
(a sequence number is needed, which we propose should
be in the U-U field; everything else is already there, with
the VC providing the function of the context ID). The rest of
the trailer (length, CRC) provides useful and necessary functionality.

This way, you get reasonable efficiency when carrying
real-time data over ATM using AAL5. In particular,
with 5 msec G.711 voice, a cell carries all the needed
information, including the AAL5 trailer.

We use a "header extension" bit in the U-U field
to allow us to communicate uncompressed
(partial or full) headers.

            K. K. Ramakrishnan

-- 
K. K. Ramakrishnan                             Email:[email-masked]
AT&T Labs-Research, Rm. A155                   Tel: (973)360-8766
180 Park Ave, Florham Park, N.J. 07932         Fax: (973) 360-8050
	URL: http://www.research.att.com/info/kkrama