Subject: Auditing Of Packages

From: Tom-PT Taylor <[email-masked]>
Date: Wed, 26 Jan 2000 21:23:26 -0500

Every termination should support digit map capability, so digit map names
and values are all you would want to audit.  AuditValue is logical for that.
This leaves packages, which happen to be tied into what types of ephemeral
termination an MG will support.  Doctrine coming out of Washington was that
you would find out the latter by digging out the termination naming pattern,
then walking through  the naming tree to determine the capabilities
supported by each branch.  As Chip points out immediately below, however,
you cannot currently determine the packages supported by a termination until
it has been instantiated.  It seems reasonable that AuditCapability also
return a PackageList, the packages potentially supported by the termination
as opposed to those actually invoked.

                    From:         Chip Sharp <[email-masked]>
                    Subject:      Auditing

                    Section:        7.2.6, last line
                    Category:       Technical
                    Issue:          The draft text specifies that "DigitMap
and Packages are
                    not legal in AuditCapability". This is inconsistent with
the return
                    parameters shown for the example API. Furthermore, it
would seem reasonable
                    to be able determine what packages a termination (or
gateway) supports as
                    well as whether digit map is supported or not. Although
packages can be
                    audited with AuditValue, it would seem to make more
sense to allow it in
                    AuditCapability.
                    Proposal:       It is proposed to strike the above
sentence and allow for
                    auditing of these two capabilities.

                    v13 Status:     OPEN. No relevant text changed.

                    Section:        7.2.6
                    Category:       Open Issue
                    Issue:          The current draft text does not specify
how to audit
                    ephemerals at startup. This issue was identified by the
IETF editor but has
                    not yet been resolved (issue 1). The issue is, that when
you boot and have
                    not yet created any ephemeral terminations, how do you
know what the MG can
                    do. For example, how do you know if the MG has say an IP
interface, and ATM
                    interface, an MPLS interface or a Frame Relay interface
. If you could
                    audit something, you could look at the "network" value
in LocalControl.
                    Discussion:             A continuation of the discussion
that has occurred
                    on the Megaco mailing list so far is needed in order to
resolve the issue.

                    v13 Status:     OPEN. No relevant text has been added.

Tom Taylor
Advisor -- IPConnect Standards
E-mail: [email-masked] (internally, Tom-PT Taylor)
Phone and FAX: +1 613 736 0961

---

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 27 Jan 2000 10:03:12 -0500

The Audit Descriptor has DigitMap as one of its options,
so you can ask for a DigitMap.  The text says "DigitMap applied to the root
Termination returns all named DigitMaps in the gateway."
So I AuditValue does what you want.

AuditCapability of DigitMap doesn't make any sense I think, and that is what
the text says.

Packages for ephemerals are solved by name patterns, which was
what started me out on that in the first place.  If you wildcard
auditValue a name pattern that equates to an ephemeral, and ask
for Packages, I think you get a list of packages that ephemeral
would support.

