Subject: Re: Profiles in Service Change

From: Peter Blatherwick <[email-masked]>
Date: Wed, 6 Sep 2000 09:00:47 -0500

Like Brian, I'm not sure we aren't all actually saying nearly the same thing
in different ways.

The confusion happens when an MG attempts to use more than one profile
within any particular control association with an MGC (corresponds to
Service Change registration).  For an MG to support more than one profile,
registering only one at a time through ServiceChange, is not a problem
(solves multiple carrier-specific profiles and also multi-purpose MG Brian
points to).  For an MG device to support multiple virtual MGs, each with
different single profiles at any given time is also not a problem (another
way to solve multi-purpose MG).  MGCs can certainly support multiple
profiles, no problem there either as long as the SW keeps a clean
separation.

Confusion only occurs when there is more than one profile in operation at a
time between MGC-MG pairs.  Allowing this I think will lead to trouble at
least until clean, clear profile definition rules are defined.  (Even then
I'm not entirely convinced.)  Your proposed change, as I understood it,
would allow for multiple profiles to be registered by the MG side at
ServiceChange, hence I do not agree we should do that in the Implementer's
Guide.  Would like some basic discussion of above points captured though.

-- Peter

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

Actually, except for the unfortunate plan to develop an
profile for BICC, I think you are proving my point.
A trunk gateway conforming to the MSF Trunk Gateway Profile
could be used by an MGC that used any of your listed protocols
to communicate with another MGC.  The idea that the MG should
have to know what the interMGC protocol is strikes me
as a VERY bad idea.

The IPphone is an MG profile, and a phone conforming to the
Ipphone profile could be used with an MGC that used H.323,
SIP, BICC or other interMGC protocols.

I do believe that there will be some "private" profiles.
A carrier for example, might develop a profile, and demand
that vendors conform to it.  That might lead a vendor to
support more than one profile in an MG, but I suspect that
such use will depend on a lot of provisioning anyway, and
will thus not be a problem for the MG.  I also suspect there
will be a couple of competing profiles for common gateway
types, which might cause some confusion for a while.

Finally, I suspect that many vendors will have private profiles
which would make use of some special capabilities, but are otherwise
supersets of a more "standard" profiles.  If such
vendors can get MGCs to support them, fine.  Otherwise
such profiles will not fare well in the market.

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.

Brian

> -----Original Message-----
> From: Christian Groves [mailto:[email-masked]]
> Sent: Wednesday, September 06, 2000 12:36 AM
> To: Rosen, Brian
> Cc: [email-masked]
> Subject: Re: Profiles in Service Change
>
>
> G'Day Brian,
>
> So does that mean that nobody can make an MG which supports more than
> one profile? :-)
>
> This seems to be a pretty big limitation to me. I know
> several companies
> are developing MGs that are capable of being used in many different
> scenarios. If one MGC can support H323-SIP, Sip-BICC, BICC-ISUP, VoDSL
> Access, IpPhone, BICC-3gPP and the permutations of these I
> don't see why
> the MG can only support one profile. I don't see that the
> development of
> one profile to support all these possibilities is realistic
> but I do see
> that a MG could support as these different accesses.
>
> In the real world MGs will support multiple profiles and I
> think we need
> to give advise in the Implementor's guide how this fits in with the
> limited profile mechanism we have in H248v1.
>
> Cheers, Christian
>
> "Rosen, Brian" wrote:
> >
> > I do NOT consider it to be an error, and I think the whole idea
> > of Profile is that an MG implements one.  The MGC, of course,
> > can implement many (if it serves several kinds of gateways).
> >
> > While such a restriction could lead to lots of private profiles,
> > it could also lead to a few commonly implemented profiles.
> > The package mechanism is a wonderful thing, but it leads to
> > lots of options, which leads to incompatible MGs and MGCs.
> > Profiles are the way to group options into implement able sets
> > so that MGs and MGCs can interoperate.
> >
> > If you have multiple profiles, then you might as well just
> > have no profiles - the ServiceChange could return the package list.
> >
> > Brian
> >
> > > -----Original Message-----
> > > From: Christian Groves [mailto:[email-masked]]
> > > Sent: Monday, September 04, 2000 8:58 PM
> > > To: [email-masked]
> > > Subject: Profiles in Service Change
> > >
> > >
> > > G'Day all,
> > >
> > > I discussion on another email exploder (MSF) it was pointed
> > > out that the
> > > ServiceChange only supports one profile to be returned. I
> would have
> > > thought that a MG could support more than one profile.
> > >
> > > Do people consider this to be an error to be updated in the
> > > implementor's guide?
> > >
> > >
> > > If so the following changes probably would be necessary.
> > >
> > > 7.2.8 ServiceChange
> > > The optional ServiceChangeProfile parameter specifies the
> Profile[/s]
> > > (if any) of the protocol supported.  The
> ServiceChangeProfile includes
> > > the version of the profile supported.
> > >
> > > A.2
> > > ServiceChangeParm ::= SEQUENCE
> > > {
> > >         serviceChangeMethod     ServiceChangeMethod,
> > >         serviceChangeAddress    ServiceChangeAddress OPTIONAL,
> > >         serviceChangeVersion    INTEGER(0..99) OPTIONAL,
> > > >>      serviceChangeProfile    SEQUENCE OF
> > > ServiceChangeProfile OPTIONAL,
> > >         serviceChangeReason     Value,
> > >         serviceChangeDelay      INTEGER(0..4294967295) OPTIONAL,
> > >                                     -- 32 bit unsigned integer
> > >         serviceChangeMgcId      MId OPTIONAL,
> > >         timeStamp               TimeNotation OPTIONAL,
> > >         nonStandardData         NonStandardData OPTIONAL,
> > >         ...
> > > }
> > >
> > > ServiceChangeResParm ::= SEQUENCE
> > > {
> > >         serviceChangeMgcId      MId OPTIONAL,
> > >         serviceChangeAddress    ServiceChangeAddress OPTIONAL,
> > >         serviceChangeVersion    INTEGER(0..99) OPTIONAL,
> > > >>      serviceChangeProfile    SEQUENCE OF
> > > ServiceChangeProfile OPTIONAL,
> > >         ...
> > > }
> > >
> > > B.2
> > > >>      serviceChangeProfile = ProfileToken EQUAL NAME
> SLASH Version
> > >
> > >
> > > Cheers, Christian
> > >
>
>

