Subject: Re: Auditing of ephemerals

From: Christian Groves <[email-masked]>
Date: Mon, 31 Jul 2000 15:56:53 +1000

G'Day Brian and Flemming,

I see my idea of how to audit non-instantiated ephemerals isn't willing
too many supporters. I see 2 issues here. One is about naming schema and
is now being covered in another thread. The second is how to audit
euphemerals particularly non-instantiated euphemerals.

Following Brian's premise that all provisioning is evil and those that
do it should burn for eternity ;-). We need a way to audit the
capabilities of the terminations in a MG. For physical terminations no
problem as we have the NULL context. For euphemerals considering that
the MGC knows the naming pattern we still need to be able to find what
the termination can do, before we instantiate it. A euphemeral may not
physcially exist in hardware but it will still have capabilities and
values (packages) that are associated with it that can be used by the
MGC. You have to audit it or the other alternative is to provision and
not having to worry about heating for an eternity.

I provided a thought of how this could be acheived in my previous
emails. Does anyone else have an idea of how to do this?

Cheers, Christian

"Rosen, Brian" wrote:
>
> > > Firstly I agree that there's no requirement that ephemerals
> > are named
> > > RTP/* is was just an example. You'd know the naming pattern
> > before you
> > > did an audit.
> > >
> >
> > Actually, part of the point is that you do *not* know the
> > naming pattern, but
> > want to learn it. Seems there's no way to do that so we will have to
> > provision it.
> Yes, well there was a big mess about learning naming patterns.
> I had a suggestion, which was not accepted, no alternative
> was offered, and so there is no way to learn the naming pattern
> of any set of terminations.
>
> I think provisioning it is a very bad idea, but you have no
> alternative. Sigh.
>
> >
> > >
> > > Secondly I don't see what stops you doing a wildcard audit
> > (particularly
> > > an audit capability) on non instantiated ephemerals.
> >
> > How can you audit something that doesn't exist ?
> I agree, you can't
>
> >
> > > If you use
> > > ContextID ALL, wildcard the termination and ask for
> > wildcard response
> > > then you should be able to get whats wanted. The spec
> > doesn't disallow
> > > this.
> >
> > I think it does. The command is to be tried on all
> > terminations matching the
> > wildcard, so what do you do when there are no instantiations of some
> > ephemeral termination type - I would expect nothing.
> As would I
>
> >
> >
> > > You have to be able to do an auditvalue to see the value of the
> > > packages that relate to the ephemeral.
> >
> > On an instantiated ephemeral - yes, but on an non-existent ephemeral ?
> >
> > >
> > >
> > > Cheers, Christian
> > >
> > > "Rosen, Brian" wrote:
> > > >
> > > >  I don't agree with this answer.
> > > >
> > > > First of all, I don't think it is possible to do a wildcard audit
> > > > of RTP/* unless there are some terminations that match
> > (instantiated)
> > > >
> > > > Second, there is no requirement that rtp ephemerals are
> > named RTP/*
> > > >
> > > > I think the answer is what I said, you audit packages.
> > > > If there are more than one "rtp" package, so what, if your MGC
> > > > implements a package that does some kind of rtp, then you
> > can create
> > > > rtp ephemerals.
> > > >
> > > > I'm not sure how you ever get into trouble here, because while I
> > > > can see extending rtp (or atm), I can't see replacing it, and then
> > > > having an MG implement two kinds of rtp.  If they did, there would
> > > > have to be something in SDP, or a parameter in LocalControl or
> > > > TerminationState which told the gateway which one to create.
> > > >
> > > > Brian
> > > >
> > > > -----Original Message-----
> > > > From: Christian Groves
> > > > To: [email-masked]
> > > > Sent: 7/26/00 2:04 AM
> > > > Subject: Re: Auditing of ephemerals
> > > >
> > > > G'Day Flemming,
> > > >
> > > > By auditing rtp/* and asking for a wildcard response it
> > will give you
> > > > the packages and properties for that class of termination
> > without the
> > > > need for instantiating each of the euphemeral terminations.
> > > >
> > > > Naming schemes can be provisioned to a certain extent and
> > then auditing
> > > > can give you the characteristics of named terminations.
> > > >
> > > > Cheers, Christian
> > > >
> > > > Flemming Andreasen wrote:
> > > > >
> > > > > "Rosen, Brian" wrote:
> > > > >
> > > > > >  You audit packages.  For example, if the MG
> > implements RTP, then
> > > > > > it implements the RTP package.  Same with ATM.  You
> > audit packages
> > > > of
> > > > > > the whole gateway, of course.
> > > > > >
> > > > >
> > > > > That doesn't sound particularly foolproof - who's to
> > say I want to
> > > > implement
> > > > > *the* RTP package or *the* ATM package, etc.
> > Nevertheless, it still
> > > > leaves
> > > > > me with a couple of questions:
> > > > >
> > > > > 1. How do I figure out the naming scheme used for these
> > ephemeral
> > > > > terminations, e.g. "rtp/{1,2,3,4}" ?
> > > > > 2. If I have more than one type of ephemeral
> > termination supported,
> > > > how do I
> > > > > figure out which one support what packages (without
> > instantiating one
> > > > of
> > > > > course).
> > > > >
> > > > > -- Flemming
> > > > >
> > > > > >
> > > > > > Brian
> > > > > >
> > > > > > -----Original Message-----
> > > > > > From: Flemming Andreasen
> > > > > > To: [email-masked]
> > > > > > Sent: 7/25/00 6:20 PM
> > > > > > Subject: Auditing of ephemerals
> > > > > >
> > > > > > Once upon a time, we had quite a lot of discussion
> > about how to
> > > > audit
> > > > > > ephemerals at startup time. We even had a suggestion
> > in the Base
> > > > Root
> > > > > > Package aimed specifically at solving this, however
> > it was removed
> > > > later
> > > > > > on and I can't remember if we ever came up with an
> > alternative,
> > > > hence my
> > > > > > question:
> > > > > >
> > > > > > How does an MGC figure out what ephemerals an MG supports ?
> > > > > >
> > > > > > -- Flemming
> > > > > >
> > > > > > --
> > > > > > Flemming Andreasen                Phone: +1 732 452 1667
> > > > > > Cisco Systems                     Fax:   +1 240 359 5839
> > > > >
> > > > > --
> > > > > Flemming Andreasen                Phone: +1 732 452 1667
> > > > > Cisco Systems                     Fax:   +1 240 359 5839
> >
> > --
> > Flemming Andreasen                Phone: +1 732 452 1667
> > Cisco Systems                     Fax:   +1 240 359 5839
> >

---

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 2 Aug 2000 10:27:37 -0400

I see the problem, and as an architectural matter, I'd like to be able to
achieve what you want to achieve.

As a practical matter, knowing what packages are implemented on the MG is
probably enough.  You would have to have a situation where there was some
kind of asymmetric split of capabilities on the gateway, where some
ephemerals
\
could do DTMF detect while others couldn't.  I think that that is not
practical,
because there is no way (currently) to ask the gateway to create a specific
kind of ephemeral - it's inferred in the media descriptor.

I'll absolutely agree you need AT LEAST to be able to get the list of
packages
implemented on the gateway, but that's the other thread.  Not being able to
find out exactly what the MG can do (which packages on which terminations)
is,
I think, something we want.  At the moment, it looks like something we would
have to change.

Linking the threads, I could propose in my name pattern package to have the
package
list as another parameter returned.  That would give you what you are
looking for.
It would be annoying in that you would not get a Package descriptor, you
would get
a parameter of ROOT which had the list.  It has the big advantage that it is
not a change to the protocol.  The most sweeping answer would be to define
a wildcard command with wildcard response request which doesn't match any
ephemerals
to return the value of the ephemerals as if there were some.  Another way is
to
define AuditCapabilities of Packages to do what we want.

Brian

> From: Christian Groves [mailto:[email-masked]]
> Sent: Monday, July 31, 2000 1:57 AM
> To: Rosen, Brian
> Cc: [email-masked]