Re: [codec] #16: Multicast?

[Colin Perkins <[e-mail]>]

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.

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