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
_______________________________________________ Asterisk-Users mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-users
