[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [AVT] The RTP payload format for multichannel codecs's signallingproblem
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 +46 8 4048287
Torshamsgatan 23 | Fax +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
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
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt
_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt