Subject: RE: [AVT] VoIP Shim for RTP Payload Formats

From: "Desineni, Harikishan" <[email-masked]>
Date: Wed, 6 Sep 2006 12:56:50 -0700

I am under the impression that in-band signaling inside payload header
is an accepted concept in this community. Other than AMR Payload format,
there is another payload format which is trying to use this concept.
Once such work is the use of MBS field in Sec 5.2
draft-ietf-avt-rtp-g729-scal-wb-ext-07.txt

"MBS (4 bits): maximum bit rate supported.  Indicates a maximum bit
 rate to the encoder at the site of the receiver of this payload."

I think that RTCP (AVPF) has a similar message which can be used to
convey maximum bit rate to the encoder at the remote end.

I'd like to infer the following statements from the reference to the
above work in RTP and RTCP:

1) In-band signaling using RTP payload header is an allowed/accepted
concept.
2) RTCP signaling may also exist to carry the same information.

In certain scenarios (MOH, voice mail), RTCP signaling is unavoidable.
One will end up defining methods to carry the same information using
both in-band RTP and RTCP based feedback.

-----Original Message-----
From: Colin Perkins [mailto:[email-masked]] 
Sent: Friday, August 25, 2006 7:30 AM
To: Ingemar Johansson S ((LU/EAB))
Cc: [email-masked]
Subject: Re: [AVT] VoIP Shim for RTP Payload Formats

> 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.

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

Colin

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

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

---

From: "Even, Roni" <[email-masked]>
Date: Thu, 7 Sep 2006 09:48:03 +0300

Hi,
I want to put my 2 cents on in band signaling.

I would agree that in-band signaling will work I point to point call.
Care should be taken for the following cases

1. Unidirectional media.
2. Multicast
3. Multipoint cases

That is why I think that capabilities should be in the signaling path
In the media path you can have changes which are of a temporary nature
like rate change commands for video or audio or indications.

I think you suggest a capability describing a more permanent state which
should be in SDP.

Roni Even    

> From: Desineni, Harikishan [mailto:[email-masked]]
> Sent: Wednesday, September 06, 2006 10:57 PM
> To: Colin Perkins; Ingemar Johansson S ((LU/EAB))
> Cc: [email-masked]
> Subject: RE: [AVT] VoIP Shim for RTP Payload Formats
> 
>

---

From: "Ingemar Johansson S \(LU/EAB\)" <[email-masked]>
Date: Mon, 11 Sep 2006 09:20:51 +0200

Hi

I agree that capabilities should be exhanged (eg. SDP) in order to
decide if Shim should be allowed. 
The main application is point to point communication.
Of the cases below I belive that in case 1 and 2 Shim should be avoided.
In case 3 it may be possible to use Shim if a conference bridge can do
policing on the Shim information.

Ingemar

> From: Even, Roni [mailto:[email-masked]] 
> Sent: den 7 september 2006 08:48
> To: Desineni, Harikishan; Colin Perkins; Ingemar Johansson S (LU/EAB)
> Cc: [email-masked]
> That is why I think that capabilities should be in the 
> signaling path In the media path you can have changes which 
> are of a temporary nature like rate change commands for video 
> or audio or indications.
> 
> I think you suggest a capability describing a more permanent 
> state which should be in SDP.
> 
> Roni Even    
>

---

From: "Even, Roni" <[email-masked]>
Date: Thu, 14 Sep 2006 18:47:36 +0300

Hi,
I think that I was not clear about capabilities.
What I meant was not that SDP should be used to find if Shim should be
used but I said that Shim should not be used to replace SDP by signaling
end to end capabilities that are to be conveyed in SDP. The extreme case
is to signal all optional parameters defined in SDP via in-band
signaling, the example for G.729 looked to me like SDP and not in-band
Roni

> From: Ingemar Johansson S (LU/EAB)
> [mailto:[email-masked]]
> Sent: Monday, September 11, 2006 10:21 AM
> To: Even, Roni; Desineni, Harikishan; Colin Perkins
> Cc: [email-masked]

---

From: "Desineni, Harikishan" <[email-masked]>
Date: Thu, 14 Sep 2006 16:25:16 -0700

"mbs" in SDP is to communicate the max rate (parameter) at the time of
call setup (offer/answer). During the call, max bit rate ("mbs") updates
can be communicated using in-band signaling. At the time of call set up,
"mbs" is serving as a parameter. During the call, "mbs" in the payload
header is acting as a request to the other end.

In this scenario, using in-band looks like a better approach than
updating SDP. SDP update would require parsing the entire SDP and
identifying the modified value, which doesn't look like a nice
implementation and may not be as fast as in-band signaling. In-band
signaling in offer/answer sessions is definitely a good approach if the
information being carried is not part of SDP.