So:
if Context=-{Modify=Root{TerminationState{g/PatternNum=2}}}
might return
.....TerminationState(g/MaxPatterns=4,g/PatternNum=2,g/Pattern="Ephem?n?n?n?
n",....}}}}

then
Context=-{W-AuditValue=Ephem*{Audit{Packages}}}

should return the list of packages.

While we could ask that this be made more explicit in the text,
no substantive change is warranted, I believe.

Brian

> -----Original Message-----
> From: Tom-PT Taylor [mailto:[email-masked]]
> Sent: Wednesday, January 26, 2000 9:23 PM
> To: [email-masked]
> Subject: Auditing Of Packages
>
>

---

From: Chip Sharp <[email-masked]>
Date: Thu, 27 Jan 2000 11:07:28 -0500

>Every termination should support digit map capability, so digit map names
   ^^^^^^^^^^^^^^^^^^^^^
I assume this was a typo?  Do you really mean that every termination (e.g.,
a video termination) should support digit maps?

>Phone and FAX: +1 613 736 0961

Support NetAid!  http://www.netaid.org
--------------------------------------------------
Chip Sharp                 Consulting Engineering
Cisco Systems              Telco Bio-region
Reality - Love it or Leave it.
--------------------------------------------------

---

From: Tom-PT Taylor <[email-masked]>
Date: Thu, 27 Jan 2000 12:36:08 -0500

Terminations in themselves are media-independent.  Hence in principle they
should all support digit maps.  The events which get mapped into digit maps
may be associated with specific media, as indicated by the relevant
packages.

> From: Chip Sharp [SMTP:[email-masked]]
> Sent: Thursday, January 27, 2000 11:07 AM
> To:   Taylor, Tom-PT [CAR:B904:EXCH]; [email-masked]
> Subject:      Re: Auditing Of Packages
>

---

From: Tom-PT Taylor <[email-masked]>
Date: Thu, 27 Jan 2000 12:38:53 -0500

You miss the point.  When an MG first starts up, there are no instantiated
ephemeral terminations.  As a result, you can't do an AuditValue on them.
It HAS to be AuditCapability.

> From: Rosen, Brian [SMTP:[email-masked]]
> Sent: Thursday, January 27, 2000 10:03 AM
> To:   Taylor, Tom-PT [CAR:B904:EXCH]; [email-masked]
> Subject:      RE: Auditing Of Packages
>

---

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 27 Jan 2000 13:00:05 -0500

This might be theoretically true, but in fact you have to implement dtmf
detect before you
can use digitmaps, because they only operate on dtmf digits,

If we had gone ahead and generalized the mechanism to work on arbitrary
sequences
of detectable events, then what you suggest would make sense.  As they are
now
defined, they are limited to MGs that implement dtmf detect.  That being
said, we get to
the IPPhone folks' definition of optional. If I keep the same stance I took
with them
you have to implement the DigitMap descriptor even if you don't implement
dtmf detect.
You have to accept a digitmap in an event even if you don't implement dtmf
detect, and
auditing of same has to work.

Brian

        -----Original Message-----
From:   Chip Sharp [SMTP:[email-masked]]
Sent:   Thursday, January 27, 2000 11:07 AM
To:     Taylor, Tom-PT [CAR:B904:EXCH]; [email-masked]
Subject:        Re: Auditing Of Packages

   ^^^^^^^^^^^^^^^^^^^^^

>Phone and FAX: +1 613 736 0961

        Support NetAid!  http://www.netaid.org <http://www.netaid.org>

---

From: Tom-PT Taylor <[email-masked]>
Date: Thu, 27 Jan 2000 12:10:41 -0600

Read the current wording of digit maps.  Any event package that maps events
to the digits 0-9 and letters A-K can be used with digit maps.  By the way,
the DTMF package does not currently show this mapping, and that has to be
fixed.  The ABNF for digit maps shows MF symbols, and those have to be
deleted.

> Sent: Thursday, January 27, 2000 1:00 PM
> the IPPhone folks' definition of optional. If I keep the same stance I
> took with them
>       Terminations in themselves are media-independent.  Hence in
> principle they should all support digit maps.  The events which get mapped
> into digit maps may be associated with specific media, as indicated by the
> relevant packages.
>
>               Support NetAid!  <http://www.netaid.org>

---

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 27 Jan 2000 13:13:00 -0500

You are arguing the unarguable.  If they don't exist, then you could assert
that you
can't do any kind of audit.  If you want to allow an audit, then whether you
allow
auditValue or AuditCapability doesn't matter a whit.  In this case, I'd just
allow it
for AuditValue, and not mess up AuditCapability.

Brian

        -----Original Message-----
From:   Rosen, Brian [SMTP:[email-masked]]
Sent:   Thursday, January 27, 2000 10:03 AM
To:     Taylor, Tom-PT [CAR:B904:EXCH]; [email-masked]
Subject:        RE: Auditing Of Packages

        AuditCapability of DigitMap doesn't make any sense I think, and that
is what
the text says.

        So:

n",....}}}}

        then

        Brian

> From: Tom-PT Taylor [ mailto:[email-masked]
<mailto:[email-masked]> ]

---

From: Tom-PT Taylor <[email-masked]>
Date: Thu, 27 Jan 2000 13:52:32 -0600

What you're saying is that there is no semantic difference between
AuditValue and AuditCapability.  I hope you don't mean that.  We introduced
the distinction so we could audit separately the values actually set on a
termination vs. the choices offered to the MGC.  Packages on a non-existent
termination fall into the latter category -- they haven't been set yet.  The
whole point of the naming pattern and the W- wildcarding was so you could
walk through and determine what the MG could do on an aggregate basis before
you really got into call processing.

> Sent: Thursday, January 27, 2000 1:13 PM
> You are arguing the unarguable.  If they don't exist, then you could
> assert that you
> can't do any kind of audit.  If you want to allow an audit, then whether
> you allow
> auditValue or AuditCapability doesn't matter a whit.  In this case, I'd
> just allow it
>       You miss the point.  When an MG first starts up, there are no
> instantiated ephemeral terminations.  As a result, you can't do an
> AuditValue on them.  It HAS to be AuditCapability.
>
>       > From: Tom-PT Taylor [ <mailto:[email-masked]>]

---

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 27 Jan 2000 15:03:07 -0500

The whole idea of auditing packages "breaks" the distinction between
AuditValue and
AuditCapability.  You can make an argument that Packages should be legal in
either,
but there aren't two interesting things you can get with Packages, so we
decided that
they were legal in AuditValue, and not in AuditCapabilities.  We could have
decided the
other way, and there would be no difference, the decision was arbitrary.
I don't think there is any way you can assert there is any difference
between Package
audit of a physical termination and package audit of a (non instantiated)
ephemeral
termination which would lead you to argue that package audit of one should
be in AuditValue
while package audit of the other should be in AuditCapability.  Neither ever
has
"possible values" or "current values".  They both indicate "packages
implemented",
which is neither a possible or a current value.

        -----Original Message-----
From:   Rosen, Brian [SMTP:[email-masked]]
Sent:   Thursday, January 27, 2000 1:13 PM
To:     Taylor, Tom-PT [CAR:B904:EXCH]; [email-masked]
Subject:        RE: Auditing Of Packages

Brian

                -----Original Message-----
From:   Rosen, Brian [SMTP:[email-masked]]
Sent:   Thursday, January 27, 2000 10:03 AM
To:     Taylor, Tom-PT [CAR:B904:EXCH]; [email-masked]
Subject:        RE: Auditing Of Packages

                AuditCapability of DigitMap doesn't make any sense I think,
and that is what
the text says.

                Packages for ephemerals are solved by name patterns, which
was
what started me out on that in the first place.  If you wildcard
auditValue a name pattern that equates to an ephemeral, and ask
for Packages, I think you get a list of packages that ephemeral
would support.

                So:

                then

                While we could ask that this be made more explicit in the
text,
no substantive change is warranted, I believe.

                Brian

> From: Tom-PT Taylor [ < mailto:[email-masked]
<mailto:[email-masked]> >]

---

From: Tom-PT Taylor <[email-masked]>
Date: Thu, 27 Jan 2000 14:23:34 -0600

I had figured that AuditValue would return "packages actually invoked in
properties set for this termination".  There's an important distinction
between that and "properties that could be invoked for a termination with
this name pattern" -- the latter, for instance, might reveal that the GW
supports both ATM and RTP ephemerals using the same simple numeric name for
each, while the AuditValue would reveal that this particular instantiated
termination has an ATM package on it.

The issue of determining MG transport capabilities and the nature of
ephemeral terminations is not closed until we close on this one.

> Sent: Thursday, January 27, 2000 3:03 PM
> To:   Taylor, Tom-PT [CAR:B904:EXCH]; [email-masked]
> AuditCapability.  You can make an argument that Packages should be legal
> in either,
> they were legal in AuditValue, and not in AuditCapabilities.  We could
> have decided the
> while package audit of the other should be in AuditCapability.  Neither
> ever has
> AuditValue and AuditCapability.  I hope you don't mean that.  We
> introduced the distinction so we could audit separately the values
> actually set on a termination vs. the choices offered to the MGC.
> Packages on a non-existent termination fall into the latter category --
> they haven't been set yet.  The whole point of the naming pattern and the
> W- wildcarding was so you could walk through and determine what the MG
> could do on an aggregate basis before you really got into call processing.
>
>               You are arguing the unarguable.  If they don't exist, then
> you could assert that you
>       can't do any kind of audit.  If you want to allow an audit, then
> whether you allow
>       auditValue or AuditCapability doesn't matter a whit.  In this case,
> I'd just allow it
>                       You miss the point.  When an MG first starts up,
> there are no instantiated ephemeral terminations.  As a result, you can't
> do an AuditValue on them.  It HAS to be AuditCapability.
>
>               > From: Tom-PT Taylor [ <
> <mailto:[email-masked]>>]
>               > This leaves packages, which happen to be tied into what
> types
>               > of ephemeral
>               > you would find out the latter by digging out the
> termination
>               > naming pattern,
>               > return a PackageList, the packages potentially supported
> by
>               > the termination
>               >                     Issue:          The draft text
> specifies
>               > that "DigitMap
>               >                     well as whether digit map is supported
> or
>               > not. Although
>               > packages can be
>               >                     audited with AuditValue, it would seem
> to
>               > make more
>               > sense to allow it in
>               >                     AuditCapability.
>               >                     do. For example, how do you know if
> the
>               > MG has say an IP
>               > interface, and ATM
>               >                     interface, an MPLS interface or a
> Frame
>               > Relay interface
>               > . If you could
>               >                     Discussion:             A continuation
> of
>               > the discussion
>               > that has occurred