Re: [codec] #16: Multicast?

[Marshall Eubanks <[e-mail]>]

On Apr 21, 2010, at 8:17 AM, Colin Perkins 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.
>

Yes, I can see that. However, this seems to be not so much a function  
of the transport protocol as on the desired use - a distributed  
conference or a large scale meeting with many simultaneous active  
streams (such as the old Access Grid) is likely to have the same  
issues whether the transport is unicast or multicast or P2P.

At any rate, I would regard multicast support as a SHOULD.

Regards
Marshall



> -- 
> Colin Perkins
> http://csperkins.org/
>
>
>
>