Re: [AVTCORE] draft-ietf-avtcore-multi-party-rtt-mix Issue 1: transport

[Christer Holmberg <[e-mail]>]

Hi,

---
    
    >>> 1) A mechanism that the mixer can use when it is revealed that the endpoint does not support proper multi-party presentation. There are functional limitations,
    >>> but it works reasonably well, especially for few parties taking turns in reasonably good order. It is specified in section 13.2 and is called "Multi-party mixing for
    >>> multi-party unaware endpoints".
    >> Why not simply call it "Multi-party mixing for single-party endpoints"?
    >
    > Maybe.
    >
    > I initially used "conference-unaware", in order to use the same term as 
    > in RFC 4353 and RFC 4579 SIP central conferencing. The most urgent 
    > applications claim that they use that framework.
    >
    > But then I realized that for our case it was more important how the 
    > media format was composed than how the multi-party session was signaled, 
    > so I started to call it "multi-party aware" and "multi-party unaware".  
    > It still has similarities with the nomenclature of the conferencing 
    > framework.
    >
    > If we were to change terms, I think it would be better with two-party 
    > endpoints, because they are made for two-party sessions. On the other 
    > hand, multi-party-aware endpoints can also handle two-party sessions.
    >
    > So the difference is really that the endpoint is unaware of the 
    > charcteristics in the media format that tells about different parties.
    >
    > What do you think?

    I am fine with whatever :)

    Regards,
  
    Christer