Subject: Re: Profiles in Service Change

From: Peter Blatherwick <[email-masked]>
Date: Wed, 6 Sep 2000 12:42:59 -0500

A couple of points to add to the below (I agree with reasoning and 1 profile
at a time rule):

I do not expect profiles to completely get around auditing, merely make it a
whole lot easier and more reliable.  If termination/package structure,
minimum package support, naming conventions and so on are all agreed
implicitly by the MGC accepting a profile, then audits are used only to find
out what else a particular MG does, and audits can be much more specifically
directed.  If an MGC wants to only support the minimum function, there may
be no audits required at all in some cases (not the case in IP Phone BTW --
would still need to audit specific UI widgets supported by the UI
termination).

In the example of a Fax IP Phone, an alternative to creating a new profile
extending IP Phone is for the device just to support the IP Phone profile
and use MGC audits to discover there is additional fax support in the MG.
(Not too sure just what hypothetical package(s) we would need to add to make
this so, but no worries about that here.)  As long as the Fax IP Phone
device follows the basic structure and rules of IP Phone, I don't see any
interoperability trouble or ambiguity.

Also, to re-iterate an earlier point, if we take it as given that profiles
can define such things as assumed termination/package structure and naming
conventions, then arbitrary mixing of multiple profiles is much more than
understanding minimum required package support, and is a much trickier
problem.  Mutually incompatible assumptions may be made by the multiple
profiles, and then how to sort out the resulting ambiguity in the MGC and
MG?  Yeti.  Without rules for profile definition we have no way to sort this
out for multiple simultaneous profiles.  With the one profile at a time
rule, the problem does not exist and yet we can still extend using
additional packages within the overall structure defined by that profile.

If it is desirable to create profiles that extend others (I think this would
be a good thing), I submit we need to define formal definition rules to
specify how this works, along the lines of what we did with packages.  To my
mind this would be an extension of the Megaco/H.248 Protocol, for version 2,
not a job for the Implementer's Guide.  Same goes for re-defining profile in
ServiceChange -- must be tied to specific rules.

-- Peter

-----Original Message-----
From: Rosen, Brian [mailto:[email-masked]]
Sent: Wednesday, September 06, 2000 11:04
To: [email-masked]
Subject: Re: Profiles in Service Change

I think that if we need to have faxphones, then we need
a profile for them, and there should be one way to do that,
which would be an extension of the Ipphone profile.

The real issue is, suppose you only had an MGC available that
DID understand Ipphone, but did NOT understand Ipfaxphone.

What is the right thing to do?
 a) fail, because you can't fax, and a user may expect that
 b) use the Ipphone protocol and cause a local error if
        a user tried to fax
 c) have local action (provisioning, or local configuration)
        that disables the fax function
I'm not really sure what the best answer is.  It's not
obvious to me that there IS a good answer.  It's good to
use the lowest common denominator to get service, but you
really ought to disable fax at the local terminal (which
could downgrade the profile).

I do think you have raised another issue worth discussing,
which is:
        Should we create a new profile to add one feature,
                or should MGCs audit always?

This also seems to me to not have an ideal answer:
  Making tons of profiles to add features is clearly going to
  give us lots of non-interoperable devices

        but

  auditing removes any usefulness of profiles for actual
  operation of the protocol

Brian

> -----Original Message-----
> From: John Segers [mailto:[email-masked]]
> Sent: Wednesday, September 06, 2000 10:48 AM
> To: [email-masked]
> Subject: Re: Profiles in Service Change
>
>
> I agree to the underlying idea that profiles could be used to restrict
> fragmentation.  On the other hand, I think that Christian has a point.
> His example may have been unfortunate because it mentioned a call
> signaling protocol, but the point is valid.
>
> Suppose that I want to build a MG that supports the IPphone
> profile, and
> I also build in IP fax support.  If my MG signals that it supports the
> IPphone profile, the MGC infers that this MG supports a certain set of
> packages and maybe some things that are optional in the base megaco
> protocol.  It doesn't have a reason to audit the MG and find
> out that it
> can also do IP fax.  So how do I get the MGC to use the fax support
> (other than by provisioning the MGC with this information)?
>
> John
>
> Flemming Andreasen wrote:
> >
> > OK - I'll buy that.
> >
> > -- Flemming
> >
> > "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
> > > >
> > > >
> >
> > --
> > Flemming Andreasen
> > Cisco Systems
>
> --
> John Segers                                  email: [email-masked]
> Lucent Technologies                                        Room HE 303
> Dept. Forward Looking Work                      phone: +31 35 687 4724
> P.O. Box 18, 1270 AA  Huizen                      fax: +31 35 687 5954
>

