[Asterisk-Users] Service codes for MGCP channels

[Tilghman Lesher]

On Thursday 20 November 2003 02:45, Florian Overkamp wrote:
> At 16:48 19-11-2003 -0600, you wrote:
> >And you will have control of your devices.  The problem is that many
> >of the call features are intrisically related to how the channel
> > type signals to devices.  Hence, the functionality needs to be at
> > the channel driver level.
>
> Actually, I don't agree. It is related to how the signalling toward
> the _other party's_ channel should be (for instance redirection
> signals instead of dialling, if supported - yes, that would be nice!)

I'm thinking of forwarding, where the digits entered influence how you
as the dialler of the digits (not of subsequent calls) hear prompts
(e.g. a special dialtone before you enter the extension to which you
want calls forwarded).

> >There are two problems, as I see it:  first of all, you're
> > cluttering the dialplan with features that ought to be intrinsic to
> > the system. Note that you're going to have to include EVERY context
> > in which phones start with these programmed call features.  Second,
> > considering that everybody is going to have pretty much exactly the
> > same logic in every dialplan, that's a lot of wasted time (and a
> > great potential for typos and missed logic).  Asterisk is not
> > supposed to be a barebones system (as you seem to be describing);
> > it is, indeed, a full-featured system.
>
> You are assuming everybody is going to have the same logic. This is
> not true. First of all we want to use different access codes than are
> currently in use.

As I stated before, that will be part of the implementation.

> Second of all, it might be possible to
> differentiate in what we supply if we are working in a billable
> environment. Additional services can be at a premium, so being able
> to allow or disallow access will make sense.

This relates to implementation.  Precisely put, you want the ability to
turn call features on and off on a per-channel basis.

> And even then, people
> will want to make minor tweaks in the behaviour of the services (like
> playing back a confirmation prompt upon redirection, or just hanging
> up).

I suspect that this is only a minority of people.  Most users will
expect each call feature to work in exactly the same way as that
feature on the PSTN, and the users' perceptions on how things should
work strongly supports implementing this inside the channel.

> These all seem like minor things, but they relate very strongly to
> what the end user percieves. This is precisely why it should be
> accessible to system administrators rather than programmers - the
> local organisation offering a pbx on asterisk knows much better than
> anyone else what their users expect of them.

Users' perceptions are exactly why the code needs to be inside the
channel driver, but configurable for the system administrator.

-Tilghman