I agree with you that in-band signaling shall not be used as a back door
to update any attribute values that might have been communicated via SDP
during call setup. In theory, a receiver can use in-band signaling to
carry whatever feedback information RTCP can carry. I prefer to see
in-band signaling as a means to provide quick feedback of delay
sensitive information to the remote end (sender) in unicast
configurations.

As pointed out by Colin, using SHIM is like proposing a new RTP profile,
which will introduce profile negotiation issues which are being worked
out in MMUSIC. If this approach is chosen, then I prefer this one to
evolve as a new RTP profile optimized for point to point conversational
multi-media services. This would make SHIMs more generic for use by
other media types, and a place holder for other RTP/RTCP optimizations
applicable in point to point topology.

- - - - - - - - - - - - - - - - - -
Harikishan Desineni
Qualcomm Inc.,
mailto:[email-masked]

> Sent: Thursday, September 14, 2006 8:48 AM
> To: Ingemar Johansson S (LU/EAB); Desineni, Harikishan; Colin Perkins
> Cc: [email-masked]

---

From: "Ingemar Johansson S \(LU/EAB\)" <[email-masked]>
Date: Fri, 15 Sep 2006 09:06:54 +0200

Hi

As Mr Desiniemi pointed out the purpose of the inband signaling (e.g
Shim) is to transmit delay sensitive information, the purpose is not to
replace SDP. 
SDP will be used to do session negotiation, among that it should be
possible to negotiate if Shim inband signaling should be allowed/used
during the session.  

The aproach that is proposed in connection with the Shim draft is to, in
its simplest form, to propose two payload types, for example 
PT=97 : AMR 
PT=98 : AMR with Shim
It is then possible for the other end to accept one or both of the
proposed PT's. 

There is a possibility that a new session negotiation might take place
for instance at an handover from a HSPA network to a GERAN-EDGE network,
however it is very possible that the applications won't know that this
happen (the radio interface might for instance be connected to a laptop
via USB). Also if one use SDP it very easily becomes quite large
messages even though compression is used. The word from the "network"
guys that I ask is "don't count on session re-negotiation" in the middle
of a session. One exception is of course if one add a new component or
switch to a 3party call.

As for a completely new RTP profile, it is possible that this is the way
to go in the long perspective but this seems to be something that may
take some time before it is settled. 
The Shim proposal is something that will hopefully be added to the MTSI
(Multimedia Telephony Service over IMS) standardization in 3GPP and the
time perspective is such that it should preferrably be settled by the
end of this year.  

Regards
Ingemar

> Sent: den 15 september 2006 01:25
> To: Even, Roni; Ingemar Johansson S (LU/EAB); Colin Perkins
> Cc: [email-masked]
> "mbs" in SDP is to communicate the max rate (parameter) at 
> the time of call setup (offer/answer). During the call, max 
> bit rate ("mbs") updates can be communicated using in-band 
> signaling. At the time of call set up, "mbs" is serving as a 
> parameter. During the call, "mbs" in the payload header is 
> acting as a request to the other end.
> 
> In this scenario, using in-band looks like a better approach 
> than updating SDP. SDP update would require parsing the 
> entire SDP and identifying the modified value, which doesn't 
> look like a nice implementation and may not be as fast as 
> in-band signaling. In-band signaling in offer/answer sessions 
> is definitely a good approach if the information being 
> carried is not part of SDP.
> 
> I agree with you that in-band signaling shall not be used as 
> a back door to update any attribute values that might have 
> been communicated via SDP during call setup. In theory, a 
> receiver can use in-band signaling to carry whatever feedback 
> information RTCP can carry. I prefer to see in-band signaling 
> as a means to provide quick feedback of delay sensitive 
> information to the remote end (sender) in unicast configurations.
> 
> As pointed out by Colin, using SHIM is like proposing a new 
> RTP profile, which will introduce profile negotiation issues 
> which are being worked out in MMUSIC. If this approach is 
> chosen, then I prefer this one to evolve as a new RTP profile 
> optimized for point to point conversational multi-media 
> services. This would make SHIMs more generic for use by other 
> media types, and a place holder for other RTP/RTCP 
> optimizations applicable in point to point topology.
> 
> 
> > > In case 3 it may be possible to use Shim if a conference 
> bridge can
> do
> signaling 
> > > > path In the media path you can have changes which are of a 
> > > > temporary nature like rate change commands for video or 
> audio or 
> > > > indications.
> > > >
> > > > I think you suggest a capability describing a more 
> permanent state 
> > > > which should be in SDP.
> > > >
> > > > Roni Even
> > > >
> > > > > is an accepted concept in this community. Other than 
> AMR Payload
> > > > format,
> > > > > I think that RTCP (AVPF) has a similar message which 
> can be used
> > to
> > > > > Audio/Video Transport Working Group [email-masked] 
> > > > > Audio/Video Transport Working Group [email-masked]

