Re: [codec] #16: Multicast?

[stephen botzko <[e-mail]>]

in-line

Stephen Botzko

On Wed, Apr 21, 2010 at 8:17 AM, Colin Perkins <[e-mail]> wrote:

> On 21 Apr 2010, at 12:20, Marshall Eubanks wrote:
>
>> On Apr 21, 2010, at 6:48 AM, Colin Perkins wrote:
>>
>>> 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.
>>>
>>>
>> It is not clear to me what supporting multicast would entail here. If this
>> is a codec over RTP, then what is to stop it from being multicast ?
>>
>
>
> Nothing. However group conferences implemented using multicast require end
> system mixing of potentially large numbers of active audio streams, whereas
> those implemented using conference bridges do the mixing in a single central
> location, and generally suppress all but one speaker. The differences in
> mixing and the number of simultaneous active streams that might be received
> potentially affect the design of the codec.
>

Conference bridges with central mixing almost always mix multiple speakers.
As you add more streams into the mix, you reduce the chance of missing onset
speech and interruptions, but raise the noise floor. So even if complexity
is not a consideration, there is value in gating the mixer (instead of
always doing a full mix-minus).

More on point, compressed domain mixing and easy detection of VAD have both
been advocated on these lists, and both simplify the large-scale mixing
problem.

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