Subject: [MEDIACTRL] Comments on draft-dolly-mediactrl-requirements-00

From: Diego B <[email-masked]>
Date: Tue, 17 Jul 2007 01:02:13 +0300

Hi;
Here are my comments regarding this first draft.

This draft is on the right track for adoption as a MEDIACTRL working 
group draft,
but I have some concerns that should be addressed before adoption.

I found the document and the requirement "very" conference oriented
while the other media services (IVR, announcements, transcoding, .. ) 
are mentioned
in a more general and non specific way. Conference may be the most 
complex or important "customer"
for this protocol, but I think this document must expose the requirement 
for all media service.

========
1- Introduction
The interest for this protocol, as described in the second paragraph, is 
not just for Conference servers or Application Servers
acting as focus.... . There is also interests in IVR and IVVR, 
Announcements, Recording, Transcoding (Audio,Video), media stream 
manipulation,
etc. The Introduction may talk about the general need for this protocl, 
and give some examples.

2- Terminology
"The Application Server includes the conference policy server, the focus 
and the conference notification server as defined in [CARCH]"
Again, the Application Server can hold any communication application 
that needs media resource services. A conference server
can be given as an example but not as part of the Application Server 
definition.

3.1 Media Control Requirements

REQ-MCP-01 - The idea here is a relation many-to-many between an AS and MS ?

REQ-MCP-04 - I'm not sure what is the meaning of  "application scope" of 
the protocol
The applications of the protocol may be defined by different documents

REQ-MCP-14: This is not already done by SIP/SDP ?

REQ-MCP-16 and 18; when in 18 you say: "to play announcement to a single 
user" you mean to a single
conference participant ?
Can't we combine 16 and 18 ?

REQ-MCP-04, 5, 10, 11, 16, 17, 18 are more application 
requirements/functionality and not core MCP requirements
We can move those to a new req. chapter.

3.2 Media mixing requirement

REQ-MCP-25b: There may be a need to notify which is the active video 
window ( it can be different than the current speaker )

3.3 IVR Requirements

REA-MCP-30: Why not making this a Recording requirement ?
The AS shall be able to instruct the MS to record a media stream
to a URI (file:[nfs, iscsi, smb ... ]  ftp: webdav: http: .... ).

After that there is a requirement to play a file ( URI ) to a conference mix
or to play a file (URI) REQ-MCP-16 and 18

There must be a requirement to handle fail-over (AS fail over).

REQ-MCP-xx: An AS shall be able to send a SIP request to the MS to
change an open session (reINVITE, UPDATE)
There may be a security consideration here

REQ-MCP-xx: An AS shall be able to re-open failed channels and to 
instruct the MS to
send notifications for those channels to this AS.

REQ-MCP-xx: An AS shall be able to query an MS about open sessions
and get information about them.

================

Regards
Diego B

_______________________________________________
MEDIACTRL mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mediactrl
Supplemental Web Site:
http://www.standardstrack.com/ietf/mediactrl

---

From: "Even, Roni" <[email-masked]>
Date: Thu, 26 Jul 2007 15:35:48 +0300

Diego,

Thanks, see inline

Roni

> -----Original Message-----

> From: Diego B [mailto:[email-masked]]

> Sent: Tuesday, July 17, 2007 1:02 AM

> To: [email-masked]; Spencer Dawkins

> Subject: [MEDIACTRL] Comments on draft-dolly-mediactrl-requirements-00

> for all media service.

[RE:] agreed

> and give some examples.

[RE:] I will try to make it clearer. I am not sure about general recording

> definition.

[RE:] Right, I will clarify

> REQ-MCP-01 - The idea here is a relation many-to-many between an AS and MS

> ?

[RE:] Yes, there was a comment from Xiao with suggested text that I will use.

> The applications of the protocol may be defined by different documents

[RE:] I think that this is the scope of work, this is why I am not sure about general recording.

> REQ-MCP-14: This is not already done by SIP/SDP ?

[RE:] This is the solution if you use 3PCC between AS and MS but we need to decide on solution

> Can't we combine 16 and 18 ?

[RE:] OK

> We can move those to a new req. chapter.

[RE:] I can do it but I wanted to have all the general requirements in one section. Is it important

> window ( it can be different than the current speaker )

[RE:] How do you define active video?

> After that there is a requirement to play a file ( URI ) to a conference

> mix

> or to play a file (URI) REQ-MCP-16 and 18

[RE:] This is again a question of scope. 

> There may be a security consideration here

[RE:] OK, I will make it general, not a SIP request but just the operation.

> send notifications for those channels to this AS.

[RE:] I am not sure I understand the flow logic.

> and get information about them.

[RE:] I think it is covered in 31 and 32

---

From: "Diego B" <[email-masked]>
Date: Thu, 26 Jul 2007 16:03:41 +0300

Hi;

Regarding the "active video" I was thinking about video conferences
where a presetnation is another participant, so the active speaker
is one participant and the active video is the presentation participant,
this make sense ?

I think a separation between core retirement and application specific
requirement
can make the doc clear and extensible ( until its final release ).

> instruct the MS to send notifications for those channels to this AS.
The flow : imagine an AS (AS1) for some reason crash. another AS (AS2)
take over AS1 sessions and now it has to re-open the control-channels
with the Media Servers to continue. If each connection has a
connection ID (CID),
there has to be a way for AS2 to open a channel to the MS and to
assign to this connection the CIDs from AS1. From now on, all the
event from CID will be managed
by AS2.

Why do you think general recording is not at the same scope level as
mixing or IVR ?

Regards
Diego B

---

From: Eric Burger <[email-masked]>
Date: Thu, 26 Jul 2007 12:06:59 -0500

[not as chair]

> Why do you think general recording is not at the same scope level as

Because it is always part of mixing or IVR.

Notice:  This email message, together with any attachments, may contain information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated entities,  that may be confidential,  proprietary,  copyrighted  and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.

---

From: "Diego B" <[email-masked]>
Date: Thu, 26 Jul 2007 20:25:05 +0300

Hi;
Yes, right.
I can see this now.

Thanks
Diego B

---

From: Peili <[email-masked]>
Date: Thu, 26 Jul 2007 14:55:15 -0500

> Because it is always part of mixing or IVR.
Peili: what about Personal Video Recording which may not bounded to IVR 
or mixing?