Subject: Re: digitMapDescriptor

From: Brian Rosen <[email-masked]>
Date: Fri, 13 Aug 1999 11:03:02 -0400

The in the event descriptor rules we find:
requestedAction = ( AccumulateDescriptor / NotifyActionToken /
                    AccumulateToken / extensionParameter)

AccumulateDescriptor = AccumByDMToken LBRKT (digitMapName /
                         digitMapValue) RBRKT

Notice the last one, your choices are an existing predefined map name,
or a definition without a name.  There is not a way in the current
syntax to predefine a name (other than by provisioning) except using
the digitMapDescriptor in Add/Move/Modify (which is where eventDescriptor
can be used).

Thus I think the current syntax should stand.  You could look ahead
and slightly change digitMapDescriptor from
digitMapDescriptor = DigitMapToken EQUAL digitMapName LBRKT digitMapValue
RBRKT

to be

defineDescriptor = DefineToken EQUAL definedName COLON defineType LBRKT
   defineString RBRKT

where for now:
definedName = pkgdName
defineType = DigitMapToken
defineString = digitMapValue

Someday we could have additional types and strings, like
defineType = DigitMapToken / ScriptToken / TemplateToken

Brian

> -----Original Message-----
> From: Nancy-M Greene [mailto:[email-masked]]
> Sent: Thursday, August 12, 1999 2:30 PM
> To: [email-masked]
> Subject: digitMapDescriptor
>
>
> On a closer look at the digitMapDescriptor, we see that it is in the
> eventsDescriptor, AND as a separate parameter to Add, Modify and Move.
>
> Based on the fact that we have left Put, Delete, and
> scripting for a later
> version of the protocol, I would like to argue that there is
> no need to have
> digitMapDescriptor as a separate parameter to Add, Modfiy and
> Move messages.
> Having it there is in essence trying to piggyback a Put
> function onto the
> Add/Modify/Move.
>
> It is enough to have the digitMapDescriptor in the
> eventsDescriptor, where
> it allows you to send down a name and/or value of a digit map to be
> associated with that eventsDescriptor. If you do this, that
> digitmap will be
> stored and only the name of the digit map needs be sent down
> later. The
> scope of the digit map would still be the scope of the
> terminationId sent in
> the message.
>
> Digit maps can of course be provisioned on the MG in some way
> outside the
> scope of this version of the Megaco protocol, and then
> referred to only by
> name in the eventsDescriptor.
>
> We should leave digitMapDescriptor in the AuditValue and
> AuditCapabilities
> because you need a way to audit the digit maps in use by a particular
> termination and stored on the MG.
>
> Nancy
>
> --------------------------------------------------------------
> ------------
> Nancy M. Greene
> Internet & Service Provider Networks, Nortel Networks
> T:514-271-7221 (internal:ESN853-1077) E:[email-masked]
>