Subject: [mediactrl] Draft Meeting Minutes

From: "Burger, Eric" <[email-masked]>
Date: Thu, 10 Nov 2005 09:27:44 GMT

Media Control - Meeting Minutes
IETF 64
Vancouver, B.C. Canada
November 9th, 2005

Alvin Chubbs, humble scribe

Discussion focussed on
http://www.ietf.org/internet-drafts/draft-dolly-xcon-mediacntrlframe-00.
txt
 
1) Requirement 3
        - ASR/TTS is ground that is already covered by other protocols
        - Action Item (Martin): reword the requirement to indicate that
the protocol enables ASR/TTS services, but that the functionality is
invoked through other mechanisms
 
2) Requirement 7
        - Action Item (Martin): reword to indicate that the protocol
should allow, but must not require, a media server resource broker /
proxy to exist
 
3) Requirement 8
        - allow two models of conference control channel usage:
                1) one control channel can control multiple conferences
                2) one control channel per conference
        - wording related to "individual leg instructions" should be
modified to indicate that control can extend to individual media streams
        - Action Item (Martin): reword the requirement to encompass the
above points
        - some discussion about whether a single conference can be
controlled by multiple control channels. Some concerns expressed about
allowing this, but no requirement statement to explicitly disallow.
 
4) Requirement 9
        - some discussion about the meaning of command, and a suggestion
to use terms such as request, response and notification.
        - Action Item (Martin): define the terms used in the document -
any nouns used such as command, request, response, notification, etc.
        - reuse xcon terms where appropriate
 
5) Requirement 10
        - Action Item (Martin): delete the requirement. Discussion of
RTP is out of scope for this protocol.
 
6) Requirement 11
        - Action Item (Martin): add a context paragraph at the start of
the document to indicate that media session establishment is out of
scope. Requirement should use xcon wording to imply that the protocol is
agnostic with respect to specific media session establishment protocol
used.
        - general feeling was that the media session establishment
protocol will be SIP. However, no definite statement to that effect.
 
7) Requirement 12
        - Action Item (Martin): change the "must" to a "may" for this
requirement
        - Some discussion that protocol mechanisms are not needed to
accomplish this requirement, as it can be accomplished in the AS.
Counter-point to this line of thought was the example of an audio-video
conference with voice activated switching.
 
8) Requirement 13
        - Action Item (Martin): delete this requirement as it is out of
scope for the protocol. Explain in context paragraph at the start of the
document that the moving of conferences between Media Servers is done by
the AS.
 
9) Requirement 14
        - Action Item (Eric): deal with Jim later
 
10) Requirement 15
        - Action Item (Martin): move this requirement to Section 3.2.
Wording should emphasize that AS must be able to audit MS state.
 
11) Requirement 16
        - Action Item (Martin): add wording about maintaining forward
and backward compatibility
 
12) Requirement 2
        - Action Item (Martin): add new requirement (2a) that transport
layer protocol used must be reliable. 
        - Action Item (Martin): group together requirements 2, 2a, 3, 5
and 6. (This suggestion came from Eric - in case further elaboration is
required.)

13) Possible New Requirement - discovery and service advertisement
        - discussion that there is a need for the following but not in
this protocol
                - way for the MS to advertise its capabilities
                - way for the AS to discover MS
        - Action Item (Martin): add text at the start of the document
and mention that the above items are needed but are out of scope for
this protocol
 
14) Possible New Requirement - packages
        - once we got past initial reactions, consensus was that the
requirements are extensibility and flexibility. Packages are one
possible solution. They are not a requirement.
 
15) Possible New Requirement - call statistics at end of call
        - this will be needed in AS-MS interaction, but will not be done
in this protocol
 
16) Possible New Requirement - redundancy mechanisms
        - no protocol requirements related to redundancy were identified
at this time
 
17) Action Item (Chris): provide directions on how to access the mail
list archive
 
18) Next Steps
        - discussed option of moving work to speechsc 
        - consensus to stay under the radar for now to prevent things
from getting slowed down prematurely
        - discussion of 3GPP IMS architecture. Comments that there is no
clear definition of MRFC, and that Media Resource Broker appears to be
missing.
        - Action Item (Martin): update draft by start of 2006
        - Action Item (Eric?): setup teleconference by end of January. 
        - Next IETF meeting is March in Dallas. Expect to be discussing
protocol proposals then.

--------------------------
Ubiquity Software does not control or endorse the content, messages or information found in this mail list and it specifically disclaims any liability with regard to these communications.
Ubiquity Software reserves the right the restrict access to any communications in violation of the Terms and Conditions of Use for this website or as otherwise deemed improper.