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

[Tom Taylor <[e-mail]>]

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:

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

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