Subject: Re: H.248/BICC discussions

From: "Rosen, Brian" <[email-masked]>
Date: Mon, 5 Jun 2000 15:21:10 -0400

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

---

From: Christian Groves <[email-masked]>
Date: Tue, 6 Jun 2000 11:09:26 +1000

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