Subject: Re: Profiles in Service Change

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 5 Sep 2000 08:13:58 -0400

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, 6 Sep 2000 15:36:24 +1100

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