Subject: RE: [mediactrl] The MediaCTL BOF has been aproved.

From: "Drage, Keith \(Keith\)" <[email-masked]>
Date: Tue, 26 Sep 2006 12:57:39 +0100

3GPP TR 24.880 is a feasibility study to work out the best protocol to
fulfil the functional split between AS/S-CSCF/MRFC. It does not touch
the split between the MRFP and the MRFC.

As a feasibility study it can make proposals for changes in the 3GPP IMS
architecture to encompass the best usage, which can be fed to the
architecture group for approval.

Note that the IMS architecture we are talking about is a functional
architecture consisting of functional entities. This does not constrain
a physical box containing two functional entitites. Therefore it is
entirely appropriate that the MRFC and MRFP are subsumed into a single
physical box for deployment (the H.248 community view the AS/MRFC as
deployable in a single box with a separate MRFP).

Note that this discussion is not IMS specific, we would be arguing the
same split of functionality if IMS did not exist.

The first task of the BoF is to try and enshrine the scope of the work
into a charter.

Regards

Keith

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf 
> Of Even, Roni
> Sent: 25 September 2006 22:02
> To: Diego B; Asher Shiratzky
> Cc: Mike Coffee; Cullen Jennings; MixerControl; Eric Burger
> Subject: RE: [mediactrl] The MediaCTL BOF has been aproved.
> 
> Hi,
> So we already show that we are not sure why we are doing this 
> work. A couple of view I see here
> 
> 1. AS-MRFC is XCON and MRFC-MRFP is MediaCTL 2. There only AS 
> and MS (need to change IMS architecture) 3. AS-MRFC is 
> MediaCTL and MRFC-MRFP is H.248
> 
> Roni
> 
> > -----Original Message-----
> > From: Diego B [mailto:[email-masked]]
> > Sent: Monday, September 25, 2006 10:18 PM
> > To: Asher Shiratzky
> > Cc: Mike Coffee; Even, Roni; Cullen Jennings; MixerControl; Eric 
> > Burger
> > Subject: Re: [mediactrl] The MediaCTL BOF has been aproved.
> > 
> > Hi;
> > As far as I know, based on current deployments, companies are 
> > deploying MRF-C and MRF-P as a single component hiding the real 
> > interface between them.
> > I may be wrong, but this is the way several companies are 
> working now.
> > 
> > What is the meaning of  using MSCML or MOML/MSML between MRF-C and 
> > MRF-P ? I belive those protocol are more suitable to be an 
> MRF-C interface.
> > 
> > I think the MediaCTL group has to concentrate in defining , 
> as Asher 
> > propose, the interface MRF-C <= Cr => AC
> > 
> > Regards
> > Diego B
> > 
> > 
> > Asher Shiratzky wrote:
> > > The focus and the first priority of the MediaCTL BOF should be  to
> > define the AS to MRFC interface based on SIP. Today in 3GPP 
> there is 
> > only a SIP based interface between the S-CSCF to the MRFC 
> which is not 
> > sufficient for applications, Although it defined as SIP 
> there is a way 
> > to go to make it an interoperable and a fully defined interface.
> > > Looking on the history of the MRFC/ MRFP interface in the 
> 3GPP, in 
> > > all
> > the meetings and cases the 3GPP disapprove SIP as a replacement for 
> > H.248 (independent if it comes from the MSF or from individual 
> > companies), and this is based on the fact that it's against 
> the 3GPP 
> > architecture for MG to MGC relationship (where MRFC to MRFP 
> is one of 
> > the use cases) which is also used by ETSI TISPAN.
> > >
> > > Bottom line: let's start from the AS to MRFC interface 
> (documented 
> > > in
> > 3GPP TR 24.880) where we should approve all the drafts it's 
> based on, 
> > and than in the future we can handle other items as well. If those 
> > drafts will not progressed the 3GPP will find other ways to make it
> > >
> > > Thanks,
> > > Asher
> > >
> > > -----Original Message-----
> > > From: [email-masked] [mailto:owner-
> > [email-masked]] On Behalf Of Mike Coffee
> > > Sent: Monday, September 25, 2006 3:22 PM
> > > To: Even, Roni
> > > Cc: Cullen Jennings; MixerControl; Eric Burger
> > > Subject: RE: [mediactrl] The MediaCTL BOF has been aproved.
> > >
> > >
> > >
> > > Since it appears that very few vendors are utilizing H.248 for 
> > > MRFC-to-
> > MRFP control, and are, instead, using MSCML or MOML/MSML, Media 
> > Control would give the industry a best-of-both worlds and a 
> single de 
> > jure protocol suite to support.
> > >
> > > Mike Cofee
> > >
> > >
> > >
> > > Hi,
> > > What is the meaning of the "do no harm". I thought we are 
> trying to
> > promote this work in 3GPP IMS to replace H.248 as MS or 
> MRFC to MRFP 
> > control protocol. My assumption is that once we get 
> approval for the 
> > work at IETF we would suggest it to the 3GPP.
> > > If not why are we doing it at all?
> > > Roni
> > >
> > >
> > >> -----Original Message-----
> > >> From: [email-masked] [mailto:owner- 
> > >> [email-masked]] On Behalf Of 
> Cullen Jennings
> > >> Sent: Thursday, September 21, 2006 8:06 PM
> > >> To: MixerControl
> > >> Cc: Eric Burger
> > >> Subject: [mediactrl] The MediaCTL BOF has been aproved.
> > >>
> > >>
> > >> I would like to pass on that IESG is going to approve 
> this BOF. A 
> > >> few comments that came back is that one of the good 
> parts of this 
> > >> work is that it looks like it will "do no harm". I 
> encourage folks 
> > >> to keep that true :-)
> > >>
> > >> We need to get the official request this weekend. I 
> would like the 
> > >> BOF to be 1 hour. I will work with Eric on getting the 
> request in.
> > >>
> > >> If people would like to send me private input on suggestions for 
> > >> possible chair(s) if a WG is formed, please do send it soon - in 
> > >> general I am keen on a chair that is experienced and a 
> chair that 
> > >> has lots of energy and is not too jaded. (for some reasons this 
> > >> often results in two chairs :-)
> > >>
> > >> Thanks, Cullen
> > >>
> > >>
> > >>
> > >> --------------------------
> > >> 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.
> > >>
> > >
> > > --------------------------
> > > 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.
> > >
> > >
> > >
> > > --------------------------
> > > 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.
> > >
> > >
> > > --------------------------
> > > 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.
> > >
> 
> 
> --------------------------
> 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.
> 

--------------------------
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: Eric Burger <[email-masked]>
Date: Tue, 26 Sep 2006 17:14:35 +0100

I would encourage everyone to review the document.  It is freely
downloadable from the 3GPP web site.  If you are a 3GPP member, I would also
strongly suggest commenting on the document.