Subject: [AVT] VoIP Shim for RTP Payload Formats

From: "Ingemar Johansson S \(LU/EAB\)" <[email-masked]>
Date: Thu, 24 Aug 2006 08:45:21 +0200

Hi

This message is sent to notify about a new draft that is available at
http://tools.ietf.org/wg/avt/draft-johansson-avt-rtp-shim-00.txt

Title: "VoIP Shim for RTP Payload Formats"
Abstact:
This document provides a general mechanism to provide with compact and
efficient inband signaling mechanisms for VoIP applications using the
RTP (Real-Time Transport Protocol). It provides the option to include a
few additional inband signaling bytes in between the RTP header and the
RTP payload. The intention of using Shim is to enable a fast inband
signaling channel. The main application is for two party
teleconferencing, The presented mechanism is not recommended to be used
for multi party teleconferencing applications. The name Shim is to refer
to the "little thing something that one put in between". 

Regards
Ingemar Johansson

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

---

From: Colin Perkins <[email-masked]>
Date: Fri, 25 Aug 2006 11:42:16 +0100

Ingemar,

> to the "little thing something that one put in between".

Can you comment on why you believe defining a new RTP profile such as  
this is to be preferred over the mechanism defined in draft-ietf-avt- 
rtp-hdrext? The small bandwidth saving doesn't seem compelling,  
compared to the complex signalling that will be required to negotiate  
a new profile, and the significant backwards compatibility issues.

Also, can you comment on why you consider in-band signalling is  
necessary for the purpose of requesting changes to the compression  
ratio/redundancy? The sender would seem able to infer any changes  
needed from RTCP reception reports.

Colin

---

From: "Ingemar Johansson S \(LU/EAB\)" <[email-masked]>
Date: Fri, 25 Aug 2006 14:08:56 +0200

Hi

Thanks for the comments ,answers below.

-----Original Message-----
From: Colin Perkins [mailto:[email-masked]]
Sent: den 25 augusti 2006 12:42
To: Ingemar Johansson S (LU/EAB)
Cc: [email-masked]
Subject: Re: [AVT] VoIP Shim for RTP Payload Formats

Ingemar,

>> This document provides a general mechanism to provide with compact 
>> and efficient inband signaling mechanisms for VoIP applications using

>> the RTP (Real-Time Transport Protocol). It provides the option to 
>> include a few additional inband signaling bytes in between the RTP 
>> header and the RTP payload. The intention of using Shim is to enable 
>> a fast inband signaling channel. The main application is for two 
>> party teleconferencing, The presented mechanism is not recommended to

>> be used for multi party teleconferencing applications. The name Shim 
>> is to refer to the "little thing something that one put in between".
>
>(Q) Can you comment on why you believe defining a new RTP profile such 
>as this is to be preferred over the mechanism defined in 
>draft-ietf-avt- rtp-hdrext? The small bandwidth saving doesn't seem 
>compelling, compared >to the complex signalling that will be required
to negotiate a new profile, and the significant backwards compatibility
issues.
(A) I have considered this opportunity and the plain reason why this
approach was not pursued was that I got the impression that header
extentions is meant for experimental purposes only. Also I get the
impression that it is more acceptable to specify several payload types
than using the header extension. Question is then : Is it acceptable to
use the header extension bit for other than experimental purposes ? 

>(Q) Also, can you comment on why you consider in-band signalling is 
needed >from RTCP reception reports.
(A) Main argument here is that the RTCP reports can become quite bulky,
in header compressed links (eg. Compressed with RoHC) the RTP flow will
be header compressed, something that will not happen with RTCP packets. 
What I wanted was a fast inband signaling mechanism that cause as little
overhead as possible.

Regards
Ingemar 

-----Original Message-----
From: Colin Perkins [mailto:[email-masked]] 
Sent: den 25 augusti 2006 12:42
To: Ingemar Johansson S (LU/EAB)
Cc: [email-masked]
Subject: Re: [AVT] VoIP Shim for RTP Payload Formats

Ingemar,

> RTP (Real-Time Transport Protocol). It provides the option to include 
> a few additional inband signaling bytes in between the RTP header and 
> the RTP payload. The intention of using Shim is to enable a fast 
> inband signaling channel. The main application is for two party 
> teleconferencing, The presented mechanism is not recommended to be 
> used for multi party teleconferencing applications. The name Shim is 
> to refer to the "little thing something that one put in between".

Can you comment on why you believe defining a new RTP profile such as
this is to be preferred over the mechanism defined in draft-ietf-avt-
rtp-hdrext? The small bandwidth saving doesn't seem compelling, compared
to the complex signalling that will be required to negotiate a new
profile, and the significant backwards compatibility issues.

