Subject: Profiles in Service Change

From: Christian Groves <[email-masked]>
Date: Tue, 5 Sep 2000 11:58:08 +1100

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: Peter Blatherwick <[email-masked]>
Date: Tue, 5 Sep 2000 09:49:55 -0400

Formal rules for what a profile can and cannot specify are not currently
defined.  At one point, I proposed some rules, but these turned out to be
contentious, were not agreed, and have not been followed up. This issue was
deferred to later version of the Megaco/H.248 Protocol in the Washington
meeting last year, if I recall correctly, and left at the 1 profile rule we
currently have in place.  Without these formal rules, it is difficult to
know what the effect of allowing multiple profiles would be.  Therefore, I
think its better *for now* to stick with a single profile.  I don't consider
it an error, but actually an intentional decision.

Several side effects of allowing multiple profiles would be difficult to
sort out.  For example, profiles can (and I believe in many cases absolutely
must) specify which optional aspects are used by the MG side, for example
making specific selection on encoding and transport.  Profiles may also
define specific termination organization, naming conventions etc.  If an MG
supports 2 or more profiles, and these do not each make the same selections
or assumptions, how to sort out which are actually in use?  This quickly
becomes a deep rat hole, and could add enormously to the complexity of both
MG and MGC applications, while not helping interoperability (maybe even
hurting it).  This defeats the intent of profiles -- to improve
interoperability and provide simplifying assumptions for specific
applications of the Protocol.

Since profiles essentially define particular applications of the
Megaco/H.248 Protocol, what the current rule is really saying is an MG
supports 1 application if it uses a profile to declare this to its
controlling MGC.  Of course, multiple virtual MGs could still be in
operation on the same physical device, or profiles could be defined which
capture more than one application, so there are ways around this.

Looking forward a bit, to definition of the profile rules, one possible
approach would be to provide a formalism for profiles to be extended and/or
versioned, similar to the sub-classing-like approach used by package
definition now.  This would mean we could build profiles on each other
without having contentions over optional elements.

I remain quite interested in this topic, and feel this would be a good thing
to include in any extension of the Megaco WG's charter for consideration in
version 2 (once some version 1 implementation experience is gained of
course).

For implementor's guide, I suggest some explanatory text on what profiles
are intended to do would be in order, but don't think the implementor's
guide should modify the Protocol.

-- Peter Blatherwick

-----Original Message-----
From: Christian Groves [mailto:[email-masked]]
Sent: Monday, September 04, 2000 20:58
To: [email-masked]
Subject: Profiles in Service Change

G'Day all,

7.2.8 ServiceChange

A.2

        ...
}

B.2

Cheers, Christian

---

From: Christian Groves <[email-masked]>
Date: Wed, 6 Sep 2000 15:29:36 +1100

G'Day Peter,

I agree that the Profile mechanism isn't really well defined. I do see
that these will need to be defined shortly. With different
standardisation bodies working (MSF, ITU SG11, DSL Forum, 3gPP etc.
etc.) on different profiles and packages, multiple profiles are going to
be a reality very shortly.

Please see specific comments below [CHG]

Cheers, Christian

Peter Blatherwick wrote:
>
> Formal rules for what a profile can and cannot specify are not
> currently defined.  At one point, I proposed some rules, but these
> turned out to be contentious, were not agreed, and have not been
> followed up. This issue was deferred to later version of the
> Megaco/H.248 Protocol in the Washington meeting last year, if I recall
> correctly, and left at the 1 profile rule we currently have in place.
> Without these formal rules, it is difficult to know what the effect of
> allowing multiple profiles would be.  Therefore, I think its better
> *for now* to stick with a single profile.  I don't consider it an
> error, but actually an intentional decision.
>
> Several side effects of allowing multiple profiles would be difficult
> to sort out.  For example, profiles can (and I believe in many cases
> absolutely must) specify which optional aspects are used by the MG
> side, for example making specific selection on encoding and
> transport.  Profiles may also define specific termination
> organization, naming conventions etc.
[CHG] Yes I agree. I think the MSF IAs and BICC profile start to do
this.

> If an MG supports 2 or more
> profiles, and these do not each make the same selections or
> assumptions, how to sort out which are actually in use?