---

From: Christian Groves <[email-masked]>
Date: Thu, 7 Sep 2000 10:51:22 +1100

G'Day Pete,

Please see the dicussion of your points below marked [CHG]

Cheers, Christian

Peter Blatherwick wrote:
>
> Like Brian, I'm not sure we aren't all actually saying nearly the same
> thing in different ways.
>
> Service Change registration).
[CHG] Why?

> For an MG to support more than one
> profile, registering only one at a time through ServiceChange, is not
> a problem (solves multiple carrier-specific profiles and also
> multi-purpose MG Brian points to).

[CHG] This may not be a problem to do in the protocol but it is not
described anywhere. So far in the protocol we send "a" servicechange
with the profile.

> For an MG device to support
> multiple virtual MGs, each with different single profiles at any given
> time is also not a problem (another way to solve multi-purpose MG).

[CHG] Yes I agree it is a solution when the Virtual MG needs only to
cope with one profile and the over all physical MG has multiple
profiles. But if the Virtual MG needs to use 2 profiles then you have a
problem.

> MGCs can certainly support multiple profiles, no problem there either
> as long as the SW keeps a clean separation.

[CHG] Agreed. I don't see this as very hard because the MGC will use the
appropriate bits out of a profile for the functionality is wants.

>
> Confusion only occurs when there is more than one profile in operation
> at a time between MGC-MG pairs.  Allowing this I think will lead to
> trouble at least until clean, clear profile definition rules are
> defined.  (Even then I'm not entirely convinced.)

[CHG] Can you please explain why there is confusion?
To me an MGC knows what application it wants and will choose the
appropriate Profile along with the appropriate packages/properties etc.
The MG is just a slave to this so there should be no confusion there.
Isn't the ServiceChange profile more of a "hey this is what I support,
its up to you to use me how you want within these parameters" rather
than you shall do this.

> Your proposed
> change, as I understood it, would allow for multiple profiles to be
> registered by the MG side at ServiceChange, hence I do not agree we
> should do that in the Implementer's Guide.  Would like some basic
> discussion of above points captured though.

[CHG] I think its important to note that the Implementers Guide has 2
sections. One for Technical and Editorial Changes. Another Sections for
notes to guide Implementors which is non-normative ie. it won't appear
in the protocol. If we can't agree on a technical change (I still think
its worth discussing this) then we should at least offer some advice in
the advice section. So I don't want sweep this under the carpet by
saying we'll discuss it later because the later we leave it the bigger
problem this will be.