Also, can you comment on why you consider in-band signalling is
necessary for the purpose of requesting changes to the compression
ratio/redundancy? The sender would seem able to infer any changes needed
from RTCP reception reports.

Colin

---

From: "Ingemar Johansson S \(LU/EAB\)" <[email-masked]>
Date: Fri, 25 Aug 2006 15:53:34 +0200

> Sent: den 25 augusti 2006 14:45
> On 25 Aug 2006, at 13:08, Ingemar Johansson S ((LU/EAB)) wrote:
> >>> This message is sent to notify about a new draft that is 
> available 
> >>> at
> >
> >>> party teleconferencing, The presented mechanism is not 
> recommended 
> >>> to
> >
> >> (Q) Can you comment on why you believe defining a new RTP profile 
> >> such as this is to be preferred over the mechanism defined in
> > to negotiate a new profile, and the significant backwards 
> > compatibility issues.
> > than using the header extension.
> 
> The mechanism you propose in your draft is an extension to 
> the fixed RTP header, and so will be a new profile, not a 
> payload format (see RFC 3550 section 5.3). This makes 
> backwards compatibility difficult, and greatly increases the 
> complexity of the signalling.
>
The intention with this mechanism is that it should be negotiated during
session setup. Therefore I don't see this as a backwards compatibility
issue.
> 
> > Question is then : Is it acceptable to use the header extension bit 
> > for other than experimental purposes ?
> 
> Yes, although I would discourage in-band signalling of the 
> form you are proposing, since RTCP solves the same problem.

Inband signaling of the type proposed already exist for eg. 
the AMR payload format (RFC3267), it is however limited to the 
request of lower/higher codec rate. The intention of this added 
inband signaling is to allow for requests regarding frame aggregation 
and redundancy during a session so in that aspect it is a 
continuation of the inband signaling concept that already exist. 
Yes it is possible to do with RTCP but as you point out below the 
use is restricted due to bandwidth requirements and possibly also 
limited to DTX periods in order to avoid disturbance on the RTP flow in 
Bottleneck links. Also there is a discussion going on in e.g 3GPP 
where the use of RTCP i limited or even disabled.

> > (A) Main argument here is that the RTCP reports can become quite 
> > bulky, in header compressed links (eg. Compressed with 
> RoHC) the RTP 
> > flow will be header compressed, something that will not happen with 
> > RTCP packets.
> > What I wanted was a fast inband signaling mechanism that cause as 
> > little overhead as possible.
> 
> The RTCP timers will constrain it to a configured small 
> fraction of the bandwidth, so I don't find this argument convincing.
> 
> Colin
>

---

From: Colin Perkins <[email-masked]>
Date: Fri, 25 Aug 2006 15:29:38 +0100

On 25 Aug 2006, at 14:53, Ingemar Johansson S ((LU/EAB)) wrote:
...
> The intention with this mechanism is that it should be negotiated  
> during session setup. Therefore I don't see this as a backwards  
> compatibility issue.

How do you propose to negotiate this? There is no well-defined  
solution to RTP profile negotiation in SDP at present, and the  
requirements work (draft-andreasen-mmusic-sdp-capability- 
negotiation-00.txt) is at an early stage.

Once you've solved the negotiation problem, there is still a  
backwards compatibility issue with the extended RTP headers, which  
does not occur if RTP header extensions or RTCP are used.

> continuation of the inband signaling concept that already exist.

This is one of the less desirable features of the AMR payload format,  
and was included solely for backwards compatibility.

> Bottleneck links.

I don't consider these to be credible reasons for not using RTCP. The  
bandwidth used by RTCP is a small fraction of the RTP rate, and  
should not be a significant disruption.

> Also there is a discussion going on in e.g 3GPP  where the use of  
> RTCP i limited or even disabled.

RTCP is not an optional part of RTP. If 3GPP are proposing to disable  
it, then their architecture is broken.

Colin

---

From: Colin Perkins <[email-masked]>
Date: Fri, 25 Aug 2006 13:45:02 +0100

On 25 Aug 2006, at 13:08, Ingemar Johansson S ((LU/EAB)) wrote:
>>> available at
>>> recommended to
>> such
> compatibility

The mechanism you propose in your draft is an extension to the fixed  
RTP header, and so will be a new profile, not a payload format (see  
RFC 3550 section 5.3). This makes backwards compatibility difficult,  
and greatly increases the complexity of the signalling.

> for other than experimental purposes ?

Yes, although I would discourage in-band signalling of the form you  
are proposing, since RTCP solves the same problem.

> bulky,

