Subject: Basic Media Policy (was: RE: [XCON] CPCP requirements to support IMS)

From: [email-masked]
Date: Tue, 16 Dec 2003 10:54:53 +0200

> -----Original Message-----
> From: ext Eric Burger [mailto:[email-masked]]
> Sent: 15.December.2003 19:06
> To: Khartabil Hisham (NMP-MSW/Helsinki); [email-masked]
> Subject: RE: [XCON] CPCP requirements to support IMS
> 
> 
> I suppose if the policy is "this conference can accept [one 
> or more of {audio, video, text, application}]", then that works.
> 
> Note that does not prevent a "(audio, video)" conference from 
> accepting a "(audio)"-only participant.  Or does it?  I would 
> vote "no."

I agree.

So back to my ogiginal question:

Should we define a basic media policy as a first step in CPCP (for media types only)?

Regards,
Hisham

> 
> 
> -----Original Message-----
> From:	[email-masked] [mailto:[email-masked]]
> Sent:	Mon 12/15/2003 2:54 AM
> To:	Eric Burger; [email-masked]
> Cc:	
> Subject:	RE: [XCON] CPCP requirements to support IMS
> Are you suggesting that that creator of a conference has no 
> say in what media the conference will offer?
> 
> /Hisham
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]On 
> Behalf Of ext
> > Eric Burger
> > Sent: 12.December.2003 22:31
> > To: Khartabil Hisham (NMP-MSW/Helsinki); [email-masked]
> > Subject: RE: [XCON] CPCP requirements to support IMS
> > 
> > 
> > Why do we need an explicit policy at all?
> > 
> > Wouldn't the bridge, by its nature, accept or reject the 
> > different media types?
> > 
> > > -----Original Message-----
> > > From: [email-masked] 
> [mailto:[email-masked]]
> > > Sent: Fri, December 12, 2003 9:32 AM
> > > To: [email-masked]; [email-masked]; 
> [email-masked]
> > > Subject: RE: [XCON] CPCP requirements to support IMS
> > > 
> > > 
> > > The issue I have is that we at least need to know the media 
> > > to be used in the conference (audio, video, text), to enable 
> > > the server to reserve resources and to enable the focus to 
> > > include/exclude certain media from the INVITEs SDP it sends 
> > > out to the dial-out list, and also enables the focus to 
> > > reject the media streams in the SDP of INVITE request coming 
> > > from dial-in participants.
> > > 
> > > I don't think in the basic media policy needs to define what 
> > > the codecs to be used are, this can be a normal offer answer 
> > > exchange between the client and the server.
> > > 
> > > This is a basic requirement and enables CPCP to work without 
> > > the complicated media policy. If the people working on the 
> > > media policy could work on a basic one like this, it would be 
> > > great. We can then work on an advanced media policy as a 
> > second step.
> > > 
> > > Regards,
> > > Hisham
> > > 
> > > > -----Original Message-----
> > > > From: [email-masked] [mailto:[email-masked]]On 
> > > Behalf Of ext
> > > > Adam Roach
> > > > Sent: 11.December.2003 23:40
> > > > To: Koskelainen Petri (NRC/Tampere); [email-masked]
> > > > Subject: RE: [XCON] CPCP requirements to support IMS
> > > > 
> > > > 
> > > > [as chair]
> > > > 
> > > > [email-masked] 
> > > > [mailto:[email-masked]] wrote:
> > > > 
> > > > > I'm a bit worried about media policy-CPCP integration 
> > > > > and WG schedule regarding it.
> > > > > 
> > > > > Currently the charter says the following:
> > > > > May 04  Submit Membership Manipulation Protocol for 
> > > > publication as PS 
> > > > > Jul 04  Submit Protocol for Media Topology Control for 
> > publication
> > > > > 
> > > > > What I would like to have by May 04 is CPCP with the ability 
> > > > > to set up typical real-life conference, e.g. with audio 
> > > codec X and
> > > > > centralized mixer. 
> > > > ...
> > > > > Current media policy seems to be extremely complex and 
> > > the RFC goal 
> > > > > is not until July.
> > > > > 
> > > > > Georg can probably comment on 3GPP schedules but in any case, 
> > > > > should we adopt simple media definition in CPCP itself 
> > (or divide
> > > > > media policy into basic and advanced parts so basic 
> > media policy 
> > > > > could be ready by May 04)?
> > > > 
> > > > Media policy was pushed to July precisely because it is 
> > more complex
> > > > and (at this point, at least) more contentious.
> > > > 
> > > > I fear that diverting resources to getting a bare-bones 
> > media policy
> > > > out the door early will only cause significant delays 
> to not just
> > > > advanced media policy, but to all of our deliverables. 
> That seems
> > > > a steep price to pay for a two-month advance on publication.
> > > > 
> > > > Hopefully, by the time the membership manipulation 
> > document is ready
> > > > for publication, the media policy draft will be stable 
> > > enough to give
> > > > you a basis to start implementation.
> > > > 
> > > > What is important to keep in mind is that we are not 
> > > performing these
> > > > tasks serially. The documents should develop pretty much in 
> > > parallel.
> > > > 
> > > > /a
> > > > 
> > > > _______________________________________________
> > > > XCON mailing list
> > > > [email-masked]
> > > > https://www1.ietf.org/mailman/listinfo/xcon
> > > > 
> > > 
> > > _______________________________________________
> > > XCON mailing list
> > > [email-masked]
> > > https://www1.ietf.org/mailman/listinfo/xcon
> > > 
> > > 
> > 
> > 
> > _______________________________________________
> > XCON mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/xcon
> > 
> 
> 
> 
> 
> 
> 

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