Re: [codec] #16: Multicast?

["Christian Hoene" <[e-mail]>]

Hi,

>On 21 Apr 2010, at 10:42, codec issue tracker wrote:
>> #16: Multicast?
>> ------------------------------------
>> +----------------------------------
>> Reporter:  hoene@.                 |       Owner:
>>    Type:  enhancement             |      Status:  new
>> Priority:  trivial                 |   Milestone:
>> Component:  requirements            |     Version:
>> Severity:  Active WG Document      |    Keywords:
>> ------------------------------------
>> +----------------------------------
>> The question arrose whether the interactive CODEC MUST support
>> multicast in addition to teleconferencing.
>>
>> On 04/13/2010 11:35 AM, Christian Hoene wrote:
>>>>> P.S. On the same note, does anybody here cares about using this
>>>>> CODEC with multicast? Is there a single commercial multicast
>>>>> voice deployment? From what I've seen all multicast does is
>>>>> making IETF voice standards harder to understand or implement.
>>>>
>>>> I think that would be a mistake to ignore multicast - not because
>>>> of multicast itself, but because of Xcast (RFC 5058) which is a
>>>> promising technology to replace centralized conference bridges.
>>>
>>> Regarding multicast:
>>>
>>> I think we shall start at user requirements and scenarios.
>>> Teleconference (including mono or spatial audio) might be good
>>> starting point. Virtual environments like second live would require
>>> multicast communication, too. If the requirements of these
>>> scenarios are well understand, we can start to talk about potential
>>> solutions like IP multicast, Xcast or conference bridges.
>
>
>RTP is inherently a group communication protocol, and any codec
>designed for use with RTP should consider operation in various
>different types of group communication scenario (not just multicast).
>RFC 5117 is a good place to start when considering the different types
>of topology in which RTP is used, and the possible placement of mixing
>and switching functions which the codec will need to work with.

I have to admit that my thinking is complete different. I first start with user requirements, then look how to achieve them, and
finally consider on how to map them on existing standards - not the other way around.

Users do demand for teleconferencing, preferable at high quality (good spatial audio quality, low acoustic latency and reliable).
Thus, this is a MUST requirement.

I believe that multicast support NEEDS NOT to be particular optimized due to the following two reasons:

a) RFC5117: 4.1.3.  Per Domain Bit-Rate Adaptation

   Participants are most likely to be connected to each other with a
   heterogeneous set of paths.  This makes congestion control in a Point
   to Multipoint set problematic.  For the ASM and "relay" scenario,
   each individual sender has to adapt to the receiver with the least
   capable path.  This is no longer necessary when Media Translators,
   Mixers, or MCUs are involved, as each participant only needs to adapt
   to the slowest path within its own domain.  The Translator, Mixer, or
   MCU topologies all require their respective outgoing streams to
   adjust the bit-rate, packet-rate, etc., to adapt to the least capable
   path in each of the other domains.  That way one can avoid lowering
   the quality to the least-capable participant in all the domains at
   the cost (complexity, delay, equipment) of the Mixer or Translator.

Indeed, the CODEC SHOULD be adapted on each path to achieve best quality.

b) Multicast is used (to my best knowledge) mainly locally and not throughout the Internet, thus if we want to support global
interactive communication with a good CODEC support of MULTICAST cannot be considered as granted.

Yours respectfully,

 Christian

>--
>Colin Perkins
>http://csperkins.org/
>
>
>
>_______________________________________________
>codec mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/codec