Subject: Re: digitMapDescriptor

From: Fernando Cuervo <[email-masked]>
Date: Mon, 16 Aug 1999 13:26:53 -0400

So..
the "operational" part of digit maps is handled through events..this is
good.
The "definitional" (?) part of  scripts, templates, digitmaps, etc is all
handled in the same manner..this is good.
However, we could define them in any command. I sort of liked the "old"
Put/Delete commands. The transactional model of Megaco will allow
Put/Deletes to go together with Add/subtract/move...etc. if required or on
their own (a better way to handle things that are more permanent and broader
in scope than the digit collection on a per call basis).

Fernando Cuervo

> ----------
> From:         Brian Rosen[SMTP:[email-masked]]
> Sent:         August 16, 1999 11:06 AM
> To:   [email-masked]
> Subject:      Re: digitMapDescriptor
>
> > Ok, I see this now - either a digitMapName OR a digtMapValue in the
> > AccumulateDescriptor- and I assume if you just put a
> > digitMapValue, it is a
> > transient digit map, i.e. it will not stick around after the
> > event(s) it is
> > assigned to has(have) been detected.
> Correct
>
>
> > In order to simplify things for the MG, we could say that the
> > digitMapDescriptor is ONLY used on Modify, and on Add. It
> > should NOT be used
> > on Move. If we allow it everywhere, then the errors that can
> > occur on a
> > command are increased - what if the actual move succeeds, but
> > the storing of
> > a digit map fails? You may still have wanted the Move to
> > occur. So better to
> > separate the two - do a Modify with a digitMapDescriptor, and
> > then do a
> > Move.
> I don't understand this; there is no difference between Add and
> Move in this respect, and it complicates the syntax, in that
> at the moment, all the parameters to Add, Move and Modify
> are the same.
>
> > Actually, we need to say on the Add and Modify, that if the
> > storage of the
> > digitMapDescriptor fails, the Add or Modify should still do
> > the other things
> > it is asked to. In other words, we need to send back a
> > Warning msg that the
> > storage of the digit map failed, and because this is the
> > case, the Events
> > Descriptor will act as if it had been asked to send back a
> > Notify on every
> > event detected. Same thing if a named digit map is not found.
> I don't think this is right.  If you can't store the digitmap,
> it's an error, and the transaction is in error (although
> we are arguing about transaction syntax at the moment).
> If the digitmap defined is used in the EventDescriptor of
> the Add, it's definitely a problem.
>
> Brian
>