[Asterisk-Users] Service codes for MGCP channels

[Tilghman Lesher]

On Wednesday 19 November 2003 15:16, John Todd wrote:
> >On Wednesday 19 November 2003 10:11, John Todd wrote:
> >>  >after testing with a MGCP phone (Swissvoice ip10s) I found the
> >>  > following ASTERISK-based codes (VERTICAL SERVICE CODES) to
> >>  > work - I assume that most of those will also work with SIP,
> >>  > but haven't checked that yet:
> >>  >
> >>  >*67 - Calling Number Delivery Blocking
> >>  >*70 - Cancel Call Waiting
> >>  >*72 - Call Forwarding Activation
> >>  >*73 - Call Forwarding Deactivation
> >>  >*78 - Do Not Disturb Activation
> >>  >*79 - Do Not Disturb Deactivation
> >>  >*8 - Call pick-up
> >>  ># - Transfer
> >>  >
> >>  >Questions:
> >>  >- how can I enable "Calling Number Delivery"? *65 doesn't seem
> >>  > to do the trick:
> >>  >- how can I enable "Call Waiting" after having it disabled via
> >>  > *70?
> >>
> >>  No, these do not work with SIP, and there is currently a
> >> request to remove that functionality from the MGCP and Zap
> >> channels, since this type of feature should be (IMHO) in the
> >> dialplan and not built into the channel.  (What if I want to use
> >> *70 for something else? How do I read the status of Do Not
> >> Disturb, since this is embedded in the channel?)
> >
> >You're going to be waiting an awful long time, then, because call
> >features are not going to be removed from the zap channel. 
> > Instead, they will be added to more channels.  What _will_ be
> > happening in the future, however, is the ability to customize the
> > codes (in both a global, as well as a channel-type-specific way)
> > used to invoke call features.
> >
> >Mark has been very emphatic about call features not belonging in
> > the dialplan.
>
> That doesn't make much sense.

Actually, it does.  Read on for why I agree with Mark.

> Reason: call control features need to be managed from the "center"
> of the network, not at the edges.

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.

> I want full control of my end devices, and full visibility into
> their states.

Putting the functionality inside the channel driver says nothing about
visibility.  Indeed, one of the things I'd like to do with Zap channel
forwarding, for example, is to expose that forwarding with astdb.  In
addition, this will allow call forwarding on Zap channels to persist
across Asterisk restarts.

> If the CLASS features are handled within the channel,
> then that implies that either a) a new set of applications or
> variables exist that can provide visibility and configuration into
> each channel (yuck!) or

That's only if the call features are exposed in the dialplan (which
they will not be).  Call features will be intrinsic to the channel.

> b) there is no visibility into set/get on CLASS features (worse.)

Again, this is a matter of implementation, not a criticism of the
basic concept.

> I have implemented a full CLASS featureset in the dialplan,
> including customized voice feedback prompts, speed dials,
> music-on-hold selection, call forwarding (timed AND unconditional),
> telemarketer block selection, blah blah blah.   It took me some
> time, but it wasn't impossible, obviously - anyone can do it -
> that's what the dialplan DOES; it's not hardcoded.  The concept
> here is that we want to move the programming into the hands of the
> admin in a scriptable way, not put the  programming inside of the C
> code of the application package (meaning the chan_* drivers.)

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.

But if you really feel strongly about scripting your own call
features, note that you can already override existing call features
simply by including your own logic for that code in your dialplan.

-Tilghman