Subject: Re: Profiles in Service Change

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 6 Sep 2000 07:42:00 -0400

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:38:40 +1100

G'Day Brian,

I think you've proved my point also. There are going to be multiple
profiles developed and the MSF won't be the only body in the world
having the mandate to do protocol definition.

Has John pointed out in email perhaps my example wasn't clear. By
mentioning SIP/H323/ISUP I was more alluding to the applications that
these would support. The MG should have no knowledge of the Call Control
Protocol but it was support the services that these Call Control
Services provide.

The solution you propose still doesn't get over the case where the MG
needs to use 2 profiles. ie. ISUP/BICC Services on one side and VoDSL
access on the other side.

Cheers, Christian