Subject: [MEDIACTRL] Endpoint Signaling

From: Eric Burger <[email-masked]>
Date: Mon, 13 Nov 2006 23:46:53 -0500

Well, the secret is out and the mediactrl list is up and running.  It
actually has been up for a while, but I was waiting until the archive got
loaded before announcing the list was up.

Please use the IETF list address going forward.  Instructions are at the
supplemental web site, http://flyingfox.cantata.com/i-d/mediactrl

Thanks.

_______________________________________________
MEDIACTRL mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mediactrl

---

From: "Adnan Saleem" <[email-masked]>
Date: Mon, 13 Nov 2006 22:56:17 -0800

Eric,

Agreed.

However, just to put this in other words, whether the signalling 
is from something called an "AS" or an "endpoint" is up to deployment 
scenarios. We (in mediactrl) are defining a certain level of control 
functionality and behaviour of a media server. For instance, VCR controls 
and floor control require certain functionality from a media server, but 
this does not imply that the media server also provides the application
service logic, which utilizes the primitive level controls to a media
server.

I think some of the confusion may come from the way we describe the
interface to a media server, ie directly between an "AS" and "MS", whereas
by "AS" we mean application logic, and do not intend to stipulate where
this application logic may reside.

you may want to revise the wording based on the above, but I'm ok 
with what you have already written.

Adnan

-----Original Message-----
From: Eric Burger [mailto:[email-masked]] 
Sent: November 13, 2006 8:47 PM
To: [email-masked]
Subject: [MEDIACTRL] Endpoint Signaling

As I was revising the charter, I stumbled upon something related to Roni's
and Lorenzo's discussion on BFCP that relates directly to Dave Oran's
concern.  Namely,

  Shall mediactrl entertain signaling directly between the
  user endpoint and the media server?

I would offer the answer is "no."  That restriction means that if we receive
floor control commands, they will come from the application server.
Likewise, while the media server will most likely do VCR controls (or
trick-play controls, i.e., FF, REW, Pause), they will not be directly from
the end-user.

Of course, there is nothing to prevent a user endpoint from looking like an
application server, nor is there anything to prevent us from deciding that
if we do floor control, it will look like BFCP.  However, I would like to
clarify that we will NOT be working on a user-end-point to media server
protocol in mediactrl.

The language I have put into the most recent draft charter reads as follows:

   The expected deployment architecture for a media server
   in the context of mediactrl is as a server to application
   servers.  It is not expected that end user endpoints will
   have a direct signaling relationship to the media server.

Any dissent?  Speak now before I update the charter.

---

From: Lorenzo Miniero <[email-masked]>
Date: Tue, 14 Nov 2006 10:54:58 +0100

Hi Eric,

> trick-play controls, i.e., FF, REW, Pause), they will not be directly from

I absolutely agree on that, since it would actually give each 
'application' in the AS more control upon the users and resources it is 
managing.

> clarify that we will NOT be working on a user-end-point to media server

I agree, with its features the mediactrl is of much more interest to 
complex applications, that the end-points would use and refer to to take 
advantage of these features.

> Any dissent?  Speak now before I update the charter.

Ok for me.

Cheers,
Lorenzo

-- 
Lorenzo Miniero, Junior Researcher
Dipartimento di Informatica e Sistemistica
Università degli Studi di Napoli "Federico II"
Via Claudio 21 -- 80125 Napoli (Italy)
Phone: +390817683821 - Fax: +390817683816
Email: [email-masked]

-- 
Il messaggio e' stato analizzato alla ricerca di virus o
contenuti pericolosi da MailScanner, ed e'
risultato non infetto.

---

From: "Even, Roni" <[email-masked]>
Date: Wed, 15 Nov 2006 13:45:38 +0200

Eric,
There is a different between signaling and control. 
End to end control make sense and we have it also in RTCP like video
fast update and flow (Rate) control.
Floor control is not signaling
Roni

> Sent: Tuesday, November 14, 2006 6:47 AM
> To: [email-masked]
> Of course, there is nothing to prevent a user endpoint from looking
like
> an
************************************************************************
**
> **********
> This footnote confirms that this email message has been scanned by
> PineApp Mail-SeCure for the presence of malicious code, vandals &
computer
> viruses.
************************************************************************
**
> **********

---

From: "Tim Melanchuk" <[email-masked]>
Date: Wed, 15 Nov 2006 10:56:26 -0800

