Subject: Re: Profiles in Service Change

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 7 Sep 2000 14:02:36 -0400

I proposed a way (not a wonderful way, but a way) to have
an MG that has multiple profiles find an MGC to serve it.
It won't work if you literally mean supporting two profiles
at the same time.  I don't think that is a problem worth
solving at this time.  Your example - VoDSL and BICC was
an unfortunate choice, because you can predict my answer:
        Neither VoDSL, nor BICC should be profiles

If someone wanted to define a profile for a residential
gateway with a DSL uplink supporting POTS lines, I think that
would be a useful profile.  If someone wanted to define
a profile for a gateway that switched AAL2 subchannels from LES Phase II
VoDSL devices into a distributed Class 5 VoATM
environment, I think that would be a useful profile.
The idea that anything related to BICC (an MGC-MGC protocol)
should be visible in a Megaco/H.248 profile strikes me
as a very bad idea.

Brian

> -----Original Message-----
> From: Christian Groves [mailto:[email-masked]]
> Sent: Wednesday, September 06, 2000 7:39 PM
> To: Rosen, Brian
> Cc: [email-masked]
> Subject: Re: Profiles in Service Change
>
>
> 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
>
> "Rosen, Brian" wrote:
> >
> > 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: Wed, 13 Sep 2000 14:07:08 +1100

G'Day Brian,

I know that BICC profiles upsets you. Perhaps I should be a
little more abstract Application Set "A" and Application Set "B"? One
set of services/applications residing on each side of the gateway. These
services/applications will require some different information elements
to be sent over the vertical.

I think the one profile for all is noble but who would do a SIP
Application Set "a" to BICC Application Set "b" and H.323 Application
Set "c". Is it MSF, ITU SG11, ITUSG16, Softswitch, Tiphon? They all have
an interest in doing something with H.248 and no doubt it will be a huge
political fight if they are to agree on one profile. I might take
holidays for the 2 years they fight it out :-).

I'd prefer to support profiles A, B and C rather than profiles (AB, AA,
BB, AC, CC, BC, ABC etc) in my MG.

I know I'm not going to convince you that other bodies will do
applications but I believe the reality is that there will be a
multiplicity of profiles at the same time and that we need to come up
with something which allows this. This time is appropriate because we
know it will happen and I'd rather be proactive rather than trying to
solve the mess once it occurs.

Cheers, Christian