The RTCP timers will constrain it to a configured small fraction of  
the bandwidth, so I don't find this argument convincing.

Colin

---

From: "Lide, David" <[email-masked]>
Date: Fri, 25 Aug 2006 08:50:46 -0500

On the use of RTCP RR for this purpose, there are two problems
(1) need to be able to force the RR generation, i.e., overrule the
default RTCP bandwidth rules
(2) can't signal what payload the other side should switch to (no
equivalent of a CMR field)

Couldn't RFC 4585 be used here?  This relaxes the RTCP b/w rules and
allows early RTCP messages to be sent.  It also defines a new RTCP block
explicitly for this purpose.

Regards,
dave

-----Original Message-----
From: Ingemar Johansson S (LU/EAB)
[mailto:[email-masked]] 
Sent: Friday, August 25, 2006 8:09 AM
To: [email-masked]
Subject: RE: [AVT] VoIP Shim for RTP Payload Formats

Hi

-----Original Message-----
From: Colin Perkins [mailto:[email-masked]]
Sent: den 25 augusti 2006 12:42
To: Ingemar Johansson S (LU/EAB)
Cc: [email-masked]
Subject: Re: [AVT] VoIP Shim for RTP Payload Formats

Ingemar,

Regards
Ingemar 

-----Original Message-----
From: Colin Perkins [mailto:[email-masked]] 
Sent: den 25 augusti 2006 12:42
To: Ingemar Johansson S (LU/EAB)
Cc: [email-masked]
Subject: Re: [AVT] VoIP Shim for RTP Payload Formats

Ingemar,

Colin

---

From: Randell Jesup <[email-masked]>
Date: Fri, 25 Aug 2006 13:25:40 -0400

>default RTCP bandwidth rules

Not just bandwidth, but also minimum time separation (~5s).  See AVPF to
solve this (but there we've again introduced a profile negotiation, which
Colin was recommending against).  So is it worse to negotiate a new
profile for inband/shim than it is to negotiate a profile for AVPF?
Good question.

>explicitly for this purpose.

AVPF doesn't restrict the bandwidth rules, it changes the rules about
how you use the bandwidth.  You're still limited to 5% (or other value
if you negotiated it).

In a hypothetical 20ms, 200 byte payload codec (96000 kbps) adding 1 byte
to the header per packet is only 400 bits/second (~0.4%), and 2000 bits
(250 bytes) in 5 seconds.  That's roughly the size of 2, maybe 3 RTCP
packets in that timeframe (assuming AVPF!), but it gives you MUCH finer
granularity to adjust (and lower delay in adjusting, especially in AVP
mode).  Note that a lower-bitrate codec such as G.729 would be a higher
percentage, but still lower than RTCP.

-- 
Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS team
[email-masked]

---

From: "Ingemar Johansson S \(LU/EAB\)" <[email-masked]>
Date: Mon, 28 Aug 2006 09:02:26 +0200

