Subject: Re: [MEDIACTRL] MRB-PUB-2

From: "Lorenzo Miniero" <[email-masked]>
Date: Fri, 05 Jun 2009 17:42:10 +0200

Second issue: Active Mixer Sessions...
Honouring the security considerations of the mixer package,
we chose not to report the conference IDs of the active
mixers. Instead, info about all the mixers is put together
to provide a generic view on the resources usage. The info
on codecs is the same as before (so different reports for
encodings and decodings). This way, no private info would be
released, while still providing the needed data.

Are you ok with this approach, or do you think that the
report should be different and/or include
additional/different information?

Thanks,
Lorenzo and Chris

----- Original Message -----
Da : Chris Boulton <[email-masked]>
A : [email-masked]
Oggetto : [MEDIACTRL] MRB-PUB-2
Data : Fri, 05 Jun 2009 15:42:19 +0100

> MediaCtrl-ID: MRB-PUB-2
> 
> Interface Name: Publishing
> 
> Property Name: Active Mixer Sessions
> 
> Description:
> 
> Provides a representation of mixed Active RTP sessions
> (see Active RTP  Sessions for definition) that are
> occurring on a logical media server  instance. The details
> are conveyed in a list showing the number of  active mixes
> and the number of Active RTP sessions per codec type 
> involved in the mixes. The figure provided for each codec
> is split into  two parts. The first part represents the
> number of incoming Active RTP  Sessions (decoding) while
> the second part represents the outgoing Active  RTP
> sessions (encoding). The figures provide a snap shot of
> current  usage and should only be used as a guidance when
> making resource decisions.
> 
> Type: A list of the number of mixes and associated number
> of Active RTP  sessions (see earlier definition).
> 
> Example:
> 
> 5 mixes – 10/20 G711 – 6/10 H.264
> 
> 
> 
> Please provide comments on this interface property and let
> us know if it  triggers any thoughts on additional
> information that could be included  in the interface. This
> information will be used as the basis for text in  the
> next version of the draft.
> _______________________________________________ MEDIACTRL
> mailing list [email-masked]
> https://www.ietf.org/mailman/listinfo/mediactrl
> Supplemental Web Site:
> http://www.standardstrack.com/ietf/mediactrl

---

From: "MUNSON, GARY A, ATTLABS" <[email-masked]>
Date: Mon, 8 Jun 2009 16:37:03 -0400

On this one, I'm puzzled about not reporting the conference IDs to MRB
because of privacy considerations. I would think that the MRB knows or
can know that information anyway. Because when the AS requests a MS
resource for conferencing (whether Query or In-Line, whether according
to Lorenzo's conceptual model thinking or mine), I would think the AS
would pass the conference ID to the MRB as part of a request. Otherwise
call legs for the same conference wouldn't necessarily end up on the
same mixer, right?

I think there's value in having the report done by Conference ID.
Especially for sanity checking/troubleshooting,  MRB could compare its
view of what it thought the situation was according to what it had
assigned/offered (however you want to say it) to ASes, versus what the
Published view is. 

cheers,

Gary

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Lorenzo Miniero
Sent: Friday, June 05, 2009 11:42 AM
To: Chris Boulton; [email-masked]
Subject: Re: [MEDIACTRL] MRB-PUB-2

Thanks,
Lorenzo and Chris

----- Original Message -----
Da : Chris Boulton <[email-masked]>
A : [email-masked]
Oggetto : [MEDIACTRL] MRB-PUB-2
Data : Fri, 05 Jun 2009 15:42:19 +0100

> 5 mixes - 10/20 G711 - 6/10 H.264
> 
> 
> 
_______________________________________________
MEDIACTRL mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mediactrl
Supplemental Web Site:
http://www.standardstrack.com/ietf/mediactrl

---

From: Chris Boulton <[email-masked]>
Date: Mon, 08 Jun 2009 22:14:15 +0100

> call legs for the same conference wouldn't necessarily end up on the
[Chris] I am not sure that this problem is within the scope of MRB 
(others thoughts would be much appreciated).  I would imagine an MRB 
playing a role that allows a request to be serviced by an appropriate 
media server (based on capabilities/resources).  Once that conference 
mix is established by the controlling AS its job is done.  The 
correlation of new requests etc is part of the conferencing application 
logic and not really an MRB function.  An MRB certainly could provide 
such information but I would need to be convinced that this lies within 
the boundaries of an MRB and its intended functionality.

> assigned/offered (however you want to say it) to ASes, versus what the
[Chris] Isn't this more auditing at the Mixer package level?