[Asterisk-Users] Service codes for MGCP channels

[John Todd]

>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.

There is always exactly one context that handles incoming calls from 
a channel, I think, so this is not a major issue. Using "include" is 
trivial enough once the code is written.

>  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

OK, I have no complaints as long as what is in the dialplan takes 
precedence over the hardcoded entries in the channel drivers.  My 
feelings are pretty strong that this shouldn't be channel-specific, 
and I want to handle methods and feedback in my own way (as I have 
done already.)  As long as I can turn OFF the hardcoded features in 
the channel drivers, and/or insert my own dialplan logic such that 
the hardcoded features are never accessed, then that satisfies my 
requirements.

I am still unclear on your arguments as to why (as an example) *69 
should be _hardcoded_ into the Zap channel driver, and _hardcoded_ 
into the SIP channel driver, etc. etc. etc.  This seems to be an 
incredible redundancy of code for something that should be left to 
the admin to handle themselves in whatever way they want.  After all, 
these are just DTMF sequences - no magic.  If the end device (SIP, 
Zap, whatever) has their own CLASS dialplan sets, then that is a 
different problem - either deactivate them and use the server, or 
leave them enabled and ignore things for that line.

JT