> Sent: den 25 augusti 2006 16:30
> the fixed 
> How do you propose to negotiate this? There is no 
> well-defined solution to RTP profile negotiation in SDP at 
> present, and the requirements work 
> (draft-andreasen-mmusic-sdp-capability-
> backwards compatibility issue with the extended RTP headers, 
> which does not occur if RTP header extensions or RTCP are used.

I believe that the negiotation problems are something that can be
solved. Also I don't believe that backwards compatibility is an issue.
 
> form you 
> > the AMR payload format (RFC3267), it is however limited to 
> the request 
> > of lower/higher codec rate. The intention of this added inband 
> > signaling is to allow for requests regarding frame aggregation and 
> > redundancy during a session so in that aspect it is a 
> continuation of 
> > the inband signaling concept that already exist.
> 
> This is one of the less desirable features of the AMR payload 
> format, and was included solely for backwards compatibility.
> 
> > Yes it is possible to do with RTCP but as you point out 
> below the use 
> > is restricted due to bandwidth requirements and possibly 
> also limited 
> > to DTX periods in order to avoid disturbance on the RTP flow in 
> > Bottleneck links.
> 
> I don't consider these to be credible reasons for not using 
> RTCP. The bandwidth used by RTCP is a small fraction of the 
> RTP rate, and should not be a significant disruption.
>
One example of the possible problems that RTCP might face in a 3G
cellular network, this is not to be interpreted as a bash at 3G
networks, it is just the laws of physics that applies to all wireless
access technology today.
The smallest size of the RTCP packets (SR) is 672bits with IPv4 . In
order to add the proposed functionality (request for redundancy/frame
aggregation one can add an APP packet (128bits). The total size is then
800 bits. With IPv6 the size is 160 bits more.
With the optimized radio transmission scheduled for in 3GPP the maximum
size of the radio blocks is in the order 300-400 bits. This means that
the RTCP packets always get fragmented, this is no big issue with
persistent radio bearers such as defined for HSDPA as they do
retransmission until the packet is reassembled, there will be a little
more jitter however. 
There are however also specified non persistent radio bearers in
GERAN-EDGE that allows a maximum of one retransmission, in this case the
risk is quite high that the RTCP packets does not reach the receiver at
all, especially if the RTCP sender is close to a cell border. This means
that there is a risk to use RTCP in the adaptation. 

> 
> > Also there is a discussion going on in e.g 3GPP  where the 
> use of RTCP 
> > i limited or even disabled.
> 
> RTCP is not an optional part of RTP. If 3GPP are proposing to 
> disable it, then their architecture is broken.
See above for an effort to explain the reasoning.

---

From: "Ingemar Johansson S \(LU/EAB\)" <[email-masked]>
Date: Mon, 28 Aug 2006 09:13:16 +0200

> From: Randell Jesup [mailto:[email-masked]] 
> Sent: den 25 augusti 2006 19:26
> To: Lide, David
> Cc: Ingemar Johansson S (LU/EAB); [email-masked]
> Not just bandwidth, but also minimum time separation (~5s).  
> See AVPF to solve this (but there we've again introduced a 
> profile negotiation, which Colin was recommending against).  
> So is it worse to negotiate a new profile for inband/shim 
> than it is to negotiate a profile for AVPF?
> Good question.
> 
> >allows early RTCP messages to be sent.  It also defines a new RTCP 
> >block explicitly for this purpose.
> 
> AVPF doesn't restrict the bandwidth rules, it changes the 
> rules about how you use the bandwidth.  You're still limited 
> to 5% (or other value if you negotiated it).
> 
> In a hypothetical 20ms, 200 byte payload codec (96000 kbps) 
> adding 1 byte to the header per packet is only 400 
> bits/second (~0.4%), and 2000 bits (250 bytes) in 5 seconds.  
> That's roughly the size of 2, maybe 3 RTCP packets in that 
> timeframe (assuming AVPF!), but it gives you MUCH finer 
> granularity to adjust (and lower delay in adjusting, 
> especially in AVP mode).  Note that a lower-bitrate codec 
> such as G.729 would be a higher percentage, but still lower than RTCP.
Just wanted to add that with the proposed solution there are two
alternatives. 
1) Continuous 1 byte overhead
2) Overhead only if Shim is sent
The latter assumes that one can switch between two payload types.
As regards to how inband signaling is solved, by means of different
payload types or using the extension bit is as I see it as a matter of
taste, actually I initially sketched an a solution using the extension
bit earlier but as the impression was that the extension bit should not
be touched. This opinion seem to have changed however and beleive that
it should be possible to use the mechanism proposed in
draft-ietf-avt-rtp-hdrext. My main point is however that inband
signaling is to prefer over RTCP.

> 
> --
> Randell Jesup, Worldgate (developers of the Ojo videophone), 
> ex-Amiga OS team [email-masked]
> 
>

---

From: Colin Perkins <[email-masked]>
Date: Mon, 28 Aug 2006 10:57:54 +0100

> The latter assumes that one can switch between two payload types.

I think there is some confusion here: the shim you propose is an  
extension to the fixed RTP header, and hence must be a new RTP  
profile, rather than a new payload type [RFC 3550 section 5.3]. This  
is why there are difficult signalling issues and backwards  
compatibility problems.

Colin

---

From: "Ingemar Johansson S \(LU/EAB\)" <[email-masked]>
Date: Mon, 28 Aug 2006 14:21:50 +0200

> Sent: den 28 augusti 2006 11:58
> Cc: Randell Jesup; Lide, David; [email-masked]
> >> See AVPF to solve this (but there we've again introduced a profile 
> >> negotiation, which Colin was recommending against).
> rules about 
> >> how you use the bandwidth.  You're still limited to 5% (or other 
> >> value if you negotiated it).
> >>
> >> In a hypothetical 20ms, 200 byte payload codec (96000 
> kbps) adding 1 
> >> byte to the header per packet is only 400 bits/second (~0.4%), and 
> >> 2000 bits (250 bytes) in 5 seconds.
> timeframe 
> >> (assuming AVPF!), but it gives you MUCH finer granularity 
> to adjust 
> >> (and lower delay in adjusting, especially in AVP mode).  
> Note that a 
> >> lower-bitrate codec such as G.729 would be a higher 
> percentage, but 
> >> still lower than RTCP.
> I think there is some confusion here: the shim you propose is 
> an extension to the fixed RTP header, and hence must be a new 
> RTP profile, rather than a new payload type [RFC 3550 section 
> 5.3]. This is why there are difficult signalling issues and 
> backwards compatibility problems.

