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

[Magnus Westerlund <[e-mail]>]

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 [phone]
Torshamsgatan 23           | Fax   [phone]
S-164 80 Stockholm, Sweden | mailto: [e-mail]



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
[e-mail]
https://www1.ietf.org/mailman/listinfo/avt