Subject: Re: Profiles in Service Change

From: Peter Blatherwick <[email-masked]>
Date: Mon, 11 Sep 2000 11:19:22 -0500

A delayed G'Day back Christian:

I believe most of your queries on the below post were already answered one
way or another, so I snipped liberally.  If not satisfied, please post them
again.  I only touch on a couple of the points here, [PB].

-- Peter

-----Original Message-----
From: Christian Groves [mailto:[email-masked]]
Sent: Wednesday, September 06, 2000 19:51
To: Blatherwick, Peter [CAR:AT14:EXCH]
Cc: [email-masked]
Subject: Re: Profiles in Service Change

G'Day Pete,

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

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

[PB] Key difficulty is overlapping assumptions in the multiple profiles
being in conflict with each other, or otherwise causing ambiguity.  Both MG
and MGC side would need to deal with this ambiguity, at some cost in
complexity, and (most alarming) by each making additional assumptions on how
to resolve the ambiguities.  Since we have no specific rules, result would
be potentially serious interoperability problems.

[PB] If for example profile X defines a naming convention for its
terminations which overlaps the convention used by profile Y, the MG cannot
resolve a command from the MGC without knowing which specific application (X
or Y) sent it in the first place.

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

[PB] I definitely agree (as above) we should supply some advice, not just
sweep it under the carpet. (The lump would be unsightly, and we'd keep
tripping over it ;-)   See outline just posted elsewhere on this thread for
what I believe should be in there.  Technical changes to properly support
what we have been discussing here would be well beyond a simple technical or
editorial change.  To properly address the issues, if we feel they truly
need to be addressed, will take some real effort.  For now, what we have in
place seems quite workable.

[PB} [snip]

---

From: Christian Groves <[email-masked]>
Date: Wed, 13 Sep 2000 14:01:24 +1100

G'Day Peter,

I don't believe that multiple profiles will as complex as you have
indicated below. For instance if you have a X profile one side of the
MGC/MG and a Y profile on the other side of the MGC/MG. The MGC wants a
certain access (X functionality) it will use the terminationID
structure/naming appropriate for that side of the MG. The MGC knows from
the profile which packages etc that termination supports.

I believe you highlighted my concerns by saying "Both MG and MGC side
would need to deal with this ambiguity, at some cost in complexity, and
(most alarming) by each making additional assumptions on how to resolve
the ambiguities." By having 2 or more profiles defined (I am aware of at
least 5 - Tiphon, MSF Trunking, MSF Access, IP Phone, BICC) this is what
we have now and it I would like to resolve this.

So I propose :
o updating the ASN1/ABNF to handle multiple profiles
o adding text to 7.2.8 to clarify what H248 means by neogitiation today.
   ie. what does the MG do if the MGC doesn't send back the profile?
stop? try another?
o some note on what a profile means to the MGC. Does it mean that the
MGC needed audit packages because the profile says which ones are
implemented? Can additional packages not in the profile be supported?
etc.

I'll formulate a more specific proposal later.

Cheers, Christian

Peter Blatherwick wrote:
> I believe most of your queries on the below post were already answered
> one way or another, so I snipped liberally.  If not satisfied, please
> post them again.  I only touch on a couple of the points here, [PB].
>
> -- Peter
>
> [PB] Key difficulty is overlapping assumptions in the multiple
> profiles being in conflict with each other, or otherwise causing
> ambiguity.  Both MG and MGC side would need to deal with this
> ambiguity, at some cost in complexity, and (most alarming) by each
> making additional assumptions on how to resolve the ambiguities.
> Since we have no specific rules, result would be potentially serious
> interoperability problems.
>
> terminations which overlaps the convention used by profile Y, the MG
> cannot resolve a command from the MGC without knowing which specific
> application (X or Y) sent it in the first place.
>
> > Your proposed
> [PB] I definitely agree (as above) we should supply some advice, not
> just sweep it under the carpet. (The lump would be unsightly, and we'd
> keep tripping over it ;-)   See outline just posted elsewhere on this
> thread for what I believe should be in there.  Technical changes to
> properly support what we have been discussing here would be well
> beyond a simple technical or editorial change.  To properly address
> the issues, if we feel they truly need to be addressed, will take some
> real effort.  For now, what we have in place seems quite workable.
>
> [PB} [snip]