Subject: Re: Profiles in Service Change

From: Peter Blatherwick <[email-masked]>
Date: Mon, 11 Sep 2000 11:42:19 -0400

I believe that "something's" you are looking for have already been
discussed.

Re solutions, I recall seeing on this thread:
1) Backoff mechanism, try Profile X, and if MG can't get it confirmed, go to
next less capable profile Y.
2) Use multiple virtual MGs within the same physical device,
3) Define super-profiles, containing X + Y, and being sure to resolve any
resulting ambiguity (noting we currently have no rules for subclassing-like
mechanism a la package definition, but it would be a nice version 2 piece to
work through).
May have missed some (did not go back and double-check).

I also think a brief note on what profiles are intended to do (avoiding
explicit rules) would be in order.  I think most of that material has also
gone by in this thread.

My 0.05 (to avoid Oz round-off ;-)

-- Peter

-----Original Message-----
From: Christian Groves [mailto:[email-masked]]
Sent: Wednesday, September 06, 2000 19:59
To: [email-masked]
Subject: Re: Profiles in Service Change

G'Day Brian,

I completely agree that we want to make it HARD to have a multiplicity
of overlapping profiles.  But with the current text I see that we make
it impossible, its got one profile and only talks about a profile. That
is why I'd like to see : a technical change in the implementor's guide
or an implementation or "something" to say at least say how you cope
with the case where: the MG supports multiple profiles and/or the MGC
needs to access 2 profiles to complete a service. Its a real world issue
that we have to deal with as soon as we have 2 profiles defined.

Cheers, Christian

"Rosen, Brian" wrote:
>
> What is wrong is that it promotes proliferation of
> many overlapping profiles.  Profiles are supposed to be
> a way of reducing the variability that Packages provide,
> so that one could reasonably expect to be able to find
> interoperable MGs and MGCs.
>
> No one can legislate this (no protocol police...), but
> we can encourage, or discourage proliferation of
> many profiles that attempt to solve the same problem
> different ways.  If you support 100 profiles, you may
> as well just ignore the profile info and look at the
> audited package list!
>
> I want to make it HARD to have more than one profile
> per MG (not MGC).  Not impossible, just hard.  I think
> that will encourage coalescing around a small number of
> profiles for specific purposes that all relevant MGs and
> MGCs support, which in turn will make the protocol successful.
>
> What I fear is balkanization by proliferation of profiles,
> which leads to non-interoperable devices.  It would be non
> interoperable because there were no common profiles, rather
> that if you found a common one, it wouldn't work.  The
> package mechanism is a wonderful way to have all sorts of
> extensions and features in MGs.  The profile mechanism was
> designed to provide a way to corral the easy expansion into
> more limited groups of options.  Generally, successful
> protocols are not easy "bent" in many different ways -> you
> get ONE way, and everyone does it that way, and the world
> is better for it.  The package thing is great, but it is
> a danger.  The profile is the only way I know to limit it's
> potential to undermine the effectiveness of the protocol.
>
> Brian
>
> > -----Original Message-----
> > From: Flemming Andreasen [mailto:[email-masked]]
> > Sent: Wednesday, September 06, 2000 10:01 AM
> > To: Michael P DiGioia
> > Cc: [email-masked]; Christian Groves;
> > Rosen, Brian
> > Subject: Re: Profiles in Service Change
> >
> >
> >
> >
> > Michael P DiGioia wrote:
> >
> > > Brian,
> > >
> > > > > So does that mean that nobody can make an MG which
> > supports more than
> > > > > one profile? :-)
> > >
> > > >One way to get around the limitation is to try to get
> > > >service using the most "featurefull" profile.  If you fail
> > > >to find an MGC that can serve that profile, try again with
> > > >a different profile.
> > >
> > > I agree. I believe the point is that any one MG can support
> > one or more
> > > profile, however, once the most featurefull profile is
> > found to be accepted
> > > by an MGC, use it.
> >
> > I disagree as Brian's comments assumes a meaningful ordering
> > relation between
> > (at least a resonable subset of) profiles based on some set
> > of features
> > supported. I don't see that. Christian's proposal of allowing
> > a listing of
> > profiles seemed pretty good to me - what was wrong with this again ?
> >
> > -- Flemming
> >
> > >
> > >
> > > What we build into our IpPhone MG is our choice. I don't
> > believe this limits
> > > us in any way. If so, how?
> > >
> > > /mpd
> >
> > --
> > Flemming Andreasen
> > Cisco Systems
> >
> >

---

From: Christian Groves <[email-masked]>
Date: Wed, 13 Sep 2000 13:43:27 +1100

G'Day Pete,

Yes these somethings have been mentioned but I replied that I didn't
think these were sufficient. See comments [CHG] below.

I think that even in H248v1 we need to specify how profile
negotiation/confirmation is done. There is no proper description of
this. We should do this ASAP as if we wait until v2 then we will have
lots of non - compatible implementations on how they handle profiles.

Cheers, Christian

Peter Blatherwick wrote:
> 1) Backoff mechanism, try Profile X, and if MG can't get it confirmed,
> go to next less capable profile Y.
[CHG] Just how is this achieved today? There is nothing H248 that says
how the negotiation is done. The MGC may return the profile for
negotiation but that's the extent of the text saying how negotiation is
used. Does it negotiate version? profile name?

> 2) Use multiple virtual MGs within the same physical device,
[CHG] I do not believe this is a sufficient solution for all cases. The
MG should be able to support different profiles in one Virtual MG.

> 3) Define super-profiles, containing X + Y, and being sure to resolve
> any resulting ambiguity (noting we currently have no rules for
> subclassing-like mechanism a la package definition, but it would be a
> nice version 2 piece to work through).
[CHG] Subclassing and superprofiles? This is not a 'now' solution and
definitely for version 9.  I don't see why you should go to all the
trouble of merging profiles a process that takes months when registering
multiples across the H.248 would solve the problem. The other issues is
who would do this: the Super Profile Forum? ;-). It would just add
another profile to the list to be supported and we then have the same
problem.

> I also think a brief note on what profiles are intended to do
> (avoiding explicit rules) would be in order.  I think most of that
> material has also gone by in this thread.
>