Subject: Re: physical vs. ephemeral terminations

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 1 Feb 2001 09:45:20 -0500

Rosen's First rule of Provisioning - Provisioning is evil
Rosen's Second rule of Provisioning - Cross Provisioning (both MG and MGC)
        is monstrously evil

DON'T DO IT (Please)

Of course, nothing prevents you from making some proprietary MG and MGC that
requires this, but I have been quite adamant, and I think successfully,
that it is very reasonable to:
        Not have ANY knowledge of MG capability by MGC
                You can audit everything you need to know
        Never need ANY cross provisioning

So if Christian and his associates make MG/MGC pairs that need cross
provisioning, they certainly might be completely Megaco compliant, but
a customer may or may not wish to deal with such complexity.  Of course,
unless that cross provisioning was standardized by someone, it would be
completely proprietary.

A compliant Megaco implementation has to handle CHOOSE.  It is a little
tricky, but not much, to determine the characteristics of the
termination from the descriptors.  It is required that an MG do so.

We can argue about what error to return, and we need to come to agreement
about that.

If you design an MG to not have a relationship between the terminationID
schema and the packages implemented on the terminations, then you force the
MGC to audit each termination separately.  MGCs will always need a flexible
representation mechanism - this is a degenerate case, but it will work,
albeit inefficiently.  If you intelligently name your terminations, then
the MGC's database will be very compact.  I expect to see most profiles
specify compact naming schemes for this reason.

Brian

> -----Original Message-----
> From: Christian Groves [mailto:[email-masked]]
> Sent: Wednesday, January 31, 2001 9:40 PM
> To: [email-masked]
> Subject: Re: physical vs. ephemeral terminations
>
>
> G'Day Troy,
>
> I think you have to make the assumption that the MGC knows something
> about the MG. It can audit terminations to find out the capabilities
> supported. If the MGC asks a particular termination to do something
> that's not supported then the 44"x" ie. 445 unsupported property could
> be returned.
>
> I don't think the MG is as dumb as some people try to make
> out and there
> will have to be a number of things provisioned in both the
> MGC and MG to
> make this all work. We didn't document all this because if
> there are 200
> companies represented on this list I'm sure you'd have 300 different
> view (and yes I meant 300 :) )
>
> Cheers, Christian
>
> Troy Cauble wrote:
> >
> > Tom Taylor wrote:
> >
> > > >What is the error returned if an MG is asked to do something
> > > >it doesn't support (or doesn't even make sense) on that type
> > > >of termination?
> > > >        If it's asked to detect hook flash on an ephemeral
> > > >        termination?
> > >
> > > [PTT]
> > > 440 Unsupported or unknown package
> > >
> > > >        If it's asked to apply Local or Remote Descriptors
> > > >        to a physical termination?
> > >
> > > [PTT]
> > > Not an error, though the I-D describing SDP naming
> conventions (SDP nettype, addrtype) for TDM circuits has to
> be written.  You
> > > need the descriptors to describe the codec (as Madhue has
> pointed out) and the bearer capability.
> >
> > Tom,
> >
> > Well, it's an error for a POTS line.  What's the error code
> for that?
> > (Don't say 440; we're not talking about packages here.)
> >
> > >
> > > >
> > > >This seems to indicate a whole class of syntactically correct,
> > > >but nonsensical combinations.
> > >
> > > [PTT]
> > > Error code 440 covers a lot of it.
> >
> > But not all :(
> >
> > > >Also, it seems that given a termination id of CHOOSE, an MG must
> > > >traverse descriptors looking for clues that indicate whether it
> > > >should CHOOSE an ephemeral or physical termination.  Correct?
> > > >What if there is no forcing hint?
> > >
> > > [PTT]
> > > I gave my own answer to that a while ago.  Basically the
> termination is treated as an empty software container waiting
> to be filled
> > > with detail.
> >
> > This makes for nice viewgraphs, but difficult implementations :(
> >
> > >
> > > >
> > > >        A termination id schema must clearly distinguish between
> > > >        physical and ephemeral so the MGC knows how to pick a
> > > >        termination associated with some physical attribute
> > > >        (such as "POTS line 7"), yes?
> > >
> > > [PTT]
> > > It has been pointed out that there is no necessary
> association between termination type and name, even if the
> latter is based on a
> > > physical schema (e.g. shelf/slot). It might be possible
> to insert various card types (ATM, TDM, ethernet) into the same slot.
> >
> > I guess you're saying that the schema doesn't have to
> > explicity distinguish between termination types, as
> > long as the MGC and MG both know the mapping.  Correct?
> >
> > So a schema could be simply integers 1-1000, and the MGC just
> > knows that the POTS line to my house is 37, while 36
> > and 38 are to be used for RTP streams?
> >
> > Thanks,
> > -troy
>

---

From: Christian Groves <[email-masked]>
Date: Fri, 2 Feb 2001 17:17:02 +1100

G'Day Brian,

CHOOSE is applicable in a provisioned network.

Are you saying that all the operators who have provisioning in their
network are Evil? For myself and "associates" (whoever they may be)
developing MGC/MGs that handle multiple million termination systems, it
would surprise me if any vendor has sold an implementation to an
operator that had no provisioning at all. If fact if there was such a
system it would be completely non-standard proprietory as nothing has
been defined as standard yet. Having the MGC discover the names of
terminationIDs doesn't solve all your provisioning problems. Operator
certainly don't like uncertainty in their networks. They like
predictable behaviour. They won't stick a box in their network turn it
on and hope for the best and let it auto configure. Residential MG users
may want this.

Finding having no provisioning on a 2 termination MG may be completely
achievable but as the complexity of a system increases so does the
need for provisioning.

I think you and I will have to agree to disagree on this one (again).

Cheers, Christian