[Asterisk-Users] Service codes for MGCP channels

[John Todd]

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

That doesn't make much sense.

Reason: call control features need to be managed from the "center" of 
the network, not at the edges.  I want full control of my end 
devices, and full visibility into their states.  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 b) 
there is no visibility into set/get on CLASS features (worse.)

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

Is there a counter-argument to this that addresses the points about 
visibility into a channel's status?

JT