So the bottom line is that use of the extension bit is much better
then?. Reading ch 5.3 in RFC3550 I get the feeling that one need to
specify 
an RTP profile when one use this aswell or is possible to go around this
requirement if one adopt the metodology specified in
draft-ietf-avt-rtp-hdrext ?. 
I see no big problem to use the extenstion bit for the purpose of inband
signaling, all I want to have in place is inband signaling with a
sufficiently low overhead. If I understand draft-ietf-avt-rtp-hdrext
correctly the minimum overhead is 4bytes when the extension bit is set
which I believe is low enough. 
As I understand it the general consensus was that the extension bit was
not meant to be touched but as I understand things it is OK to use the
extension bit now.

Ingemar

---

From: "Even, Roni" <[email-masked]>
Date: Mon, 28 Aug 2006 15:51:11 +0300

Hi,
Some comments after reading the draft and the email exchange 

I am not sure about the right way here. The reason is that even though
the SHIM tries to define a general channel I only see one use here.

I do not see how Shims ID are allocated and managed.

Maybe if the problem is just for the AMR codecs then maybe you can
define a new payload type and have this information as a payload header
or payload packet type like in the video codecs. This will enable
negotiation.

My understanding is that this is a back channel type of message so it
will only work if you have bi-directional communication which is what
the RTCP channel is. If this is true then you should state it.

Thanks
Roni Even

---

From: "Ingemar Johansson S \(LU/EAB\)" <[email-masked]>
Date: Tue, 29 Aug 2006 11:35:44 +0200

Hi

I guess I stand corrected here. 

Ingemar

> From: Lide, David [mailto:[email-masked]] 
> Sent: den 28 augusti 2006 21:26
> To: Ingemar Johansson S (LU/EAB); Colin Perkins
> Cc: Randell Jesup; [email-masked]
> "If I understand draft-ietf-avt-rtp-hdrext correctly the 
> minimum overhead is 4bytes when the extension bit is set 
> which I believe is low enough."  Wouldn't it be 8 bytes ?
> 
> 4 bytes for the RTP extension as in 3550 (with a 16 bit ID as 
> 0XBEDE and
> a 16 bit length of 1).    You then have one byte ID|LEN to define this
> extension (SHM)  and 3 bytes to carry your SHM info.
> 
> Sent: Monday, August 28, 2006 8:22 AM
> To: Colin Perkins
> So the bottom line is that use of the extension bit is much 
> better then?. Reading ch 5.3 in RFC3550 I get the feeling 
> that one need to specify an RTP profile when one use this 
> aswell or is possible to go around this requirement if one 
> adopt the metodology specified in draft-ietf-avt-rtp-hdrext ?. 
> I see no big problem to use the extenstion bit for the 
> purpose of inband signaling, all I want to have in place is 
> inband signaling with a sufficiently low overhead. If I 
> understand draft-ietf-avt-rtp-hdrext correctly the minimum 
> overhead is 4bytes when the extension bit is set which I 
> believe is low enough. 
> As I understand it the general consensus was that the 
> extension bit was not meant to be touched but as I understand 
> things it is OK to use the extension bit now.
> 
> Ingemar
> 
> 
> 
>

---

From: "Lide, David" <[email-masked]>
Date: Mon, 28 Aug 2006 14:25:33 -0500

"If I understand draft-ietf-avt-rtp-hdrext
correctly the minimum overhead is 4bytes when the extension bit is set
which I believe is low enough."  Wouldn't it be 8 bytes ?

4 bytes for the RTP extension as in 3550 (with a 16 bit ID as 0XBEDE and
a 16 bit length of 1).    You then have one byte ID|LEN to define this
extension (SHM)  and 3 bytes to carry your SHM info.

-----Original Message-----

Ingemar

---

From: Colin Perkins <[email-masked]>
Date: Tue, 29 Aug 2006 16:38:51 +0100

> draft-ietf-avt-rtp-hdrext ?.

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

---

From: "Even, Roni" <[email-masked]>
Date: Tue, 29 Aug 2006 19:47:44 +0300

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

---

From: "Ingemar Johansson S \(LU/EAB\)" <[email-masked]>
Date: Wed, 30 Aug 2006 08:30:16 +0200

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

> From: Even, Roni [mailto:[email-masked]] 
> Sent: den 29 augusti 2006 18:48
> To: Colin Perkins; Ingemar Johansson S (LU/EAB)
> 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 
> 
> >