---

From: "Desineni, Harikishan" <[email-masked]>
Date: Fri, 15 Sep 2006 10:06:07 -0700

> It is then possible for the other end to accept one or both of the

To use 98 as stated in the above example, the SHIM has to be part of
payload header. It would require update to the AMR payload format
specification. It is not valid to use 98 as shown in your example
without updating AMR payload format.
 
> take some time before it is settled.

Proposing generic SHIM using RTP header extensions seems like the
easiest short term approach to solve this problem. This way, you'll not
have backward compatibility issues and no need to update payload format
spec. Other codecs can also use this approach without the need to update
their payload format specification.

New RTP profile optimized for point to point conversational services can
be a long term solution. Such a profile can be used to improve lot of
things in RTP/RTCP for p2p conversational services.

---

From: Colin Perkins <[email-masked]>
Date: Mon, 18 Sep 2006 10:42:01 +0100

On 15 Sep 2006, at 18:06, Desineni, Harikishan wrote:
...
> without updating AMR payload format.

...and every other payload format you want to use the shim with. This  
approach is completely impractical if you want to use the shim with  
arbitrary payload formats.

>> take some time before it is settled.

The approach you propose in the draft *requires* you to define a new  
profile. That's the only way to extend the RTP header to insert the  
shim in a way that applies to any payload format.

The alternative is to use an RTP header extension, accepting the  
additional overhead.

Colin

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 18 Sep 2006 14:20:35 +0200

Hi,

I would like to clarify a few things here.

> arbitrary payload formats.

I think you misunderstand what Ingemar is actually tries to tell you. 
You need to consider RFC 2198 but with a twist. The SHIM can actually be 
a payload format which consist of the SHIM header and the data part. The 
data part contains any other payload format. In RFC 2198 the actual 
content is indicated by the payload type field part of the RFC 2198 
payload headers. If one likes to save bits one can do the trick and 
remove the PT field for the carried data and instead indicated it in the 
signalling path. In other words one does a dynamic binding in SDP that 
PT 98 is the SHIM payload and its data part contains PT=97.

This has been done before, by 3GPP in TS 26.234 when defining a crypto 
payload used for DRM (see Annex K) and in the RTP payload format for 
retransmission (RFC 4588) (the "apt" parameter).

So the choice when indicating the original payload type carried in these 
wrapper payload formats is between a field in the header or dynamic 
bindings. 7 bits vs a doubling of the needed payload type values.

Maybe using SHIM has been misleading, and calling it a wrapper would 
have made you understand it better.

> The alternative is to use an RTP header extension, accepting the  

So I would not say that it is the only way. The proposed mechanism is 
pragmatic (as it doesn't change the RTP header, uses minimal amount of 
bytes, can be intermittent used, and can be quickly specified) but not 
the best choice for the current RTP architecture.

Cheers

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]

---

From: Colin Perkins <[email-masked]>
Date: Mon, 18 Sep 2006 13:55:58 +0100

On 18 Sep 2006, at 13:20, Magnus Westerlund wrote:
>> ...and every other payload format you want to use the shim with.  
>> This  approach is completely impractical if you want to use the  
>> shim with  arbitrary payload formats.
>
> I think you misunderstand what Ingemar is actually tries to tell  
> you. You need to consider RFC 2198 but with a twist. The SHIM can  
> actually be a payload format which consist of the SHIM header and  
> the data part. The data part contains any other payload format. In  
> RFC 2198 the actual content is indicated by the payload type field  
> part of the RFC 2198 payload headers. If one likes to save bits one  
> can do the trick and remove the PT field for the carried data and  
> instead indicated it in the signalling path. In other words one  
> does a dynamic binding in SDP that PT 98 is the SHIM payload and  
> its data part contains PT=97.
>
> This has been done before, by 3GPP in TS 26.234 when defining a  
> crypto payload used for DRM (see Annex K) and in the RTP payload  
> format for retransmission (RFC 4588) (the "apt" parameter).

Sure, that would be an alternative design, although it's not what is  
defined in the draft under discussion, and doesn't fit the RTP  
architecture any better.

Colin

---

From: "Ingemar Johansson S \(LU/EAB\)" <[email-masked]>
Date: Tue, 19 Sep 2006 10:35:16 +0200

Hi

