Re: default components versus custom components

I think the conflicts between a default component and a custom component should also be addressed. Let's say a website implements AV1, adds it as a supported payload type. There is no problem at this time because AV1 could only be a custom component. But someday, when AV1 is implemented in browsers, we need a clear strategy or API to determine whether the default AV1 component or the custom AV1 component will be used.

 
 
Best Regards,
Jianjun

On 2018/6/16, 6:00 AM, "Göran Eriksson AP" <goran.ap.eriksson@ericsson.com> wrote:

    
    
    
    
    Den 2018-06-15 23:54 skrev "Bernard Aboba" <Bernard.Aboba@microsoft.com> följande:
    
    
    
        Peter said: 
    
        
    
        "I'm persuaded by "default components" for the sake of making simple things simple, but I'm not at all persuaded by the compatibility argument.  If someone wants to make custom RTP payloads/packetizations or use SCTP instead of RTP, let them."
    
        
    
        [BA] As long as you have "default components" then custom components need only be developed when they are required.   
    
        
    
        In those cases where custom components are needed, presumably the developers understand their interoperability requirements - they know whether their custom RTP payload developed in the browser application needs to be able to talk to an equivalent custom module developed for their mobile application.
    
    
    
    [GE] +1. Same if developer use QUIC based transport solutions- the Web site developer ought to know the requirements. What we may need to consider is the ability for a web site to lock down the ability to inject custom components.

Received on Sunday, 17 June 2018 06:08:17 UTC