Subject: Re: digitMapDescriptor

From: Brian Rosen <[email-masked]>
Date: Wed, 18 Aug 1999 08:35:29 -0400

This kind of error is a software fault in the MGC, or possibly
some kind of provisioning fault.  You don't know if the MGC
is able to deal with digit by digit events.  I'd think it should be
considered serious, and rejected out of hand.

Brian

> -----Original Message-----
> From: Michael Thomas [mailto:[email-masked]]
> Sent: Tuesday, August 17, 1999 7:51 PM
> To: Brian Rosen
> Cc: [email-masked]
> Subject: Re: digitMapDescriptor
>
>
> Brian Rosen writes:
>  > 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.
>
>    One could take the stance that a digit map is
> just an optimization (which it is) and that when a
> collect according to (unspecified, errored) digit
> map is encountered, the MG should issue a warning,
> but go into digit by digit send mode. Thus an MG
> which had some sort of resource limitation on
> digit maps would still work, albeit not as
> efficiently.
>
>               Mike
>

---

From: Michael Thomas <[email-masked]>
Date: Wed, 18 Aug 1999 08:22:53 -0700

Brian Rosen writes:
 > some kind of provisioning fault.

   Not necessarily. The MG might have limited
resources and the digit map for a particular dial
plan is too big, for example. That's not really
the fault of provisioning or the MGC. In that case
-- especially since somebody is going to need to
figure out how to squeeze the digit string down --
allowing the MG to go into digit by digit mode
instead of failing altogether still allows
interoperability, albeit at a higher transaction
cost.

 > You don't know if the MGC

   The MGC needs to deal with digit by digit
events. If a sought after event occurs during
digit collection, the partial digit string is
sent.

                Mike