The situation in 3GPP is that for the Voice part of the MTSI
standardization in 3GPP there will be will be two speech codecs
mandated, namely AMR-NB and AMR-WB, both employ the same payload format
(RFC3267). The intention is that the Shim inband signaling should be
used in connection with this standardized voice service. In this view I
fail to see any interoperability problems as it is a service specified
in 3GPP.
A more thorough description of the Shim inband signaling and how it is
used in an adaptive schema is available at
ftp://ftp.3gpp.org/TSG_SA/WG4_CODEC/TSGS4_40/Docs/S4-060451.zip

My view is that inband signaling using Shim and different payload types
to distinguish between AMR and AMR+Shim is the simplest solution to a
fairly simple problem formulation (the need to adapt to changing radio
condictions in current and future radio access). The solution is not
totally according to the schoolbook and it does not comply with the
established RTP arcitecture but as Magnus points out similar tricks have
been employed earlier.

Other more advanced methods such as dedicated inband flows exist and
have their potential benefits but this is subject to a workeffort that
may take a long time and beyond the scope of the current 3GPP
standardization.

Ingemar

> Sent: den 18 september 2006 14:56
> To: Magnus Westerlund (KI/EAB)
> Cc: Ingemar Johansson S (LU/EAB); Even, Roni; [email-masked]
> >> This  approach is completely impractical if you want to 
> use the shim 
> >> with  arbitrary payload formats.
> >
> > You need to consider RFC 2198 but with a twist. The SHIM 
> can actually 
> > be a payload format which consist of the SHIM header and the data 
> > part. The data part contains any other payload format. In 
> RFC 2198 the 
> > actual content is indicated by the payload type field part 
> of the RFC 
> > 2198 payload headers. If one likes to save bits one can do 
> the trick 
> > and remove the PT field for the carried data and instead 
> indicated it 
> > in the signalling path. In other words one does a dynamic 
> binding in 
> > SDP that PT 98 is the SHIM payload and its data part contains PT=97.
> >
> Sure, that would be an alternative design, although it's not 
> what is defined in the draft under discussion, and doesn't 
> fit the RTP architecture any better.
> 
> Colin
> 
>

---

From: "Even, Roni" <[email-masked]>
Date: Tue, 19 Sep 2006 11:53:26 +0300

Hi,
>From this email it looks to me that in order to have a fast solution
that will not break any architecture would be to have a new payload that
updates RFC3267 and adds control packets with the audio frames, similar
to video codecs like H.264. 
Anyhow special care should be taken to back-channel in uni-direction and
for multipoint behavior.
Roni Even

> Sent: Tuesday, September 19, 2006 11:35 AM
> To: Colin Perkins; Magnus Westerlund (KI/EAB)
> Cc: Even, Roni; [email-masked]

---

From: Colin Perkins <[email-masked]>
Date: Tue, 19 Sep 2006 09:57:26 +0100

Agreed - I see no need what-so-ever for the shim, if that is your  
requirement. The AMR payload format is in the process of being  
updated - add the control as part of that update.

Colin

---

From: "Ingemar Johansson S \(LU/EAB\)" <[email-masked]>
Date: Wed, 20 Sep 2006 14:55:46 +0200

Hi

I suspect that I have been abit AMR oriented in my discussion. 
However the problem that the proposed draft claims to solve is not
unique to AMR, therefore it is not a good solution to include it in the
AMR payload format.

Ingemar 

> Sent: den 19 september 2006 10:57
> To: Even, Roni
> Cc: Ingemar Johansson S (LU/EAB); Magnus Westerlund (KI/EAB); 
> [email-masked]
> Agreed - I see no need what-so-ever for the shim, if that is 
> your requirement. The AMR payload format is in the process of 
> being updated - add the control as part of that update.
> 
> Colin
> 
> 
> > that will not break any architecture would be to have a new payload 
> > that updates RFC3267 and adds control packets with the 
> audio frames, 
> > similar to video codecs like H.264.
> > Anyhow special care should be taken to back-channel in uni- 
> direction 
> > and for multipoint behavior.
> > Roni Even
> >
> >> used in connection with this standardized voice service. 
> In this view
> > I
> >> fail to see any interoperability problems as it is a service 
> >> specified in 3GPP.
> >> A more thorough description of the Shim inband signaling 
> and how it 
> >> is used in an adaptive schema is available at 
> >> fairly simple problem formulation (the need to adapt to changing 
> >> radio condictions in current and future radio access). The 
> solution 
> >> is not totally according to the schoolbook and it does not comply 
> >> with the established RTP arcitecture but as Magnus points 
> out similar 
> >> tricks
> > have
> >> been employed earlier.
> >>
> >> have their potential benefits but this is subject to a workeffort 
> >> that may take a long time and beyond the scope of the current 3GPP 
> >> standardization.
> >>
> >> Ingemar
> >>
> >>