Subject: [AVT] The RTP payload format for multichannel codecs's signalling problem

From: Magnus Westerlund <[email-masked]>
Date: Thu, 05 Feb 2004 13:55:40 +0100

Hi,

Colin raised in Minneapolis a concern regarding the channel signalling 
for the AMR-WB+ payload format. The AMR-WB+ codec has both mono and 
stereo modes. On a codec level the difference is detected based on the 
frame type (FT) indicator for each frame. It is technical possible to 
switch between modes, but it does not provide as good switching 
performance as between the classic AMR-WB mono modes. However this codec 
"internal" or inband information about channels, modes etc. creates 
problem on RTP level and for the signalling. The problems described here 
is not limited to the AMR-WB+ codec, but does also effect other channels 
with internal signalling for different channel configuration.

The signalling problem is that the current practice of defining a MIME 
type and parameters and include them in SDP is not really capable of 
expressing the codecs capabilities in a good way. As it looks now, each 
declared payload type (PT) can only mean one channel configuration plus 
other parameter configuration.

This has not been a problem as long as one uses the PT field for its 
intended usage to the fully, i.e. having codec, packetization and all 
parameters being encoded in the PT: For example a stereo 16-bit PCM 
encoded audio stream is easy to describe with a MIME type and a couple 
of parameters: L16, frequency=44000, channels=2. Using the PT as 
intended also has the advantage of simplifying payload design, having 
the information explicit in the RTP header (thus avoiding per payload 
format special investigation for demultiplexing). However with the 
payload inband signalling of this information, it gets concealed within 
the payload.

This results in that declarative explicitness is diminished, and creates 
problem in cases of negotiation, like for SIP using Offer/Answer. For 
example, one possible solution for AMR-WB+ could be to declare a single 
payload type, which is always declared as being stereo. Thus expressing 
the full span of the codec capabilities. However if one only intends to 
use mono modes, this can't be expressed in this solution. It also forces 
a receiver application to set up resources beyond the what is really 
needed.

To maintain the declarative explicitness and uses the available 
mechanisms it will mean that one will need to declare different PTs for 
each channel configuration. Which would mean that an AMR-WB declaration 
possibly using both mono and stereo would look like this in SDP:

m=audio 49120 RTP/AVP 98 99
a=rtpmap:98 AMR-WB+/96000/1
a=fmtp:98 interleaving=30
 a=rtpmap:99 AMR-WB+/96000/2
a=fmtp:99 interleaving=30

However I would also like to point out that using too many PTs are not 
also not advisable, especially in regards to mechanisms like RTP 
retransmission that requires you to double the number of PTs used. 
However this should not be a concern unless we start using 10 or more 
PTs per codec.

So which alternative is better in your opinion, or do you have another 
proposal on how to solve the problem?

Best Regards

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]

This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you.

E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof.

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

---

From: Tom Taylor <[email-masked]>
Date: Thu, 05 Feb 2004 13:35:23 -0500

We have a similar problem with distinguishing between audio, voice-band data (high 
speed and low speed), voice-band text, and voice-band FAX.  Each of these requires 
a different combination of treatments in terms of echo cancellor operation, 
silence suppression, and jitter buffer operation.

Magnus Westerlund wrote:

> This communication is confidential and intended solely for the 
> addressee(s). Any unauthorized review, use, disclosure or distribution 
> is prohibited. If you believe this message has been sent to you in 
> error, please notify the sender by replying to this transmission and 
> delete the message without disclosing it. Thank you.
> 
> E-mail including attachments is susceptible to data corruption, 
> interruption, unauthorized amendment, tampering and viruses, and we only 
> send and receive e-mails on the basis that we are not liable for any 
> such corruption, interception, amendment, tampering or viruses or any 
> consequences thereof.
> 
>

---

From: Ross Finlayson <[email-masked]>
Date: Thu, 05 Feb 2004 14:04:37 -0800

