Subject: Re: Cisco SG16: Keep Active

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 9 Feb 2000 11:06:10 -0500

Somewhat hoisted, I press on :)

I do think that DigitMaps is much too specialized and should be
replaced with a much more general mechanism, but the mechanism
doesn't behave like accumulate - it actually processes the events,
until it finds a terminating event and sends ONE message.  That
is useful, and a generalized mechanism that processed a set of
events, until it found a terminating event and sent one message
would be great.  It doesn't take action to do it, all it takes
is having an event that takes a list of other events and a pattern
to match.  That can be defined in a package.

An even better mechanism would be a script that could handle
a sequence of events and change state as the events occurred,
then send a message.

Neither of those mechanisms benefit from action and loop/step;
on the contrary, they make it more complicated because the
protocol would specify how events got in and out of the buffer
and the script mechanism or generalized digitmap mechanism
has to work around that (you don't say "Accumulate" on
dtmf, you have to say "process by map").

Brian

> -----Original Message-----
> From: Michael Thomas [mailto:[email-masked]]
> Sent: Wednesday, February 09, 2000 10:49 AM
> To: Rosen, Brian
> Cc: [email-masked]
> Subject: Re: Cisco SG16: Keep Active
>
>
> Rosen, Brian writes:
>  > Flemming
>  >
>  > Rather than go through this, it seems we are in an impasse.
>  >
>  > I believe that the two modes provided give you all the tools
>  > required to either have events sent to the MGC as fast as they
>  > occur, but with little filtering, or, to have the MGC and the MG
>  > be in lock-step on processing events.  If there are some wording
>  > problems that make you think this is not so, we will have to change
>  > them, as that is the intent.
>  >
>  > It would seem that there is only one fundamental difference in the
>  > two mechanisms: you seem to want a way to have some events
> get buffered, and
>  > then have something occur which causes the buffer
>  > to be sent.  I think there is no such requirement.
>
> What, in principle, are digit maps if not special
> instances of what Flemming is describing? I don't
> think that anybody would argue that, say,
> overlapped dialing doesn't function properly. It's
> just that there's incentive to keep usual and
> unneed load off the MGC, which is a consideration.
>
> Didn't you at one time want to fold digit maps
> into a general mechanism? Something that you
> thought might be a good idea if it weren't for the
> fact that it opened yet another can of worms? How
> would you do this without having a means of
> buffering events where a specified trigger caused
> the MG to send the accumulated events?
>
>  > Let me rephrase
>  > that a little: the benefit of creating in-between mechanisms
>  > is outweighed by the complexity of the mechanism required, and the
>  > lack of agreement on what additional complexity is warranted.
>  > I think you would agree that the "send events as you find them"
>  > always works, it's just that the MGC may have to throw away some
>  > events it may have been able to avoid seeing, which raises the
>  > complexity of the MGC code required.
>
> It's not an issue of complexity; MGC's need to
> deal with events and their timing no matter how
> they come in. It it's an issue of efficiency. In
> the case of digit maps, it would at least double
> the number of messages needed to complete a call.
>
>
>              Mike
>

---

From: Flemming Andreasen <[email-masked]>
Date: Wed, 9 Feb 2000 13:03:43 -0500

"Rosen, Brian" wrote:

> until it finds a terminating event and sends ONE message.

Aah, well for that we have the Ignore action in MGCP. If you want we could
add it (or something similar). That way both of our goals would be achieved.

>  That

The only problem with that is getting the events reported in order (or even
reported when you don't get that triggering event nut a bunch of events
before that) when you have some events that are handled by the pattern and
some that are not.

> a sequence of events and change state as the events occurred,

Now that we can agree on.

> dtmf, you have to say "process by map").

Rubbish. As I have argued countless times by now, they give you a general
mechanism that allow events to be reported in order. All you are doing is
deferring everything to specialized packages, and just hope for the best
when several of these packages have to work together.

> > the number of messages needed to complete a call.

-- Flemming

--
---------------------------------------
Flemming Andreasen
Cisco Systems
---------------------------------------