i agree with roni. there is control in rtcp and also (implicitly)
within rtp in terms of dtmf. for example, dtmf can barge
prompts, acting as a control, without app server intervention.
a similar model can be used for vcr controls.

timm

---

From: Lorenzo Miniero <[email-masked]>
Date: Thu, 16 Nov 2006 10:56:23 +0100

Hi Tim,

> a similar model can be used for vcr controls.

Though I agree floor control is not signaling, it is not exclusively 
media control either. Its logical role fits best coupled with the AS, 
considering that this way we could reuse many mechanisms already present 
in existing Media Server Control paradigms to orchestrate the media 
flowing on each leg. Besides, I keep on insisting on the possible 
eterogeneous nature of the resources associated with floors. You surely 
know, for example, that in BFCP a single request regarding two separate 
floors is not accepted until both floors are: so, a request involving 
access to both text and audio could give problems if coupling floor 
control with the MS. Such a problem would not exist in coupling the FCS 
with the AS, since the AS is aware of all the available set of resources 
and the related floor associations, and according to the floor status 
changes can opportunely orchestrate the right Server: in the case of the 
example, the Media Server to grant audio (by means of what will come out 
from this WG), and whatever other server will be used for chat/IM to 
grant access to text (which is of no interest to us as MediaCtrl, but is 
for applications in the AS).

Cheers,
Lorenzo

> On 11/15/06, *Even, Roni* <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Eric,
>     > From: Eric Burger [mailto:[email-masked]
>     <mailto:[email-masked]>]
>     > To: [email-masked] <mailto:[email-masked]>
>     > I would offer the answer is "no."  That restriction means that
>     if we
>     > receive
>     > trick-play controls, i.e., FF, REW, Pause), they will not be
>     directly
>     from
>     > the end-user.
>     >
>     > application server, nor is there anything to prevent us from
>     deciding
>     that
>     > if we do floor control, it will look like BFCP.  However, I
>     would like
>     to
>     > [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>
> ------------------------------------------------------------------------
>

---

From: "Tim Melanchuk" <[email-masked]>
Date: Fri, 17 Nov 2006 10:48:10 -0800

hi lorenzo,

i wasn't specifically addressing the bfcp issue (which is the
subject of another thread), but rather the general concept of
allowing some direct endpoint "control".

from a bfcp perspective, i tend to agree with chris boulton,
that the bfcp server is a logical role that could be co-located
with either the ms or app server. locating it with the ms could
lead to simpler sdp offer/answer exchanges. locating it at the
app server requires the app server to do a lot more sdp
manipulation (which some servers may be doing anyway).

cheers,
timm

---

From: "Even, Roni" <[email-masked]>
Date: Sun, 19 Nov 2006 17:13:09 +0200

Lorenzo,
I think that we need to differentiate between the FCS who receive the BFCP message and the granting decision. This is also defined in BFCP. 
The AS will tell the MS if to grant the floor when requested or to pass the request to the AS who will make the decision.
Roni 

> From: Lorenzo Miniero [mailto:[email-masked]]
> Sent: Thursday, November 16, 2006 11:56 AM
> To: [email-masked]
> Subject: Re: [MEDIACTRL] Endpoint Signaling
> 
> Hi Tim,
> 
> >     > As I was revising the charter, I stumbled upon something related
> to
> >     Roni's
> >     > The language I have put into the most recent draft charter reads
> as
> >     > follows:
> >     >
> **************************************************************************
> **********
> PineApp Mail-SeCure for the presence of malicious code, vandals & computer
> viruses.
> **************************************************************************
> **********
> 
>

---

From: Lorenzo Miniero <[email-masked]>
Date: Sun, 19 Nov 2006 19:23:11 +0100

Hi Roni,

> The AS will tell the MS if to grant the floor when requested or to pass the request to the AS who will make the decision.

Actually, it is only specified that the *policies* the FCS will follow 
to grant floors are outside the scope of the BFCP: this suggests the 
idea that the actual decision will be taken by the FCS anyway, which 
makes sense considering the FCS could easily manage all the request 
queues directly, and knows who's releasing floors and when. But your 
consideration is right, this is not explicit.

Cheers,
Lorenzo

>>>     > floor control commands, they will come from the application
>>>       
>> server.
>>     
>>>     > Of course, there is nothing to prevent a user endpoint from
>>>       
>> looking
>>     
>>>     like
>>>     > an