Subject: Re: H.248 Packages - what goal?

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 6 Jun 2000 07:40:24 -0400

I think that is a good idea, and I will incorporate it into the
the next draft of the ATM package.

Brian

> -----Original Message-----
> From: Christian Groves [mailto:[email-masked]]
> Sent: Monday, June 05, 2000 9:09 PM
> To: [email-masked]
> Subject: H.248 Packages - what goal?
>
>
> G'Day Brian,
>
> What I miss from the whole effort of using SDP (and Annex C for that
> matter) is how you specify a subset of properties that a MG must
> implement?
>
> If I have a package then I know I must implement all the properties.
> However with SDP and Annex C I'm left with a bucket of
> properties/values, which one's do I implement for a
> particular function?
> how can I extend these?
>
> The required SDP properties should at least be mentioned in
> the package
> that would use them. This would be aside from the global
> issue of adding
> ATM parameters to SDP for SIP/RTSP etc....
>
> Cheers, Christian
>
> "Rosen, Brian" wrote:
> >
> > Christian
> >
> > The Package we propose has little more than events for
> > setup failure and codec change, as well as statistics.  It has
> > no parameters.  We are trying to align the parameters in the
> > SDP extension to Annex C, but we do that entirely in SDP,
> > not in the Package.
> >
> > If you need two more parameters in the future, I think you
> > write a document and add them to SDP.  I'm not really sure
> > how you add things to Annex C.  I understand that it would
> > be nice to get the whole thing into a package, but I don't
> > see how to reconcile that with the SDP extension process,
> > especially when, as we are hear, the effort is defined to
> > be a one-document-for-all H.248/MGCP/SIP/RTSP/...
> >
> > There are discussions of reworking SDP (SDPng).  I plan to
> > participate in that process to make sure that things get
> > better with respect to this issue.
> >
> > Brian
> >
> > > -----Original Message-----
> > > From: Christian Groves [mailto:[email-masked]]
> > > Sent: Monday, June 05, 2000 12:00 AM
> > > To: Rosen, Brian
> > > Cc: [email-masked]
> > > Subject: Re: H.248/BICC discussions
> > >
> > >
> > > G'Day Brian,
> > >
> > > I support the idea that you're updating SDP and then writing
> > > a Package.
> > > I gather that as the properties will be defined in a package that
> > > they'll be able to be used by both binary and text forms
> of H.248. I
> > > think that having several packages extending each as
> proposed by Mike
> > > Brown is a good way of approaching things.
> > >
> > > In the future though I don't know that people will want
> to go through
> > > the effort of setting up email exploders/ writing drafts/
> > > packages etc.
> > > for what may amount to 2 values. A package could be a way of
> > > doing this.
> > >
> > > Cheers, Christian
> > >
> > > PS: What's MGCP??? ;-)
> > >
> > > "Rosen, Brian" wrote:
> > > >
> > > > It's not the idea that Megaco can extend SDP with MMUSIC in
> > > the loop.
> > > > It's whether the form to do this is a package.  It's
> probably all
> > > > in the details.
> > > >
> > > > I agree that Tom's basic premise, that a Megaco
> sponsored standards
> > > > track RFC that defines an extension is a perfectly
> appropriate way
> > > > to define an extension.  The package mechanism is
> defined as pretty
> > > > general, and of course is useable by parties other than
> the IETF (as
> > > > is the SDP extension mechanism).  If we made such a
> decision than
> > > > anyone could come along, define a megaco package that
> added a media
> > > > parameter, and have the result be an extension to SDP.
> > > >
> > > > Now, it's certainly true that anyone can define an
> extension to SDP
> > > > by just doing an IANA registration of a tag, so this
> isn't very much
> > > > different, it's just that doing it as a Megaco package
> makes the SDP
> > > > extension indirect -- is that what we want?
> > > >
> > > > Consider the alternative - what we are doing now.  We
> are writing
> > > > an I-D, with the intention of getting it published as
> an MMUSIC RFC
> > > > that defines an ATM extension to SDP.  Then we have another
> > > I-D that will be
> > > > published as a Megaco RFC that defines a Megaco package
> using that
> > > > SDP extension.  We also have an MGCP package, but that is
> > > outside the
> > > > scope of this discussion at the moment.  Is that not a
> > > preferable way
> > > > to get the job done?
> > > >
> > > > Brian
> > > >
> > > > > -----Original Message-----
> > > > > From: Scott Bradner [mailto:[email-masked]]
> > > > > Sent: Friday, June 02, 2000 3:29 PM
> > > > > To: Rosen, Brian
> > > > > Cc: [email-masked]; [email-masked]
> > > > > Subject: Re: H.248/BICC discussions
> > > > >
> > > > >
> > > > > > Well, I'm having a problem with the idea that a package can
> > > > > extend SDP.
> > > > >
> > > > > SDP is designed to be extensible - it is reasonable for other
> > > > > IETF working
> > > > > groups to suggest extensions, the mmusic WG should be in the
> > > > > loop during
> > > > > the discussions but having the group that has the best
> > > knowledge of
> > > > > what the extensions are for be in the drivers seat means
> > > it is more
> > > > > likly to get done in a reasonable period of time - mmusic
> > > can provide
> > > > > feedback if they think that the proposed extensions run
> > > > > counter to the
> > > > > SDP design goals or feel that there is a better way to do the
> > > > > function.
> > > > >
> > > > > Scott
> > > > >
> > >
>