Subject: issue on digit map

From: Wai-tak Siu <[email-masked]>
Date: Thu, 18 Nov 1999 11:38:04 -0800

Hi,
    Digit maps can be shared if they are applied to multiple
terminations through commands with wildcarded termation IDs. If a shared
named digit map is later changed in a command that is applied only to a
particular termination, does it affect other terminations' view of the
digit map?
    This issue is not explained in the v.12. Thanks.
Waitak
Cisco Systems

---

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 19 Nov 1999 08:20:02 -0500

We have long discussed the issue of Global vs. Local digitmaps.
The issue is how much storage space the MG has.

If it has very restricted space, then it probably has to restrict digitmaps
to all be global

If it has a moderate amount of space, it may be able to keep
one, or maybe a couple, of digitmaps per termination, but
must rely on global DMs anything else

If it has a lot of space, multiple DMs can be stored for each
termination, but it would be convenient to allow global DMs
to avoid lots of messaging where there was common DMs.

Generally, I expect most MGs to really only implement global
MGs.  It's hard to think of a case where the dialing plan is
completely variable depending on which port you are one.  Usually, there are
a few choices, the specific one depends on the port you are on.
Nevertheless, I know of at least a couple of
cases where per port DMs would be very useful.

We can argue about whether we need syntax to differentiate
global from local DMs.  Whatever we come down to, the answer
to the question is that a change in a local DM changes only
that DM, and a change in a global DM changes all instances of
it.  There was at least one discussion a while ago on what
happened if a definition was changed WHILE THE DM WAS IN USE.
The answer seemed to be that the MG used the old definition
until a pattern match.  It occurs to me that this may be
problematic if a number of ports are programmed to use the old
copy but have not seen any digits yet - do they use the new or
the old.  I'd say the new.

Brian

> -----Original Message-----
> From: Wai-tak Siu [mailto:[email-masked]]
> Sent: Thursday, November 18, 1999 2:38 PM
> To: [email-masked]
> Subject: issue on digit map
>
>
> Hi,

---

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 19 Nov 1999 10:05:28 -0500

I agree with where this seems to be leading.  Digit maps should be globally
defined across the MG.  I can't think of a case where DMs per termination
would be useful that could not be accommodated by the same (or smaller)
amount of shared storage at the MG level.  Multiple places to define them
would just be confusing.

Can we settle this - DMs are always global in scope?  As Peter points out,
you can always use a name space hack to create the illusion of private ones.

One tricky side-effect of this is the "what digits" problem.  Are digits
being collected from dtmf tones or keypad button press events?  Associating
DMs with specific terminations would potentially simplify this.  So would
allowing different types of DM -- one Dm type for each entity where digits
could be collected.  No clean solution off hand -- thinking cap on.  ..

The following text occurred in Washington Issue 4 - Events:

Another possibility is to define a more generalized DigitMap mechanism.

In the base protocol, we define the DigitMapDescriptor, which is renamed
"PatternMap", and generally has the same syntax. A package defines specific
use for the base mechanism by defining:

     An ordered list of events that are detected (DTMF digits)

     A one character symbol for each that will occur in the pattern map

     An event which is enabled by specifying the name of an existing
pattern
        map, or a pattern map value, as a parameter.

Events in the list of events that are detected are processed through the
pattern map mechanism. The event returns a string which is the pattern
thatwas matched. If any other event is detected, the pattern is returned
with   a "|" suffix indicating that an event terminated pattern matching.

The intention is that, except for the name change, and a required
package,digitmap works just as defined now, with the same syntax in the
DigitMapDescriptor, but with the different syntax in the
EventsDescriptor(something like Events{DTMFMap{Map=NANP}}

On the subject of MG replacement/redefinition while in use, this is a
potentially hazardous situation.  Seems to me the safest approach (other
than the MGC making sure it avoids the situation in the first place!) is to
use local copies of the DM while it is in use.  Arrival of a
replacement/redefinition DM would not affect operation an existing
EventsDescriptor, whether digits are already collected or not, so there
would be no possibility of ambiguity.  If the MGC want the MG to switch to
the new DM, it re-issues the EventsDescriptor.  Otherwise, the MGC has no
way of knowing that digits have already been collected, so it cannot figure
out exactly what DM is actually in use.

Another option would be to make this an error condition.  Inform the MGC it
goofed, and let it handle the situation cleanly as it sees fit.  I prefer
the former.

I'm okay with either.

Brian

-- Peter

        -----Original Message-----
From:   Rosen, Brian [SMTP:[email-masked]]
Sent:   19 Nov, 1999 08:20
To:     [email-masked]
Subject:        Re: issue on digit map

        If it has very restricted space, then it probably has to restrict
digitmaps
to all be global

        Brian

> From: Wai-tak Siu [ mailto:[email-masked] <mailto:[email-masked]> ]

---

From: "Rosen, Brian" <[email-masked]>
Date: Mon, 29 Nov 1999 23:24:06 -0500

Absolutely.  Virtual MGs would have to have different global named
DigitMaps.

Brian

> From: Michael Thomas [mailto:[email-masked]]
> Sent: Monday, November 29, 1999 2:46 PM
> Peter Blatherwick writes:
>  > Brian, list:
>  >
>    I can think of one problem: an MG's terminations are
>    controlled by different MGC's. For example, my home
>    MG may have two terminations, each of which is controlled
>    by a different service provider.
>
>    I don't think that places an onus on the
>    protocol though; the MG just needs to keep
>    these virtual MG's separate.
>
>
>                  Mike
>