Subject: Re: physical vs. ephemeral terminations

From: Christian Groves <[email-masked]>
Date: Thu, 1 Feb 2001 13:40:08 +1100

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: Tom Taylor <[email-masked]>
Date: Thu, 1 Feb 2001 09:38:09 -0500

We have two choices: define more precise errors or interpret what we
have as best we can.  I draw people's attention to draft H.248 Annex L,
"Error codes and ServiceChange Reason Descriptions", currently to be
found at
ftp://standards.pictel.com/avc-site/till_0012/0011_Gen/H248_Annex_L.zip

Please look this over so we can comment at the next Rapporteur's meeting
in early March.

Troy Cauble wrote:
> Also, this sounds like an error for a package the MG
> doesn't support at all, not one it doesn't support on
> that termination type.
>
> -troy

---

From: Troy Cauble <[email-masked]>
Date: Thu, 1 Feb 2001 12:13:36 -0500

> view (and yes I meant 300 :) )

Christian,

Absolutely.  I agree that the MGC has to know something about the MG.

What I'm wrestling with now is the fact that the protocol allows the
MGC to pretend it doesn't know the Termination ID schema, and the MG
has to *deduce* what the MGC means.

Specifically, the MGC can tell the MG to Add CHOOSE termination
to a context and the MG has to figure out which termination, or
at least which TYPE of termination the MGC means.

Picture a gateway that handles many types of physical terminations
Add CHOOSE means that the MG has to walk through descriptor
properties as follows:

Property FOO is applicable to any of these four termination types.
Property BAR narrows the list to three termination types.
Property XYZ narrows the list to two termination types.

This is painful.

For many MGs there is the additional problem that we've still got
two possible types and returning an "empty vessel" termination is
not feasible, due to either an explicit schema that gives away the
type, or a mapping to types that is known to the MGC.  The mapping
may even go further than the *type* and be *addressing*, i.e. the
POTS line to customer X.

-troy