[CHG] I would have thought that a profile is tied to an application. ie.
if the MGC is using BICC then it would pick the BICC profile for that
part of the call. If the network side was BICC and the access was
Ipphone then it would pick the IP phone Profile to handle the access.

> This quickly
> becomes a deep rat hole, and could add enormously to the complexity of
> both MG and MGC applications, while not helping interoperability
> (maybe even hurting it).  This defeats the intent of profiles -- to
> improve interoperability and provide simplifying assumptions for
> specific applications of the Protocol.
[CHG] I still believe it does provide this. It still specifies for a
particular application what options and packages you use. I don't
believe equipment is limited to one application.

> operation on the same physical device, or profiles could be defined
> which capture more than one application, so there are ways around
> this.
[CHG] I'd be interested in exploring this a little further. Can you give
more details?

>
> Looking forward a bit, to definition of the profile rules, one
> possible approach would be to provide a formalism for profiles to be
> extended and/or versioned, similar to the sub-classing-like approach
> used by package definition now.  This would mean we could build
> profiles on each other without having contentions over optional
> elements.
[CHG] Again I agree that as soon as we start developing profiles that we
should consider future changes. However with the limits of the profile
mechanism as it is now should we just give up on signalling the profile
and just rely on the documentation of the functionality in the profile
to provide interoperability. Just use packages as Brian alluded to.

>
> I remain quite interested in this topic, and feel this would be a good
> thing to include in any extension of the Megaco WG's charter for
> consideration in version 2 (once some version 1 implementation
> experience is gained of course).
>
> For implementor's guide, I suggest some explanatory text on what
> profiles are intended to do would be in order, but don't think the
> implementor's guide should modify the Protocol.
[CHG] Yes we could put some text in the implementor's notes section.

---

From: Tom-PT Taylor <[email-masked]>
Date: Wed, 6 Sep 2000 08:54:19 -0400

This conversation is bringing out a number of requirements for an effective
profile system.  When we sum them up perhaps we can review the situation and
see whether the protocol needs further development or whether we can make do
with the tools at hand.

> Sent: Wednesday, September 06, 2000 12:30 AM
> Subject: Re: Profiles in Service Change
>
>
> G'Day Peter,
>

---

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 6 Sep 2000 09:10:44 -0400

We can also look at profiles being written, to see how
they come out.  We might want to have some text somewhere
with advice, rather than rules.

We have had some fun with the MSF profiles; since there are
no rules, we have asked ourselves, several times, "well,
what should be in here?  What should not?"

I think they are coming out very well.  They will be public
very soon (in draft form), for others to look at.  The IPphone
profile is another to use.  The PacketCable stuff can also
be mined for ideas.

Brian

> From: Tom-PT Taylor [mailto:[email-masked]]
> Sent: Wednesday, September 06, 2000 8:54 AM
> > > I discussion on another email exploder (MSF) it was
> pointed out that
> > > the

---

From: "Petros N. Mouchtaris" <[email-masked]>
Date: Wed, 6 Sep 2000 09:22:37 -0400

The MSF profiles are now out on the MSF Web site (www.msforum.org).
The documents are:
http:// www.msforum.org/MSF-MEDIA-001.00-DRAFT_IA
http:// www.msforum.org/MSF-MEDIA-002.00-DRAFT_IA

I have been planning to send out a more formal announcement.
Do you think we should also do internet drafts to make them easily accessible to
people?

Petros

"Rosen, Brian" <[email-masked]> on 09/06/2000 09:10:44 AM

Please respond to "Rosen, Brian" <[email-masked]>

To:   [email-masked]
cc:    (bcc: Petros N. Mouchtaris/Telcordia)
Subject:  Re: Profiles in Service Change

Brian

---

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

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

> From: John Segers [mailto:[email-masked]]
> Sent: Wednesday, September 06, 2000 10:48 AM
> 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
> > >
> > > > 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
> > > > 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: Tom-PT Taylor <[email-masked]>
Date: Wed, 6 Sep 2000 12:22:49 -0500

How about the thought that a profile presents the bulk of an MG's
capabilities, but the MGC has to audit to find out what additional packages
it supports?

---

From: Peter Blatherwick <[email-masked]>
Date: Wed, 6 Sep 2000 13:47:57 -0400

(Oops -- ships that cross in the night problem.)

