[asterisk-dev] VMWI generation implemenation on FXS ports

[Oron Peled]

On Sunday, 21 בDecember 2008, Alec Davis wrote:
> In code which is still in progress uses 'mwisendtype' in chan_dadhi.conf to
> set the type of vmwi to use
>    'fsk' or undefined for exisiting FSK only support.
>    'none' no FSK spill heard every second time you go off hook.
>    'rpas' for existing support ring pulse before FSK
>    'lrev' line reversed while messages exist
>    'hvdc' high voltage, 90Vdc idle voltage
>    'hvac' high voltage neon generation, Following Silicon Labs AN33

Nice to see someone who put some order in this mess.

> The dilemma is
> 	1). A new ioctl like DADHI_VMWI_SENDTYPE
> 	2). Use existing DAHDI_VMWI and limit it to 255 messages, where the
>      upper byte is the VMWI type, bit settable, to support multiple
>      VMWI types per channel.

* I think there's no point in having two ioctl()s for this.

* Maybe the transition will be easier if we add a new ioctl name+number
  and than kill the old name+number.

* As the ones who pushed {DAHDI/ZAPTEL}_VMWI and its only current
  users (AFAIK, anyone else, please shout loud), I see no problem in
  replacing our minimal ioctl() with an improved one.
  Changing the name+number as proposed above would simply make it cleaner
  (then, we'll simply kill our old ioctl()).

* I think we are early enough in DAHDI lifecycle to do the API transition
  quickly now.

* If you want to see our implementation, just grep for vmwi in xpp/card_fxs.c


-- 
Oron Peled                             Voice/Fax: +972-4-8228492
oron at actcom.co.il                  http://www.actcom.co.il/~oron
* Progress (n.): The process through which Usenet has evolved from
  smart people in front of dumb terminals to dumb people in front of
  smart terminals.  -- obs at burnout.demon.co.uk (obscurity)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-dev/attachments/20081221/68265065/attachment.htm