Subject: RE: [Sipping] conf: comments on draft-even-sipping-media-policy-r equirements-00

From: "Even, Roni" <[email-masked]>
Date: Sun, 23 Mar 2003 13:58:11 +0200

Eric,
Thanks for the comments.
I appreciate the feedback since part of it was written based on my
understanding of multimedia conferencing and the remarks will help me to
have it clearer in the next revision. I agree that section 8 needs to be
better written.
My other responses are in line

Roni

> -----Original Message-----
> From: Eric Burger [mailto:[email-masked]]
> Sent: Thursday, March 20, 2003 9:44 PM
> To: Sipping (E-mail)
> Subject: [Sipping] conf: comments on 
> draft-even-sipping-media-policy-requirements-00
> 
> 
> Requirements in general:
> I don't get the subject of the requirements.  Is the subject 
> (in the grammatical sense) CPCP (protocol capabilities), the 
> identified party (the participant or mixer), or something else?

I agree that it should be more clear. In general the texts says "All the
requirements are based on having a privilege mechanism that
   authorizes users to access and manipulate the media policy data." 
The requirements are for the Media Policy which is part of CPCP. The
requirements can be seen also from the participant size since being able to
manipulate the media policy is subject to privilege level (one of which can
be that the participant cannot do any manipulations or even be aware that
they exist)

> 
> For example in REQ-GP1, is the *participant* the party that 
> MUST be able to specify its own topology?  Here's a nasty 
> result: a company hosts an earnings announcement conference 
> call.  Two analysts create a sidebar and get private 
> communications service paid for by the host.  I don't think 
> the participant MUST be able to specify topology, at all.  
> Alternately, is the *protocol* the party that MUST be ABLE to 
> specify topologies?
I can change the text, but again it is implied by the general sentence. 

> 
> Likewise, in REQ-GP3, does this say that the *protocol* MUST 
> allow the SPECIFICATION of the number of streams, or does 
> this say that the *mixer* must support dynamic active talker sizing?

I meant the protocol. 
> 
> REQ-GP4 is unrealistic and over the top.
I disagree, there are products that can send each participant a different
video stream by switching and even mix different layouts.

> 
> 
> The Security Considerations is VERY light.  It essentially 
> says, "bad things can happen, but we're not going to do 
> anything about it."
>
The media policy are just the data manipulations, the CPCP which is
addressed in other document is the actual transport and the security section
is more a security requirement for the CPCP.
 
> 
> I don't understand any of Section 8.  It desperately needs 
> examples.  I'm still not convinced of the need for 
> arbitrarily complex, *participant-driven* topology 
> description and manipulation.
> 
> 
> Section 8.1:
> What on Earth is LastLoudest?  What is the "audio mix set 
> before the current one"?  Over what time period?  Is this 
> continuous?  How often does it get updated?
The Lastloudest is the loudest speaker in the previous mix, this operation
is to buffer the loudest speaker when a new speaker becomes the loudest. It
is used for example in video conferencing to create a conference that is
showing to every one the loudest speaker and the loudest speaker will see
the previous loudest speaker. As for the rate of change of active speaker,
the conferencing bridges are using some parameters that specify the minimum
time that some has to be loudest before becoming the loudest speaker (also
known as cough delay - so that clearing your throat will not cause a
switch), the other parameter is minimum time that active speaker is viewed
before a switch can occur.

> 
> Does Not(Qualifier) result in a set?  E.g., in a conference 
> with more than 2 participants, Not(LastLoudest) results in 
> more than one stream.
> 
That is true, but in the example we had 4 input streams that were the result
from the mixer. three of them had the loudest speaker as a contributor and
only one did not. I will clarify the text
> 
> Section 8.3:
> What is the use case for LoudestSpeaker(N), where N != 1?  I 
> would offer that if the use case is, "I will construct a mix 
> of the three loudest talkers by doing 
An example is Not (LoudestSpeaker(2)) - will select the stream that does not
include the second loudest speaker as a contributing source.

> Mix(LoudestSpeaker(1),LoudestSpeaker(2),LoudestSpeaker(3))", 
> you will have exactly zero implementations.  That is very 
> hard to do.  Moreover, I don't know anyone that is interested 
> in, "Please play for me the 6th loudest speaker."

This is more important for video. If I am using a tiled display I want the
video of  loudest speaker in sub-window1, the video from the second loudest
speaker in sub window 2 and so on.
> 
> I would STRONGLY suggest against using numerical table 
> numbers to describe VideoLayout.  That's begging for mistakes 
> an non-interoperable implementations.
I have no problem there - by using mime types for layout I still think that
we will need to explain and draw the actual layout.

> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use [email-masked] for questions on current sip
> Use [email-masked] for new developments of core SIP
> 
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP