Subject: RE: [MEDIACTRL] Updates to Charter

From: "Chris Boulton" <[email-masked]>
Date: Mon, 4 Dec 2006 12:54:33 -0000

Agreed with Roni - the intention (and yes during our past discussions a decision was made) is SIP.

Chris.

-----Original Message-----
From: Even, Roni [mailto:[email-masked]] 
Sent: 04 December 2006 12:10
To: Drage, Keith (Keith); Lorenzo Miniero; [email-masked]
Subject: RE: [MEDIACTRL] Updates to Charter

The motivation for this work was to define the control protocol between the AS and MS taking into account that the AS and MS will have SIP stacks for session establishments between the terminals and the AS or MS anyhow, so we can leverage SIP for establishing the control connection between the AS and MS.
Roni Even

> -----Original Message-----
> From: Drage, Keith (Keith) [mailto:[email-masked]]
> Sent: Monday, December 04, 2006 2:04 PM
> To: Lorenzo Miniero; [email-masked]
> Subject: RE: [MEDIACTRL] Updates to Charter
> 
> Note that I did expect the words are an extract from the P2PSIP charter,
> and they will need some tailoring to fit mediacontrol.
> 
> However I think that allowing mediacontrol to go out and develop a session
> control protocol per se will need considerably more discussion on the
> charter. I have always assumed it was a SIP adjunct.
> 
> Keith
> 
> > -----Original Message-----
> > From: Lorenzo Miniero [mailto:[email-masked]]
> > Sent: 04 December 2006 11:54
> > To: [email-masked]
> > Subject: Re: [MEDIACTRL] Updates to Charter
> >
> > Hi Keith,
> >
> > > I did send the following mail to the list before the BOF.
> > >
> > > I think it did encompass Chris's concern.
> > >
> > > Keith
> > >
> > >
> > > From:	[email-masked] on
> > behalf of Drage,
> > > Keith (Keith) [[email-masked]]
> > > Sent:	05 October 2006 21:25
> > > To:	Eric Burger; IETF mediactrl
> > > Subject:	RE: [mediactrl] Proposed Charter
> > >
> > > There is a paragraph in the P2PSIP draft charter:
> > >
> > > "The work planned for the P2PSIP working group is distinct
> > from, but
> > > requires close participation with other IETF WGs, particularly SIP,
> > > SIPPING, SIMPLE, BEHAVE and MMUSIC. The group cannot modify the
> > > baseline SIP behavior, define a new version of SIP, or attempt to
> > > produce a parallel protocol for session establishment. If the group
> > > determines that any capabilities requiring an extension to SIP are
> > > needed, the group will seek to define such extensions
> > within the SIP
> > > working group using the SIP change process (RFC 3427).
> > > Similarly, existing tools developed in the BEHAVE and MMUSIC groups
> > > will be used for NAT traversal, with extensions or changes
> > desired to
> > > support P2PSIP created in these groups."
> > >
> > > I would suggest that we would have something along the same
> > lines in
> > > any draft media-control charter. (It may well be worth a
> > scan of the
> > > P2PSIP charter for other issues that might be included - because I
> > > think that is a well written document).
> > >
> > > Regards
> > >
> > > Keith
> > >
> >
> >
> > I'm not sure I'd like a line as "The group cannot [..]
> > attempt to produce a parallel protocol for session
> > establishment" in the charter.
> > While it's OK for P2PSIP (since it's still SIP), in MediaCtrl
> > it would mean a decision has already been taken to use SIP
> > (and/or extensions to
> > it) as protocol between the AS and the MS. Is it actually so?
> >
> > Regards,
> > 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.
> >
> >
> > _______________________________________________
> > MEDIACTRL mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/mediactrl
> >
> 
> _______________________________________________
> MEDIACTRL mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/mediactrl
> 
> 
> 
> 
> 
> **************************************************************************
> **********
> This footnote confirms that this email message has been scanned by
> PineApp Mail-SeCure for the presence of malicious code, vandals & computer
> viruses.
> **************************************************************************
> **********
> 
> 

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

Information contained in this e-mail and any attachments are intended for the use of the addressee only, and may contain confidential information of Ubiquity Software Corporation.  All unauthorized use, disclosure or distribution is strictly prohibited.  If you are not the addressee, please notify the sender immediately and destroy all copies of this email.  Unless otherwise expressly agreed in writing signed by an officer of Ubiquity Software Corporation, nothing in this communication shall be deemed to be legally binding.  Thank you.

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

---

From: "Chris Boulton" <[email-masked]>
Date: Thu, 7 Dec 2006 10:14:23 -0000

I agree with Eric.

Chris.

-----Original Message-----
From: Eric Burger [mailto:[email-masked]] 
Sent: 06 December 2006 22:29
To: Martin Dolly; Cullen Jennings
Cc: Media Control
Subject: Re: [MEDIACTRL] Updates to Charter

I would offer the Media Broker is an embodiment of a thing that
understands
a protocol for locating the "correct" media server.

I would offer that for us to work on something that is more than just a
"protocol that runs on IP," i.e., an Internet protocol, we MUST deliver
a
method for locating servers and discovering their capabilities.

I would also offer that there is a 3% chance we will be creating a new
protocol for such a task.  In particular, if one recalls the proposed
deliverables and milestones discussed in San Diego, this is Deliverable
#4,
with a milestone of delivering a Broker Protocol *or* BCP in June of
2008.
That is, there is a 97% chance that the broker protocol is simply a
convention for how media servers advertise their capabilities, using
existing protocols.

Thus, as a participant, my vote is to keep this work in charter.

Of course, I will always bow low to my AD :-)

On 12/4/06 11:11 AM, "Dolly, Martin C, ALABS" <[email-masked]> wrote:

> That is the task of the Media Resource Broker
> 
> Sent: Monday, December 04, 2006 11:10 AM
> To: Dolly, Martin C, ALABS; Cullen Jennings
> Cc: Media Control
> Martin,
> Of course you know what you deploy, but how do you configure your
> application servers to know which MS or Media servers to use for IVR,
> which one for announcement, for audio conferencing for video
> conferencing.
> Do you require the Application server to have a UI for configuring it.
> Roni Even
> 
>> From: Dolly, Martin C, ALABS [mailto:[email-masked]]
>> Sent: Monday, December 04, 2006 6:04 PM
>> To: Cullen Jennings; Even, Roni
>> Cc: Media Control
>> I  believe that discovery of MS capabilities is out of scope. From a
>> service provider perspective, we know the capabilities of the
> equipment
>> we deploy.
>> 
>> Cheers, Martin
>> 
>> 
>> 
>> 
>> 
>> 
>
************************************************************************
> **
************************************************************************
> **