Yes, I agree this is a viable approach, and will be used in many cases.
Profiles can greatly simplify this process.  I think "has to" (as in MUST)
may be too strong.  See response in another part of this thread, just
posted.

-- Peter

---

From: Peter Blatherwick <[email-masked]>
Date: Mon, 11 Sep 2000 10:35:06 -0500

Hi John, all:

First, I would like to emphasize I DO see rules for use and definition of
profiles as being important.  But I do not see the Implementer's Guide as
the place for it.  It would constitute an extension work to Megaco/H.248
Protocol, therefore a version 2 topic.  This is essentially what we decided
in Washington.  I believe what we have now is workable in the immediate
future, and both Brian and I have proposed ways to work with it that I think
cover the major cases.

Some specific responses below [PB], and more to follow on other parts of
this thread.  (And sorry for the delayed responses.)

-- Peter

-----Original Message-----
From: John Segers [mailto:[email-masked]]
Sent: Thursday, September 07, 2000 04:21
To: [email-masked]
Subject: Re: Profiles in Service Change

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).

[PB] Yes, in general profiles cannot completely obviate audits, only when
MGC assumes only the minimal functionality specified by the profile.
However, profile can greatly reduce auditing, and can supply a lot of other
valuable information about MG organization, so are extremely powerful
enablers of interoperability, complementary with packages and audits.

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.

[PB] Agree discovery of added non-package functionality would be nice to
solve.  Profiles do this for specific applications.  Difficult question is
how to solve this for multiple simultaneous applications.

- 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.

[PB} (Attempting to leave BICC etc out of it ;-)  If more than one profile
specifies more than package support, there may be conflicting assumptions,
and ambiguity results.  This is the core problem with multiple profiles.  I
don't think we're disagreeing here, just saying things differently.

  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.

[PB] I do not agree here.  Profiles specifying naming conventions, assumed
termination/package organization etc is extremely useful.  Defining only
sets of packages is insufficient.  What we have now is workable for many,
many current cases, so don't think we should restrict it.  Nor do I think we
currently have a good solution for auditing (or otherwise) to discover
non-package extended functionality.  While the latter problem *might* be
well solved by allowing multiple profiles, without deep thought and clear
definition of profile specification rules and rules around what it means to
register more than one profile at a time, we leave ourselves very open to a
big mess of ambiguity.  These topics are valid, but beyond the scope of what
I would see as an Implementer's Guide.  (Let's remember that's where this
started.)

Cheers,

John

> 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.
>
> 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
>
> From: Rosen, Brian [mailto:[email-masked]]
> Sent: Wednesday, September 06, 2000 11:04

---

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 13 Sep 2000 09:49:47 -0400

Well we are going to have to agree to disagree on more than
BICC.  I would say our views on what is a profile differ
in that I don't think a profile is used for an "application"
I think a profile is used for an MG.

So, you might have a profile for a residential POTS gateway to
an ATM uplink, or an Access gateway on an IP system.  Although
you can have profiles with options, I'd discourage them in most
cases.  So I don't think profiles are used for menus of "choose
one from column A and one from column B".  I think the "sides"
of the gateway are covered in one profile.  That is what we
are doing at MSF, that is what the PacketCable guys did with
their MGCP profiles.  I think that is a good model.

Brian

> From: Christian Groves [mailto:[email-masked]]
> Sent: Tuesday, September 12, 2000 11:07 PM
> To: Rosen, Brian
> Cc: [email-masked]
> 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
>
> "Rosen, Brian" wrote:
> >
> > 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
> >
> > > From: Christian Groves [mailto:[email-masked]]
> > > Sent: Wednesday, September 06, 2000 7:39 PM
> > > To: Rosen, Brian
> > > Cc: [email-masked]
> > > 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.
> > > >
> > > > > From: Christian Groves [mailto:[email-masked]]
> > > > > Sent: Wednesday, September 06, 2000 12:36 AM
> > > > > To: Rosen, Brian
> > > > > Cc: [email-masked]
> > > > > G'Day Brian,
> > > > > 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
> > > > > >
> > > > > > > Sent: Monday, September 04, 2000 8:58 PM
> > > > > > > I discussion on another email exploder (MSF) it
> was pointed
> > > > > > > out that the