Re: vmodem and vgetty

David Sugar <[email protected]>
Newsgroups gmane.comp.gnu.bayonne.devel
Organization GNU Telephony
Message-ID <[email protected]>
I think it could be possible to do this depending on how the vgetty code 
is organized.  The Bayonne driver adaptions that would be needed are 
relativily small and confined to virtuals.

Alex Schenkman wrote:
> David:
> 
> Can the code in vgetty be reused for the vmodem driver?
> vgetty is a voice extension of mgetty, and comes bundled in many 
> distributions.
> 
> 
> 
> On 25 aug 2005, at 17.57, [email protected] 
> <mailto:[email protected]> wrote:
> 
>> Send Bayonne-devel mailing list submissions to
>>     [email protected] <mailto:[email protected]>
>>
>> To subscribe or unsubscribe via the World Wide Web, visit
>>     http://lists.gnu.org/mailman/listinfo/bayonne-devel
>> or, via email, send a message with subject or body 'help' to
>>     [email protected] <mailto:[email protected]>
>>
>> You can reach the person managing the list at
>>     [email protected] <mailto:[email protected]>
>>
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of Bayonne-devel digest..."
>> Today's Topics:
>>
>>    1. Building turnkey solutions with Bayonne 2 (David Sugar)
>>    2. voicetronix + hangup (Alessio Pomaro)
>>    3. voicetronix + hangup (Alessio Pomaro)
>>    4. Re: voicetronix + hangup (David Sugar)
>>    5. Re: voicetronix + hangup (Alessio Pomaro)
>> **
>> *From: *David Sugar <[email protected] <mailto:[email protected]>>
>> *Date: *onsdag 24 aug 2005 17.40.06 GMT+02:00
>> *To: *mailing_list_bayonne-devel <[email protected] 
>> <mailto:[email protected]>>
>> *Subject: **[Bayonne-devel] Building turnkey solutions with Bayonne 2*
>> *Reply-To: *[email protected] <mailto:[email protected]>
>>
>>
>> Bayonne has historically been easy to use in creating ad-hoc and
>> specialized enterprise voice applications.  The use of a scripting
>> engine and the server being very scripting and application centric, even
>> for configuration and control, has I think helped this use.  I believe
>> many of these same attributes have in the past tended to make Bayonne
>> rather difficult package in pure turnkey and dedicated solutions.
>>
>> In Bayonne2 I have looked at resolving this issue in several ways.  In
>> the most extreme form, Bayonne2 can now be decapitated, and the new
>> libbayonne used with an entirely new server/application environment.
>> This allows reuse of Bayonne drivers and management frameworks, as well
>> as the core call processing engine, while offering the ability to build
>> special purpose servers that might be better suited for some types of
>> turnkey or specialized applications.  This ability will be further
>> explored in several packages that use libbayonne and adapt it for xml,
>> and servers that are more routing centric rather than application
>> centric, such as troll gateways.
>>
>> Another solution, which has been quietly explored through the 0.8 
>> releases,
>> is the use of an alternate provisioning file.  The idea behind this is 
>> that
>> one should be able to take a generic, even pre-build distribution of a 
>> bayonne
>> server, such as one might find in a debian distribution, wrap it with some
>> scripts, maybe a plugin, and thereby build and deploy a complete solution.
>> To do this, several things had to happen.
>>
>> To do turnkey solutions, the scripting language had to be maintained
>> consistently between different arbitrary versions.  In the past this was
>> not rigorously enforced.  This was in part because when Bayonne was
>> started, there was no clear or certain idea as to what the scripting
>> language would eventually need to do.  So it evolved with Bayonne.  In
>> Bayonne2, we now have a good idea of how scripting should be used, and
>> so it has been possible to define it correctly at the earliest releases.
>> It is certainly possible to see script functionality expanded with new
>> releases, but only so long as existing commands are fully retained.
>>
>> The idea behind a provisioning file (/etc/bayonne/provision.conf) was
>> based on another idea to simplify turnkey products.  The provisioning
>> file is meant not to be user edited, but rather as a separate configure
>> file that would be created by the provisioning/configuration system of
>> some turnkey product.  The idea was to have a separate place where an
>> automated configure file could be used to define and override server
>> properties as needed by turnkey products.  This keeps a clean separation
>> between user editable configure files, and those that are part of a
>> turnkey product if present. This I believe will also make it easier to
>> take generic and pre-packaged versions of Bayonne, such as might be
>> found in a debian repository, which may include default or generic
>> configure files, and still easily merge that into a turnkey solution.
>>
>> Another area that may pose some difficulties is that Bayonne is
>> scripting centric.  Even routing information is often carried in
>> scripting.  This is not a problem for creating turnkey applications that
>> might use a front-end script and external meta-data driven sources for
>> routing, such as a subscriber voice mail server or debit system that has
>> an external subscriber database, or to create a dedicated sip voice mail
>> system through turnkey provisioned with scripts that integrate for
>> example with sipxpbx.  However, some types of routing centric
>> applications will still be hard to do in Bayonne alone, either because
>> the configuration system for such solutions will either need to also
>> generate scripts, or scripts will need to be manually maintained.
>> Solutions to the latter issue will be explored in Troll and a proposed
>> descendant of Troll that I think will become very popularly used.
>>
>>
>> <dyfet.vcf>
>>
>>
>> I have installed a voicetronix board (model: v4pci16 -> 
>> http://www.voicetronix.com/vpb4_v4pci.htm -> "Robust loop drop 
>> detection - 
>> suitable for the North American telephony network in detecting far end 
>> hang 
>> up") and voicetronix driver 2.4.8 
>> (http://www.voicetronix.com/downloads.htm). 
>>
>> There is a problem with hangup event (^hangup) -> event is not 
>> recognized. 
>>
>> Have I to modify bayonne.conf ? 
>>
>> Thanks! 
>>
>> --  
>>
>> Alessio Pomaro 
>>
>> pnfStudio s.n.c.
>> Viale Porta Po, 94
>> 45100 Rovigo RO (Italy) 
>>
>> Contacts:
>> tel. (+39) 0425 404193
>> fax. (+39) 0425 988982
>> mob. (+39) 320 2392615 
>>
>> Web:http://www.pnfstudio.com 
>>
>> CONFIDENZIALE: Questo messaggio e gli eventuali allegati sono 
>> confidenziali 
>> e riservati.Se vi è stato recapitato per errore e non siete fra i 
>> destinatarielencati, siete pregatidi darne immediatamente avviso al 
>> mittente. Le informazioni contenutenon devono essere mostrate ad 
>> altri, né 
>> utilizzate, memorizzate o copiate in qualsiasiforma. 
>>
>> CONFIDENTIAL: This  e-mail  and  any attachments are confidential andmay 
>> contain reserved information.If  you are not one of the named recipients, 
>> please notify the senderimmediately.Moreover, you should not disclose the 
>> contents to any other persons, norshould the information containedbe used 
>> for any purpose or stored or copied in any form. 
>>
>>
>>
>>
>>
>>
>>
>>
>> I'm working with Fedora Core 1 - kernel 2.4.22-1.2199.5.legacy.nptl 
>>
>> I have installed a voicetronix board (model: v4pci16 -> 
>> http://www.voicetronix.com/vpb4_v4pci.htm -> "Robust loop drop 
>> detection - 
>> suitable for the North American telephony network in detecting far end 
>> hang 
>> up") and voicetronix driver 2.4.8 
>> (http://www.voicetronix.com/downloads.htm). 
>>
>> There is a problem with hangup event (^hangup) -> event is not 
>> recognized. 
>>
>> Have I to modify bayonne.conf ? 
>>
>> Thanks! 
>>
>> --  
>>
>> Alessio Pomaro 
>>
>> pnfStudio s.n.c.
>> Viale Porta Po, 94
>> 45100 Rovigo RO (Italy) 
>>
>> Contacts:
>> tel. (+39) 0425 404193
>> fax. (+39) 0425 988982
>> mob. (+39) 320 2392615 
>>
>> Web:http://www.pnfstudio.com 
>>
>> CONFIDENZIALE: Questo messaggio e gli eventuali allegati sono 
>> confidenziali 
>> e riservati.Se vi è stato recapitato per errore e non siete fra i 
>> destinatarielencati, siete pregatidi darne immediatamente avviso al 
>> mittente. Le informazioni contenutenon devono essere mostrate ad 
>> altri, né 
>> utilizzate, memorizzate o copiate in qualsiasiforma. 
>>
>> CONFIDENTIAL: This  e-mail  and  any attachments are confidential andmay 
>> contain reserved information.If  you are not one of the named recipients, 
>> please notify the senderimmediately.Moreover, you should not disclose the 
>> contents to any other persons, norshould the information containedbe used 
>> for any purpose or stored or copied in any form. 
>>
>>
>>
>>
>>
>>
>> **
>> *From: *David Sugar <[email protected] <mailto:[email protected]>>
>> *Date: *torsdag 25 aug 2005 13.55.40 GMT+02:00
>> *To: *Alessio Pomaro <[email protected] 
>> <mailto:[email protected]>>
>> *Cc: *[email protected] <mailto:[email protected]>
>> *Subject: **Re: [Bayonne-devel] voicetronix + hangup*
>> *Reply-To: *[email protected] <mailto:[email protected]>
>>
>>
>> Is this a bayonne1 or bayonne2 question?  In Bayonne1 there was a 
>> drop= option in the [vpb] section because some older cards had 
>> problems and would give false drops.  That may need to be set "drop = y".
>>
>> Alessio Pomaro wrote:
>>
>>> Hi,
>>> I'm working with Fedora Core 1 - kernel 2.4.22-1.2199.5.legacy.nptl
>>> I have installed a voicetronix board (model: v4pci16 -> 
>>> http://www.voicetronix.com/vpb4_v4pci.htm -> "Robust loop drop 
>>> detection - suitable for the North American telephony network in 
>>> detecting far end hang up") and voicetronix driver 2.4.8 
>>> (http://www.voicetronix.com/downloads.htm).
>>> There is a problem with hangup event (^hangup) -> event is not 
>>> recognized.
>>> Have I to modify bayonne.conf ?
>>> Thanks!
>>> -- 
>>> Alessio Pomaro
>>> pnfStudio s.n.c.
>>> Viale Porta Po, 94
>>> 45100 Rovigo RO (Italy)
>>> Contacts:
>>> tel. (+39) 0425 404193
>>> fax. (+39) 0425 988982
>>> mob. (+39) 320 2392615
>>> Web:http://www.pnfstudio.com
>>> CONFIDENZIALE: Questo messaggio e gli eventuali allegati sono 
>>> confidenziali e riservati.Se vi è stato recapitato per errore e non 
>>> siete fra i destinatarielencati, siete pregatidi darne immediatamente 
>>> avviso al mittente. Le informazioni contenutenon devono essere 
>>> mostrate ad altri, né utilizzate, memorizzate o copiate in 
>>> qualsiasiforma.
>>> CONFIDENTIAL: This  e-mail  and  any attachments are confidential 
>>> andmay contain reserved information.If  you are not one of the named 
>>> recipients, please notify the senderimmediately.Moreover, you should 
>>> not disclose the contents to any other persons, norshould the 
>>> information containedbe used for any purpose or stored or copied in 
>>> any form.
>>> _______________________________________________
>>> Bayonne-devel mailing list
>>> [email protected] <mailto:[email protected]>
>>> http://lists.gnu.org/mailman/listinfo/bayonne-devel
>>>
>>> <dyfet.vcf>
>>
>> *From: *"Alessio Pomaro" <[email protected] 
>> <mailto:[email protected]>>
>> *Date: *torsdag 25 aug 2005 14.19.16 GMT+02:00
>> *To: *[email protected] <mailto:[email protected]>
>> *Cc: *[email protected] <mailto:[email protected]>
>> *Subject: **[Bayonne-devel] Re: voicetronix + hangup*
>>
>> _______________________________________________
>> Bayonne-devel mailing list
>> [email protected] <mailto:[email protected]>
>> http://lists.gnu.org/mailman/listinfo/bayonne-devel
>>
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Bayonne-devel mailing list
> [email protected]
> http://lists.gnu.org/mailman/listinfo/bayonne-devel

_______________________________________________
Bayonne-devel mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/bayonne-devel
dyfet.vcf (text/x-vcard, 187 B)
begin:vcard
fn:David Sugar
n:Sugar;David
org:GNU Telephony
adr:;;;;;;USA
email;internet:[email protected]
x-mozilla-html:FALSE
url:http://www.gnutelephony.org
version:2.1
end:vcard
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.