Subject: [mediactrl] RE: mixer protocol req. - general protocol comments

From: "Even, Roni" <[email-masked]>
Date: Wed, 8 Dec 2004 09:59:00 GMT

Tim,
I was going through the comments. inline

-----Original Message-----
From: Tim Melanchuk [mailto:[email-masked]] 
Sent: Wednesday, November 24, 2004 8:53 PM
To: Even, Roni; Eric Burger; Cullen Jennings; Chris Boulton; Adam Roach;
Johnston, Alan; Garland Sharratt; Orit Levin; [email-masked]
Subject: mixer protocol req. - general protocol comments

General protocol

1. The transport of the protocol should be based on standard protocols (
SIP, H.248)

[timm] although we sometimes consider h.248 as a transport, it clearly
cannot be used simply as a transport because it brings along much
additional functionality. sip is *not* considered a general transport
protocol. tcp, udp, sctp could be considered as transport protocols
and i have sometimes thought that msrp could be a candidate.

RE: The transport here is not a transport protocol but a transport
mechanism for the mixer control protocol.

3. The protocol should enable many AS to work with the same MS (is this
really needed???)

[timm] we see this out in the world. a large carrier grade MS will
support multiple ASs where a smaller enterprize MS may not. hence,
i think that the capability should be allowed/supported by the
protocol, but not required by an MS.

RE: My question is if there a need to allow many AS to work with one MS
not based on any virtual allocation. This requirement makes it more
complicated for the AS to decide which of the MS he is managing can be
used for a new conference specially if he does not know what is the
resources usage on the MS by the other AS.

4. The AS should be able to find the MS and connect to it.

[timm] what protocol mechanisms do you think are required here? i would
hope that we could utilize existing dns or ther mechanisms without
requiring this protocol to define discovery mechanims. also, should
control
connections always be initiated from the AS to the MS, should it be the
other direction, or should either be allowed/supported? for example
mgcp and h.248 are initiated from the gateway.

RE: I am still on the requirement phase.

6. The protocol should be extendable.

[timm] i think this should be a must, but we can debate the
extension mechanisms ;-)

7. The MS shall be able to tell the AS its capacities.

[timm] this gets into the resource management area, which i think is
important but also potentially complex. how are capacities defined
and what gets reserved. i think something simple is possible, but
it can be difficult to define standard definitions here.

RE: see my response to multiple AS with one MS. It is also for enabling
the MS to inform the AS about malfunction.

8. The MS shall be able to tell the AS its functionality (Mixing, IVR,
Announcements)

[timm] agreed that there has to be a capability mechanism somewhere.
i'm not sure it's part of this protocol.

RE: we need to address it if we want AS and MS from different
manufacturers 

9. The AS shall be able to create and delete sessions on the MS.

[timm] i think that session establishment should be *explicitly* out of
scope for this protocol. sip is an example of a session establishemnt
protocol that works well in the context of application and media
servers.
the protocol should be focused on conference application functionality,
and not duplicate things found in other protocols.

RE: your comment is a solution. The requirement is for the AS to be able
to start a mixing session on the MS

10. The MS shall supply the media addresses (RTP transport address) to
be
used to the AS.

[timm] see above. i would make the assumption that the AS learns
this using the session establishemnt protocol. if for some reason
the AS is *not* on the session establishment signalling path, then
an extension could be developed to allow the AS learn about
all of the media parameters for a session.

RE: you are assuming a specific transport.

11. The MS should send a summary report when the session is terminated
by
the AS.

[timm] i'm not sure what you mean by a "summary report". our experience
has been that many application developers prefer the ability request
or enable notifications rather than having persistent reporting.

12. The AS should be able to request from the MS call status report.

[timm] how about: "The AS should be able to request call/session and
conference state from the MS."
RE: OK

14. The protocol shall include redundancy procedures.

[timm] i'm pretty sure i'll have comments here at some time ;-)

18. The MS shall inform the AS about any changes in it capacities.

[timm] is this requiring real time updating of the AS based on
fine grained changes, high/low water marks for different resources,
or as resources are added/removed through admin/provisioning actions?

RE: we will need to define this. The requirement is general

19. The AS shall be able to tell the MS which codecs to use on incoming
and out going streams

[timm] as above, i think this is part of session establishment and
out of scope for the protocol. service providers that use sip can
use the session policy mechanisms currently being developed to define
the media policy in their networks.

RE: The session policy is between the user/administrator and the AS. Now
the AS needs to be able to force this policy on the media server. This
is the part we are trying to address here.

--------------------------
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.

---

From: Tim Melanchuk <[email-masked]>
Date: Wed, 8 Dec 2004 17:55:08 GMT

inline....
Even, Roni wrote:
Tim,
-----Original Message-----

General protocol
1. The transport of the protocol should be based on standard protocols (
SIP, H.248)
[timm] although we sometimes consider h.248 as a transport, it clearly
cannot be used simply as a transport because it brings along much
additional functionality. sip is *not* considered a general transport
protocol. tcp, udp, sctp could be considered as transport protocols
and i have sometimes thought that msrp could be a candidate.
RE: The transport here is not a transport protocol but a transport
mechanism for the mixer control protocol.
[timm] i don't understand the distinction you are making. yes, we
need a transport mechanism for the mixer control protocol. i think
that transport mechanism should be a transport protocol and not
a protocol that does a bunch of other things and that just may,
incidentally be able to carry mixer control commands.
3. The protocol should enable many AS to work with the same MS (is this
really needed???)
[timm] we see this out in the world. a large carrier grade MS will
support multiple ASs where a smaller enterprize MS may not. hence,
i think that the capability should be allowed/supported by the
protocol, but not required by an MS.
RE: My question is if there a need to allow many AS to work with one MS
not based on any virtual allocation. This requirement makes it more
complicated for the AS to decide which of the MS he is managing can be
used for a new conference specially if he does not know what is the
resources usage on the MS by the other AS.
[snip]
8. The MS shall be able to tell the AS its functionality (Mixing, IVR,
Announcements)
[timm] agreed that there has to be a capability mechanism somewhere.
i'm not sure it's part of this protocol.
RE: we need to address it if we want AS and MS from different
manufacturers 
[timm] there are capability description mechanisms already defined
within the ietf. some of them work with some session establishment
protocols. my point is that i hope we examine those mechanism and
conclude that they do not fit our needs before we go and invent
new mechanism.

9. The AS shall be able to create and delete sessions on the MS.
[timm] i think that session establishment should be *explicitly* out of
scope for this protocol. sip is an example of a session establishemnt
protocol that works well in the context of application and media
servers.
the protocol should be focused on conference application functionality,
and not duplicate things found in other protocols.
RE: your comment is a solution. The requirement is for the AS to be able
to start a mixing session on the MS
[timm] again, i'm simply saying that we have session protocols already
within the ietf. we should strive to use those before deciding that we
need that functionality in *this* protocol.
10. The MS shall supply the media addresses (RTP transport address) to
be
used to the AS.
[timm] see above. i would make the assumption that the AS learns
this using the session establishemnt protocol. if for some reason
the AS is *not* on the session establishment signalling path, then
an extension could be developed to allow the AS learn about
all of the media parameters for a session.
RE: you are assuming a specific transport.
[timm] i am assuming a separation of session establishment and
media server control. i think not reinventing is a good thing.
[snip]
--------------------------
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.