RE: [AVT] VoIP Shim for RTP Payload Formats

["Ingemar Johansson S \(LU/EAB\)" <ingemar.s.johansson at ericsson.com>]

Hi

Good point. I beleive that I confused myself (possibly others) in the
beginning. 

My original view was:
Shim+Payload = new payload type, derived from original payload type,
this was supposed to be signaled in SDP.

While the IETF way of looking at things (ch 13 RFC3550) is that it
should be interpreted as :
RTP header+Shim = RTP header extension.

One drawback with using the approach according to
draft-ietf-avt-rtp-hdrext is that it costs 8 bytes to transfer as little
as one byte of inband signaling data. This extra overhead + additional
update overhead in header compression (RoHC) increases the risk to cause
segmentation at lower layers in optimized cellular networks.

Ingemar

> -----Original Message-----
> From: Even, Roni [mailto:roni.even at polycom.co.il] 
> Sent: den 29 augusti 2006 18:48
> To: Colin Perkins; Ingemar Johansson S (LU/EAB)
> Cc: Randell Jesup; Lide, David; avt at ietf.org
> Subject: RE: [AVT] VoIP Shim for RTP Payload Formats
> 
> Colin,
> The question is if this is an RTP header extension or a 
> payload header.
> I would like to see some justification for having the 
> redundancy as header extension As for the SHIM protocol my 
> view is that it is not needed since the header extension 
> draft explains how to transfer the data. All that is needed 
> is just the specific extension definition.
> Roni Even 
> 
> > 
> > If in-band signalling is to be done, then an RTP header 
> extension is 
> > the right approach (e.g. following draft-ietf-avt-rtp-hdrext). This 
> > does not require a new profile, and the signalling is 
> already defined.
> > 
> > Colin
> > 
> > _______________________________________________
> > Audio/Video Transport Working Group
> > avt at ietf.org
> > https://www1.ietf.org/mailman/listinfo/avt
> 

_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
https://www1.ietf.org/mailman/listinfo/avt