It seems to me that for any codec that carries channel etc. parameters 
inband - and allows these parameters to change 'on the fly' - there is an 
implicit assumption that each receiver should be able to handle all 
possible settings of these inband parameters.  So, given this, your first 
proposed solution seems to make the most sense: Declare the AMR-WB+ RTP 
payload type to be for stereo, even though all frames within such a stream 
might actually turn out to be mono.

	Ross.

---

From: "Arnoud van Wijk" <[email-masked]>
Date: Fri, 6 Feb 2004 13:15:56 +0100

For voice band text, I asume you mean V21 and V18 and Boudot and other text
telephone protocols?

Greetz

Arnoud

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Tom Taylor
Sent: donderdag 5 februari 2004 19:35
To: Magnus Westerlund
Cc: [email-masked]
Subject: Re: [AVT] The RTP payload format for multichannel codecs's
signalling problem

We have a similar problem with distinguishing between audio, voice-band data
(high 
speed and low speed), voice-band text, and voice-band FAX.  Each of these
requires 
a different combination of treatments in terms of echo cancellor operation, 
silence suppression, and jitter buffer operation.

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 09 Feb 2004 13:28:01 +0100

Hi Tom,

The problem you describe has what I understand solely to do with what 
you use a established media stream. However the problem I discuss has to 
do more directly with the codecs capabilities. If a encoder has stereo 
and mono capabilities and can switch between them, what is necessary to 
signal. For my problem there are certain configuration information that 
needs to be distributed outside of the encoder to decoder chain, this 
primarily being the receivers playback facilities, so that they are 
capable of handling both outputs from the decoder.

So I don't think the problems are that similar. My problem is in direct 
relation to properties of the codec, while your problem is in relation 
the usage.

Cheers

Magnus

Magnus Westerlund

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 10 Feb 2004 17:04:01 +0100

Hi Ross,

I don't think that is a good solution due to that if one is only capable 
of handling mono playback, then one might refuse to use this 
functionality, although one would in fact be able to support it. 
Therefore it seems rather important to be able to downgrade a channel 
setup from maximum to a small set. For a more critical example one might 
not support 6+1 channel, however one is interested of using 2 channels.

Secondly, I don't know if the set of possible channels is obvious what 
requires less capability between all possible configuration. Is a 
quadraphonic setup less or more than a L+R, Center and Surround setup? 
Having explicit declaration of all used channel modes avoid these problems.

Cheers

Magnus

-- 

Magnus Westerlund

---

From: Ross Finlayson <[email-masked]>
Date: Tue, 10 Feb 2004 15:29:14 -0800

>>inband - and allows these parameters to change 'on the fly' - there is
>>an implicit assumption that each receiver should be able to handle all 
>>possible settings of these inband parameters.  So, given this, your
>>first proposed solution seems to make the most sense: Declare the AMR-WB+ 
>>RTP payload type to be for stereo, even though all frames within such a
>>stream might actually turn out to be mono.
>functionality, although one would in fact be able to support it. Therefore 
>it seems rather important to be able to downgrade a channel setup from 
>maximum to a small set. For a more critical example one might not support 
>6+1 channel, however one is interested of using 2 channels.
>

Magnus,

That's true - however, explicitly declaring (in the SDP) which channel 
modes are intended to be used leads to the question of what should a 
receiver do if it later receives a stream with inband parameters that 
violate the modes that were declared earlier.  E.g., if it was declared 
that only mono should be sent, then what should a receiver do if it later 
ends up receiving stereo?

Note, of course, that this is only an issue for those payload formats where 
channel parameters are carried inband.  If you're going to allow - for such 
payload formats - less than the complete channel functionality to be 
declared in advance, then the payload format specification needs to say 
*something* about what a receiver should do it it receives data with 
different functionality.  Even saying "the receivers actions are undefined" 
in this case is better than saying nothing :-)

         Ross.