Subject: [Fwd: [Megaco] Auditing the active Contexts]

From: Dan Linton <[email-masked]>
Date: Fri, 07 Sep 2001 06:24:11 -0400

Another resend.

Subject: Re: [Megaco] Auditing the active Contexts
From: Dan Linton <[email-masked]>
To: "Rosen, Brian" <[email-masked]>
Cc: megaco <[email-masked]>
Date: Thu, 06 Sep 2001 10:51:18 -0400

Brian,

We can always agree to disagree. However, I would like to use that as
a last measure. So I'll take another crack at it.

First let's remove the idea of a new parameter on root. I agree that it is
too late for that. That is not the issue at all.

One thing I forgot to offer last time was that we have an implementation
for ALL/ROOT in our MG. It was my example Number 1 which violates
the ABNF. That's what prompted this whole discussion prior to which I was
planning to implement something like Number 3. As an implementor, I can
say that working with ALL/ROOT is not as trivial is it might seem.

The problem with both my example Number 3 and your proposal is that
they treat ROOT as a wildcarded TerminationID. Perhaps this is my
opinion, but ROOT is and should be treated as a fully specified
TerminationID. Therefore, handling it like a wildcarded TerminationID
is the wrong approach, and if it is wrong (i.e. a defect) it should be fixed
via the IG. Luckily, expanding ROOT as a wildcard also happens to be
unnecessary since ALL/ALL is possible.

Thanks,
Dan

"Rosen, Brian" wrote:

> Call it a difference of opinion, but I disagree.
>
> For one thing, the RFC and Recommendation H.248 are published.
> We can do some things in the IG, but not change the protocol.
> It's pretty easy to add some explanation, pretty hard to
> eliminate something.  Even if you "deprecate" it in the IG,
> it's still in the protocol.
>
> Besides, it gets you what you want, in a way that the
> parser can deal with, that is easy for the MG to generate.
> Sure, the package is a more compact way to get the information,
> but the way I suggest is appropriate is simple to do,
> and has little consequences.  You usually only do this
> operation when you have reason to suspect the MG is out
> of sync with the MGC.
>
> Brian
>
> > -----Original Message-----
> > From: Dan Linton [mailto:[email-masked]]
> > Sent: Wednesday, September 05, 2001 11:14 AM
> > To: Rosen, Brian
> > Cc: megaco
> > Subject: Re: [Megaco] Auditing the active Contexts
> >
> >
> > Brian,
> >
> > See comments inline.
> >
> > "Rosen, Brian" wrote:
> >
> > > The correct response, I think is:     Context = 1
> > {AuditValue = Line/1}
> > >       Context = 2 {AuditValue = Line/2}The particular
> > termination doesn't matter (it's only needed
> > > to get the syntax correct),and most importantly, you only get one.
> >
> > Why only one? It's almost like we are 'replacing' ROOT versus
> > 'expanding' it as we
> > would do if we had received * instead of ROOT. Perhaps more
> > important than that
> > is how does an implementor know to do this versus something
> > else? And if we need
> > a note in the IG, I would rather have it say that ALL/ROOT
> > should not be used.
> >
> > > I rather like the parameter idea.  We can do that with a
> > package, but I think we need tokeep the
> > > ALL/ROOT for backwards compatibility.
> >
> > Don't we potentially already have a backwards compatibility
> > issue for those that have
> > implemented it differently than what you've shown above? We
> > should probably ask if
> > anyone has implemented ALL/ROOT and if so, what does their
> > reply look like.
> >
> > Thanks,
> > Dan
> >
> > > Brian
> > > -----Original Message-----
> > > From: Dan Linton [mailto:[email-masked]]
> > > Sent: Wednesday, September 05, 2001 6:13 AM
> > > To: megaco
> > > Subject: Re: [Megaco] Auditing the active Contexts
> > >
> > >
> > >      List,
> > >
> > >      Any comments on this?
> > >
> > >      Thanks,
> > >      Dan
> > >
> > >      Dan Linton wrote:
> > >
> > >     > Hello,
> > >     >
> > >     > Section 7.2.5 in the RFC contains a table of
> > ContextID/TerminationID's
> > >     > that are allowed with the AuditValue command. Every
> > entry in that table
> > >     > makes sense except one: ALL/ROOT (i.e. ContextID = *,
> > >     > TerminationID = ROOT).
> > >     >
> > >     > I'm evaluating this under the fundamental assumption
> > that commands operate
> > >     > on terminations in a context and that ROOT should be
> > treated as if it is in the
> > >     > NULL context (which can also be found in the table
> > mentioned above). So
> > >     > NULL/ROOT yields properties on the gateway and
> > ALL/ALL yields a list
> > >     > of contexts and the terminations within the context.
> > Why do we even need
> > >     > ALL/ROOT? If it is simply to get a list of active
> > contexts (ALL/ALL effectively
> > >     > does that plus more), then I would like to propose a
> > simpler solution. That
> > >     > is, disallow ALL/ROOT. Instead, define an
> > ActiveContexts property in the
> > >     > Base Root package as a list of ContextIDs. Examples are:
> > >     >
> > >     > 1)  root/ActiveContexts = {}
> > >     >
> > >     > 2)  root/ActiveContexts = {1, 2, 8}
> > >     >
> > >     > Of course, this would be a readonly property. The
> > ROOT properties are
> > >     > returned when the MGC audits NULL/ROOT. If the MGC
> > requires more
> > >     > information than that about the active contexts, it
> > should use ALL/ALL.
> > >     >
> > >     > ---------
> > >     >
> > >     > Shifting gears back to ALL/ROOT. Not only is it a
> > special case that convolutes
> > >     > the implementation, I don't think it works. I cannot
> > come up with an appropriate
> > >     > reply even taking Section 11.1 of the Implementor's
> > Guide into consideration.
> > >     > Each of the examples given here has an issue
> > (documented below).
> > >     >
> > >     > 1) Action Request:
> > >     >       Context = * {AuditValue = ROOT {Audit{}}}
> > >     >    Action Replies:
> > >     >       Context = 1 {},
> > >     >       Context = 2 {}
> > >     >
> > >     > 2) Action Request:
> > >     >       Context = * {AuditValue = ROOT {Audit{}}}
> > >     >    Action Replies:
> > >     >       Context = 1 {AuditValue = ROOT},
> > >     >       Context = 2 {AuditValue = ROOT}
> > >     >
> > >     > 3) Action Request:
> > >     >       Context = * {AuditValue = ROOT {Audit{}}}
> > >     >    Action Replies:
> > >     >       Context = 1 {AuditValue = Line/1,
> > >     >                    AuditValue = RTP/1},
> > >     >       Context = 2 {AuditValue = Line/2,
> > >     >                    AuditValue = RTP/2}
> > >     >
> > >     > In Number 1, the replies violate the current ABNF
> > (missing the Command Reply).
> > >     > Number 2 repeats the same information inside of each
> > Action Reply. However, the
> > >     > larger issue with Number 2 is that ROOT is not in
> > either of the contexts listed. The
> > >     > replies for Number 3 are exactly the same as if
> > ALL/ALL had been used in the
> > >     > request.
> > >     >
> > >     > As it currently stands, I don't think there is a
> > valid way to Reply. So we at least
> > >     > need
> > >     > to fix that. I like adding a property to root as
> > outlined above. However, I would
> > >     > settle for simply disallowing ALL/ROOT (use ALL/ALL instead).
> > >     >
> > >     > Thanks,
> > >     > Dan
> > >
> >