Re: [codec] #16: Multicast?

[stephen botzko <[e-mail]>]

Hi Christian

Teleconferencing standards (both in the ITU-T and the IETF) support
multicast..  It would be awkward if the codec decision was somehow coupled
to the transport, and (IMHO) architecturally wrong.

While it is probably true that multicast is more likely to be used on
enterprise networks, I don't see that as terribly relevant.

I see no technical reason to NEED NOT multicast.

Regards,
Stephen Botzko

On Wed, Apr 21, 2010 at 7:14 AM, Christian Hoene <[e-mail]>wrote:

> 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
>
> _______________________________________________
> codec mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/codec
>