---

From: Christian Groves <[email-masked]>
Date: Thu, 7 Sep 2000 11:16:14 +1100

G'Day Pete,

Some comments below marked [CHG]

Cheers, Christian

Peter Blatherwick wrote:
>
> A couple of points to add to the below (I agree with reasoning and 1
> profile at a time rule):
>
> I do not expect profiles to completely get around auditing, merely
> make it a whole lot easier and more reliable.  If termination/package
> structure, minimum package support, naming conventions and so on are
> all agreed implicitly by the MGC accepting a profile, then audits are
> used only to find out what else a particular MG does, and audits can
> be much more specifically directed.  If an MGC wants to only support
> the minimum function, there may be no audits required at all in some
> cases (not the case in IP Phone BTW -- would still need to audit
> specific UI widgets supported by the UI termination).
>
> In the example of a Fax IP Phone, an alternative to creating a new
> profile extending IP Phone is for the device just to support the IP
> Phone profile and use MGC audits to discover there is additional fax
> support in the MG.  (Not too sure just what hypothetical package(s) we
> would need to add to make this so, but no worries about that here.)
> As long as the Fax IP Phone device follows the basic structure and
> rules of IP Phone, I don't see any interoperability trouble or
> ambiguity.

[CHG] You are assuming the MG has IPPhone Profile. Say I have a class of
MG that only has IPFax support and thus an IPFax Profile. Suddenly in
the world I have an IPPhone Profile and a IPFax Profile. As a vendor or
operator I think an MG having both IPPhone and IPFax is pretty cool. I
turn to the two profiles and want both in my gateway. Suddenly the MG
supports 2 profiles which could be used by the same MGC. The alternative
is an IPPhone-Fax profile but now we have 3 profiles.

Does anyone see why I'm worried if we don't have something explaining
what to do?

>
> Also, to re-iterate an earlier point, if we take it as given that
> profiles can define such things as assumed termination/package
> structure and naming conventions, then arbitrary mixing of multiple
> profiles is much more than understanding minimum required package
> support, and is a much trickier problem.  Mutually incompatible
> assumptions may be made by the multiple profiles, and then how to sort
> out the resulting ambiguity in the MGC and MG?  Yeti.  Without rules
> for profile definition we have no way to sort this out for multiple
> simultaneous profiles.  With the one profile at a time rule, the
> problem does not exist and yet we can still extend using additional
> packages within the overall structure defined by that profile.

[CHG] I think the only imcompatibility problems lie in the transport and
encoding. The MGC will use the relevant Packages and naming conventions
for the operation it wants. The MG just executes the commands. I
completely agree some rules are needed for profile definition.

>
> If it is desirable to create profiles that extend others (I think this
> would be a good thing), I submit we need to define formal definition
> rules to specify how this works, along the lines of what we did with
> packages.  To my mind this would be an extension of the Megaco/H.248
> Protocol, for version 2, not a job for the Implementer's Guide.  Same
> goes for re-defining profile in ServiceChange -- must be tied to
> specific rules.

[CHG] Profile extension to me is a little weird. I'd rather stop at
packages. We have the whole issue of registering names, backwards
compatibility etc. to deal with. But I do think we need some guide on
this now.

---

From: John Segers <[email-masked]>
Date: Thu, 7 Sep 2000 10:21:00 +0200

Pete,

I share your view that profiles cannot completely obviate the need for
auditing.  My concern is that they don't alleviate this need at all with
the current mechanisms for profiles (allowing only one) and auditing
(allowing an MGC to audit which packages are supported).

Actually, I think that there are two issues:
- If an MG reports that it supports a profile, the MGC knows about a set
  of packages that is supported and maybe some extra information
  (like termination naming).  The MG cannot indicate that it supports
more
  functionality than that defined in the profile.  So if there are MGs
and
  MGCs that support functionality beyond the profile, such MGs _always_
  have to audit to find out.
- A gateway has to sides.  Consider, for instance an ISDN to BICC GW.
  It is not unreasonable to define a profile for the ISDN terminations,
  including a naming scheme.  It is also not unreasonable to define a
  profile for the BICC network side.  If both profiles specify anything
  beyond the sets of packages that has to be supported, auditing may not
  give the MGC the capability to find out about this.

  It looks to me like we either have to restrict profiles to be no more
  than sets of packages, or we allow profiles to define more than this
  and find a way to convey information about supported functionality
  beyond sets of packages.

Cheers,

John